AutoQ content pack
Software Development Review
This review assesses whether the controls a development team uses to design, build, release and run its software securely are designed well and operating as intended.
The pack is a complete control questionnaire, ready to run on AutoQ Standalone or Enterprise Version 3.1 alongside your other reviews, with its own installer. Your team answers each control and records the evidence it inspected, and AutoQ writes the statement of fact, risk, effect and recommendation for every answer, rates each domain and produces the reports.
High-risk controls are those where a failure most directly exposes the software, its data or its customers to attack.
Who it's for
- IT auditors reviewing a development team
- Heads of engineering and application security
- Product owners responsible for a customer-facing system
- Customers assessing a software supplier
When to use it
- A secure development review of an in-house team
- Due diligence on a software supplier
- A check before an internet-facing system goes live
What it covers
Governance and Secure Design
20 controls, 5 of them high risk
High-risk focus: threat modelling, tracking security findings to closure, formal risk acceptance with affected features kept off, security release criteria, and independent penetration testing.
Examples of the controls:
- A threat model is prepared for each new system and for significant design changes, and the threats identified are tracked to a mitigation.
- Findings from security reviews, penetration tests, audits and scans are recorded with an owner, a severity and a target date, and are tracked to closure.
- A secure development policy defines the security activities required at each stage of the software life cycle, is approved by management and is reviewed at least annually.
Source Code and Change Management
20 controls, 9 of them high risk
High-risk focus: restricted and reviewed repository access with multi-factor authentication, prompt removal of leavers, branch protection, independent code review, approval before publishing, separation of duties, and keeping secrets out of the code.
Examples of the controls:
- Source code is kept in a central version control system, access is limited to authorized people, and access is reviewed at least quarterly.
- Accounts with access to the source code hosting service use multi-factor authentication, and repositories are private unless intentionally published.
- Each change is linked to an approved ticket that describes its purpose and impact, and commit messages describe what changed and why.
Build, Testing and Release
20 controls, 7 of them high risk
High-risk focus: a protected build environment, dependency scanning, automated security tests, exposure testing of the public site, separate environments, release contents checks, and secure defaults.
Examples of the controls:
- Access to the build and release systems is restricted, changes to build configuration are reviewed, and build systems are kept patched.
- Third-party dependencies are scanned for known vulnerabilities on every build and at least daily, and critical vulnerabilities are fixed within defined times.
- Releases are built from version control by a scripted, repeatable process rather than by hand.
Application Security
20 controls, 15 of them high risk
High-risk focus: no default administrator passwords, strong password storage, sign-in limits, multi-factor and network-restricted administration, sessions, authorization, input and output handling, file access, encryption, secrets, uploads, server-side requests and customer exports.
Examples of the controls:
- The software contains no default or hard-coded administrator passwords, and the first administrator login is set up by the owner, for example on the server itself or during installation.
- Administrator passwords must be at least 12 characters, and all passwords are stored salted with a slow hashing function such as scrypt, bcrypt or Argon2.
- Public pages do not contain administrative code or reveal administrative addresses; administrative pages and scripts are sent only after sign-in, and robots.txt is not relied on to hide them.
Operations and Monitoring
20 controls, 8 of them high risk
High-risk focus: separation of production from development, restricted production access, security event logging and regular log review, patching, backups and incident response.
Examples of the controls:
- Production does not run on a developer's computer; where a small team must do so, the risk is formally accepted and compensated by separate accounts, restricted folders and independent backups.
- Administrative access to production servers and data is limited to authorized people, program files need administrator rights to change, and access is reviewed quarterly.
- Requests to internet-facing applications, including refused ones, are logged with time, address and outcome, and the log is kept for a defined period.
Frameworks
Every control carries references to NIST SP 800-218 SSDF v1.1, ISO/IEC 27001:2022 Annex A and OWASP ASVS 4.0.3, so findings can be tied to the criteria your audit uses.
Criteria references mapped from NIST SP 800-218 Secure Software Development Framework v1.1 (practice and task IDs), ISO/IEC 27001:2022 Annex A and the OWASP Application Security Verification Standard 4.0.3 (chapter and requirement numbers). Verify against the editions your audit uses.
What's in the workbook
| Control Library | Every control with its domain and subdomain, the control assertion, type, nature, frequency and risk weight, the framework references, the suggested test procedure, the evidence to request, the statements of fact if true and if false, the effect if false and the recommendation. |
|---|---|
| Questionnaire | The working sheet the review team answers, control by control, with the evidence they inspected; AutoQ fills in the findings from the answers. |
| Domain Summary | The rating of each domain, weighted by risk, ready for the report. |
| Column Guide | What every column means and how it is used. |
| Sources | The framework editions the references were mapped from, with a column for the reviewer to record the date each reference was checked. |
Delivered with its own installer, which adds it to AutoQ as a new review (or as a .zip to add on the Admin tab). The questionnaire is an Excel workbook, so it can be adapted with your own controls and ratings.
The framework references were mapped from the published texts and should be checked by a qualified reviewer against the editions your audit uses. The pack supports a review; it does not replace professional judgement or the requirements of your regulator.