SOURCE REVIEW / AI security · Review practice
Reviews across the
lifecycle
A source-based guide to review targets, timing and scope across software development. It separates standard requirements and institutional guidance from derived recommendations for different change types.
- Article date
- Base notes dated
- Latest source check
THE SHORT VERSION
Key points.
- Separate target, method and timing: ASVS defines application requirements. Review and test guidance explains how to assess them; the change determines when to revisit the scope.
- Scale by the change: review affected requirements and risks while retaining applicable mandatory checks.
- Separate guidance from interpretation: the proposed change-type matrix is an editorial recommendation, not an institution-prescribed minimum.
01SOURCE REVIEW
Guidance for reviews and tests
ASVS verification levels specify the application requirements to verify. The levels alone do not define review or test procedures. Methods, scope, reviewers and evidence need to be specified in the assessment plan. [07] [08]
NIST SSDF PW.7 calls for choosing human review and/or tool analysis, checking against secure coding standards, and recording and triaging findings. PW.8 covers selecting, designing and executing tests of executable code, documenting results and triaging issues. [05]
NIST IR 8397 recommends eleven minimum developer-verification techniques, including threat modeling, static analysis, regression tests and fuzzing. Adapt the process to the product, technology, toolchain and lifecycle. The linked testing article covers the full set and its limits. [09]
OWASP SAMM combines automated security testing with manual review of selected high-risk components. Its criteria include risk-based selection, qualified reviewers, documented guidelines and handling findings through defect management. Its maturity levels describe organizational practices, separately from ASVS application verification levels. [11] [12]
OWASP WSTG supplies a flexible lifecycle framework: requirements and design review, code review, penetration and configuration testing, and change verification. It is guidance to adapt, not a universal prescribed sequence. [01]
Editorial recommendation. The matrix below translates these sources into suggested scope by change type. It does not establish an institution-prescribed minimum or universal gold standard.
The eleven verification techniques and their limits
Code and security review tools
Back to contents02SOURCE REVIEW
ASVS: requirements for the application
Standard requirements. For web applications and services, OWASP ASVS 5.0.0 provides a verifiable target. Select the level according to risk, sensitive data and expected assurance. The levels below describe application requirements, not a prescribed scanner combination or CI/CD pipeline. [07]
The selected requirement examples below are abridged, not a complete checklist. Levels build on one another; some requirements impose stricter conditions at higher levels. [07]
Record the version, target level, scope, applicable requirements, methods and evidence. Explain exclusions. A scanner report alone cannot establish that all requirements are met, and an accepted exception is not a passed requirement. OWASP does not certify applications or assessment providers. [08]
ASVS L1 · Minimum
The minimum level and a starting point for adoption, focused on basic defences against common attacks. Version 5.0 does not assume that every L1 requirement can be verified entirely from outside the application. [07]
Selected requirements: validate inputs used for business or security decisions (v5.0.0-2.2.1); implement defences against credential stuffing and password brute force (v5.0.0-6.3.1); restrict functions and individual data objects to explicitly authorised users or clients (v5.0.0-8.2.1 and v5.0.0-8.2.2). [14] [15] [16]
ASVS L2 · Target for most applications
OWASP recommends L2 for most applications. It includes the applicable L1 and L2 requirements, addressing less common attacks and more complex protections. The selected scope and any non-applicable requirements still need justification. [07] [08]
Selected additions: validate all inputs (the L2 condition in v5.0.0-2.2.1); require multi-factor authentication (v5.0.0-6.3.3); enforce field-level permissions (v5.0.0-8.2.3); log authentication operations and failed authorisation attempts (v5.0.0-16.3.1 and v5.0.0-16.3.2). [14] [15] [16] [17]
The MFA requirement allows relaxation only with a fully documented rationale and comprehensive mitigating controls. This condition also applies to its stronger L3 clause. [15]
ASVS L3 · Highest assurance level
The highest assurance level defined by ASVS, including applicable L1, L2 and L3 requirements. Its additions often provide defence in depth or controls that are harder to implement. Select it where the application risk and assurance needs warrant this depth. [07]
Selected additions: use a hardware-based, phishing-resistant authentication factor requiring user action (the L3 condition in v5.0.0-6.3.3); apply contextual authentication and authorisation controls at session start and during sessions (v5.0.0-8.2.4); require multi-user approval for high-value business operations (v5.0.0-2.3.5); log all authorisation decisions, including access to sensitive data without logging that data itself (the L3 condition in v5.0.0-16.3.2). [15] [16] [14] [17]
03SOURCE REVIEW
Review timing across the lifecycle
Source guidance. WSTG places security testing across the lifecycle. ENISA names SAST and dependency checks on each PR and peer review for security-sensitive changes. OWASP SAMM describes an automated testing baseline and qualified manual review of high-risk components. The matrix cites these methods separately from the recommended scope of each change type. [01] [04] [11] [12]
Derived recommendation. The change types, their proposed baseline and the triggers for deeper review are an editorial synthesis of the cited sources. No cited institution prescribes this exact matrix or a universal gold standard per change. The baseline column is a starting point for project policy, not proof of a complete minimum or permission to skip required checks. Checks can overlap, and findings can send work back to design, implementation or tests.
ASVS L1, L2 and L3 describe the assurance target for the application, not review levels for individual diffs. Establish a documented assessment scope first, then examine how a change affects applicable requirements and the attack surface. The matrix recommends scaling the additional review to that impact while retaining the selected requirements. [07] [02] [03]
Derived recommendation for cosmetic changes. The cited security guidance provides no explicit button-colour exemption. The recommendation to avoid a new full penetration test solely for a colour change assumes unchanged behaviour, permissions, data flows and security cues. A change that obscures a security warning or privileged action falls outside that assumption. Existing required checks still apply. [04] [02]
Requirement when AISVS is selected. AISVS has its own levels. Its 1.01 Appendix C, AC.4.2 at L2, requires SAST, IAST, DAST, secret scanning, IaC scanning and SCA on every PR containing AI-generated code, with no stated cosmetic exception. AC.4.4 adds an elevated review threshold for security-critical files. These requirements take precedence over a lighter derived recommendation when they apply. The OWASP project remains an Incubator project; its requirements are not a universal minimum for every application. [06] [10]
Verification methods and evidence
EXPLAINED VISUALLY
When to review — and how deeply
WHERE IN THE SOFTWARE DEVELOPMENT LIFECYCLE
- 01Design
Requirements, architecture & threat model
- 02Build
Tests, static analysis, dependencies & secrets
- 03Change review
Review the diff and affected code paths
- 04Release
Verify runtime behaviour & deployment settings
- 05Operate
Track vulnerabilities, changes & new evidence
Activities overlap. Findings feed back into design, fixes and tests.
When to repeat the checks
- Initial baselineNew application
- Assess architecture, the repository and relevant runtime risks before first release. Revisit after major changes.
- Every changeDevelopment & integration
- Run automated baseline checks and review affected behaviour. This does not mean a full repository audit on every pull request.
- Risk-triggeredSecurity assumptions change
- Revisit affected threats and deepen review for new interfaces, permissions, sensitive data, dependencies or infrastructure.
- RecurringMaintenance & operations
- Reassess on a risk-based schedule and when new vulnerabilities or incidents emerge, even without a code change.
Review scope by change type
Source guidance summarises the cited publications. Derived recommendations turn that guidance into a suggested baseline and escalation trigger for each change type. This mapping is not a source-prescribed minimum or a validated gold standard.
-
New application / first release
Derived recommendation
- Baseline
- Select applicable ASVS requirements. Assess threats, code, components and runtime behaviour. Include a scoped deployment pentest and record unresolved findings.
- Additional depth / trigger
- Increase assessment depth for sensitive data, critical operations or gaps in evidence. Verify fixes before accepting the remaining risk.
-
Purely visual change
Derived recommendation
- Baseline
- Keep the shared PR checks. Inspect the diff, appearance and contrast. Confirm that behaviour and security settings are unchanged.
- Additional depth / trigger
- Do not add a full pentest solely for a colour change. Reassess changes to security warnings or privileged controls.
-
Feature / bug fix
Derived recommendation
- Baseline
- Keep the shared PR checks. Review the diff and affected paths. Test expected behaviour, failure cases and relevant regressions.
- Additional depth / trigger
- Deepen security review and runtime tests when interfaces, data flows or trust assumptions change.
-
Login / permissions / sensitive interfaces
Derived recommendation
- Baseline
- Keep the shared PR checks. Add a focused security review and negative access tests. Revisit affected threats and trust boundaries.
- Additional depth / trigger
- Expand abuse-case and integration tests across affected roles and interfaces. Use targeted penetration testing where the risk warrants it.
-
Dependency addition / update
Derived recommendation
- Baseline
- Keep the shared PR checks. Review changed versions, provenance and vulnerability findings. Update the inventory and test affected integrations.
- Additional depth / trigger
- Investigate new component privileges or exposed interfaces. Add focused review and tests when they alter the attack surface.
-
Infrastructure / configuration
Derived recommendation
- Baseline
- Keep applicable PR checks. Review configuration and policy checks, access, secrets and exposure. Test the deployment and prepare rollback.
- Additional depth / trigger
- Revisit threats and test affected boundaries when identity rules, network access, encryption or data handling change.
All baseline and escalation cells are editorial recommendations. The cited sources support their principles and methods, not this exact checklist or a claim that it is sufficient. “Purely visual” excludes changes to behaviour, data flows, dependencies or security configuration. The ASVS level remains the application target, not a label assigned to each diff.
Required controls still apply. AISVS Appendix C, AC.4.2 (Level 2), specifies automated security testing on every pull request containing AI-generated code. Risk-based scoping does not waive an applicable requirement. [06]
An editorial synthesis of the cited guidance. The phases overlap and repeat. Row references support the stated methods and principles; the proposed scope per change type is a derived recommendation. The matrix was added on 19 October 2026. This is not a record of checks run on this website.
Define the application requirements, establish a baseline and revisit the affected scope when changes or new evidence alter the risk. The matrix offers a starting point for project policy. Applicable requirements and documented evidence remain decisive.
REFERENCES / 17
Sources.
This article brings together institutional standards and guidance. The change-type matrix draws on SAMM, ENISA, AISVS and W3C sources checked on 19 October 2026. Other source records retain their individual check dates. Source requirements and guidance are distinguished from editorial recommendations. This is not an assessment or certification of this website.
- OWASP WSTG 4.2 — The Web Security Testing Framework (opens in a new tab)
Overview: flexible, non-prescriptive framework. Phases 2–5 cover requirements and design review, code review, penetration and configuration testing, and change verification. The graphic uses an editorial grouping, not the exact WSTG phase names.
- OWASP — Attack Surface Analysis Cheat Sheet (opens in a new tab)
Managing the Attack Surface: baseline assessment, incremental changes, new APIs/uploads, authentication, authorisation and architecture.
- OWASP SAMM — Threat Modeling (opens in a new tab)
Iterative scope, triggers for updates and regular review of existing threat models. Activities are organised by maturity level.
- ENISA — Secure by Design and Default Playbook, Version 1.0 (opens in a new tab)
Sections 4.8–4.9: security UX, peer review for sensitive changes, SAST and dependency checks on each PR, negative tests, secrets checks and release evidence. Section 4.11: infrastructure and configuration review, CI policy checks, approvals and rollback. Sections 4.13–4.14: regression tests for security fixes and peer review of new dependencies or major upgrades. Product-dependent engineering baseline in section 4.23.2.
- NIST — Secure Software Development Framework (SSDF), Version 1.1 (opens in a new tab)
Final publication; PW.7.1–PW.7.2 and PW.8.1–PW.8.2, printed pp. 14–15 (PDF pp. 23–24). Choose human review and/or tool analysis; apply secure coding standards; record and triage findings. Select, design and execute executable-code tests, document results and triage issues.
- OWASP AISVS 1.01 — Appendix C: AI-Assisted Secure Coding (opens in a new tab)
Mutable main branch, stable 1.01 directory. AC.4.2 at L2 specifies SAST, IAST, DAST, secrets, IaC and SCA on every PR containing AI-generated code, with no cosmetic exception. AC.4.4 adds review requirements for critical files. AISVS levels are distinct from ASVS levels.
- OWASP ASVS 5.0.0 — What is the ASVS? (opens in a new tab)
Pinned 5.0.0 release. Scope for web applications and services; cumulative levels and stricter higher-level clauses. L1 minimum, L2 recommended for most applications, L3 highest assurance. L1 is not necessarily entirely black-box testable.
- OWASP ASVS 5.0.0 — Assessment and Certification (opens in a new tab)
Version, level, scope, applicability and assessment evidence; limitations of automated tools; OWASP does not certify applications or assessment providers.
- NIST IR 8397 — Guidelines on Minimum Standards for Developer Verification of Software (opens in a new tab)
Sections 1.1–1.3 and 2.1–2.11: eleven recommended minimum verification techniques; tailor the process to product, technology, toolchain and lifecycle. No single specific, prescriptive standard fits all software. Configuration and operation are outside this document’s scope.
- OWASP — Artificial Intelligence Security Verification Standard (AISVS) (opens in a new tab)
OWASP project directory lists AISVS as an Incubator project. Version 1.01 is checked against the repository, not older version labels on project pages.
- OWASP SAMM — Security Testing: Scalable Baseline (opens in a new tab)
V-ST-A-1 describes static and dynamic testing selected for the technology stack; V-ST-A-3 integrates automated security tests and review of findings into build and deployment. Maturity-model activities, not a prescribed minimum for each change type.
- OWASP SAMM — Security Testing: Deep Understanding (opens in a new tab)
V-ST-B-1: risk-based component selection, qualified reviewers following documented guidelines, and findings handled through defect management. High-risk examples include authentication, access control, sessions, external interfaces and parsers. V-ST-B-2 covers application-specific penetration testing, generally before release. V-ST-B-3 uses previous findings to trigger explicit tests when affected code changes.
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab)
SC 1.4.3 covers text contrast; SC 1.4.11 covers contrast needed to identify visual components and states. Exceptions apply. These are accessibility requirements, not a security-review cadence.
- OWASP ASVS 5.0.0 — V2 Validation and Business Logic (opens in a new tab)
Pinned 5.0.0 release. v5.0.0-2.2.1: L1 input validation and its broader L2 scope. v5.0.0-2.3.5: multi-user approval for high-value business flows at L3.
- OWASP ASVS 5.0.0 — V6 Authentication (opens in a new tab)
Pinned 5.0.0 release. v5.0.0-6.3.1: credential-stuffing and brute-force controls at L1. v5.0.0-6.3.3: MFA at L2, stronger hardware-based factor at L3, and documented conditions for relaxation.
- OWASP ASVS 5.0.0 — V16 Security Logging and Error Handling (opens in a new tab)
Pinned 5.0.0 release. v5.0.0-16.3.1: authentication logging at L2. v5.0.0-16.3.2: failed authorisation attempts at L2 and all authorisation decisions at L3, without logging sensitive data itself.