It fails at the point where security properties should have been defined, because scanning only sees what was implemented. If authentication, authorization, or trust boundaries were never specified in the design, downstream tools can confirm code quality but not correct the original security decision.
Where code scanning stops and design review should have started
security design review fails when teams treat static analysis or SAST as a substitute for defining the security model. Scanners can tell you whether the code follows expected patterns, but they cannot invent missing trust assumptions, choose the right boundary between systems, or decide who should be authenticated and authorised in the first place.
The failure is usually architectural, not tool-related. If the design never specified what must be protected, what can trust what, or which identities may act on behalf of the user or service, code scanning will only validate implementation against an incomplete plan.
That is why security design review belongs upstream of implementation, and why organisations that want stronger shift-left practice should treat design artefacts as the source of truth for security decisions, not the application code alone. NHIMG’s NHI Lifecycle Management Guide is useful here because lifecycle, ownership, rotation, and offboarding all depend on decisions that a scanner cannot infer from source code.
What code scanning can prove, and what it cannot
Scanning is strong at finding known implementation defects: insecure libraries, injection patterns, misconfigurations, exposed secrets, and some broken access checks. It is weak at judging whether the system’s security objectives were correctly defined. A clean scan result may simply mean the software consistently implements the wrong design.
That distinction matters for authentication and authorization. If the architecture does not say whether a component should use end-user identity, service identity, or delegated access, the scanner may see valid code paths while the real control problem remains unresolved. The same is true for trust boundaries, where a code-only review cannot tell whether a trust relationship should exist at all.
In practice, this is the gap between “no detected defect” and “security requirement satisfied.” A tool can confirm that an access token is checked, but it cannot confirm that the token was needed, scoped correctly, or issued to the right actor for the right purpose.
For teams building AI-assisted development workflows, the problem becomes easier to miss because code generation can increase output while reducing attention to design intent. NHIMG’s Analysis of Claude Code Security is relevant as a reminder that security tooling around code generation still depends on human-defined boundaries, review goals, and verification criteria.
Why missing design decisions become security defects later
When a security decision is absent at design time, downstream teams often compensate with ad hoc controls. That usually creates brittle authorisation logic, unclear ownership, and inconsistent trust assumptions across services. The result is not only more defects, but defects that are harder to detect because they look “implemented” even when they are conceptually wrong.
The risk is greatest where one component can act for another, where external callers can influence privileged workflows, or where secrets and tokens blur the line between authentication and delegated access. Code scanning sees syntax and patterns, not whether a business process should have been split, a privilege reduced, or a trust relationship removed entirely.
That is also why design review is the right place to catch environment separation failures, over-broad service permissions, and hidden implicit trust between internal systems. Once those assumptions are embedded in code and infrastructure, remediation becomes more expensive and often requires re-architecture rather than a simple fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-15 — Development Process, Standards, and Tools | Design review is a software development control issue. |
| SI-2 — Flaw Remediation | Scanning finds flaws after implementation and drives corrective action. | |
| IA-2 — Identification and Authentication (Organizational Users) | The question centers on whether identity decisions were defined before scanning. | |
| Recommendation — Require security design review before code reaches verification gates. Use scan findings to remediate code, then verify the design still holds. Define authentication requirements in design before validating code paths. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | ASVS explicitly separates secure architecture from implementation checks. |
| Recommendation — Review architecture requirements before relying on code-level verification. | ||
| NIST CSF 2.0 | PR.IP-1 — Policies and Processes are Implemented and Maintained | Security design review depends on defined processes and maintained standards. |
| Recommendation — Maintain a design-review process that precedes implementation scanning. | ||
Practitioner Guidance
What to verify: Treat the design artefact as incomplete unless it explicitly states the security objective, the trust boundary, the actor types, and the authorisation decision behind each sensitive flow. If those are missing, a passing scan should be interpreted as an implementation checkpoint, not as security approval.
Decision rule: If the question is “is the code secure?”, scanning helps. If the question is “was the right security model chosen?”, design review has to answer first. Use scanners to confirm execution of the design, not to discover the design after the fact.
Common mistake: Teams often review authentication code while skipping the harder question of whether the system should trust that identity path at all. The practical fix is to require a named security decision for every sensitive interaction, then verify that implementation matches that decision.
Practitioner takeaway: Code scanning reduces implementation risk, but it cannot rescue an unspecified trust model, so the most important review is the one that proves the security decision existed before the code did.
Related resources from NHI Mgmt Group
- Why do security controls for insecure code patterns fail when teams rely on function names alone?
- How should security teams design AI review pipelines for code changes?
- How should security teams combine AI-native scanning with deterministic SAST for code review at scale?
- What breaks when security teams rely only on pull request scanning for AI-generated code?