Security design review is becoming the control point for AppSec

At a glance

What this is: BSIMM16 shows security design review moving from a specialist exercise to a mainstream AppSec control, with feature review observed in 80.2% of participating organisations.

Why it matters: This matters because IAM, NHI, and broader security controls are most effective when trust boundaries, authentication, and authorisation decisions are defined before code and workflows harden them.

By the numbers:

• BSIMM16 reports that activity [AA1.1] Perform security feature review is observed in 80.2% of organizations.
• BSIMM16 is based on observations across 111 organizations.
• The activity [AA1.4] using a risk methodology to rank applications saw a 12% increase in BSIMM16.
• BSIMM16 notes a 10% increase in [AM1.5] Gather and use attack intelligence.

👉 Read Seezo's analysis of BSIMM16 and security design review

Context

Security design review is the point where teams decide how a system should behave before code exists. That matters because authentication, authorisation, trust boundaries, and data handling are often locked in at design time, long before static analysis or dependency scanning can help.

The article argues that AI-assisted development, compliance pressure, and manual review limits are pushing AppSec upstream. For identity programmes, the intersection is clear: if access patterns, service trust, and credential assumptions are not specified early, later controls inherit those gaps rather than fixing them.

Key questions

Q: How should security teams implement security design review in fast-moving development environments?

A: Start by making design review a required input to build approval, not an optional consult after implementation begins. Focus the review on trust boundaries, identity flow, data handling, and privileged interactions. Automate intake from the tools developers already use, then reserve expert time for novel architectures and high-impact systems.

Q: Why does AI-generated code change the way AppSec teams should govern design?

A: Because generated code can faithfully implement an insecure design at much higher speed than manual development. The main control problem shifts from line-by-line inspection to validating whether the system intent already includes the necessary security decisions. If the architecture is weak, automation only scales the weakness faster.

Q: What do security teams get wrong about access reviews?

A: Teams often treat access reviews as proof of control, when they are really only a point-in-time check. If reviewers cannot see current activity and business context, they may approve access that is technically valid but operationally obsolete. The better test is whether the governance model can explain why access still exists.

Q: How do organisations know if security design review is actually working?

A: Look for evidence that high-risk decisions are captured before code exists and that those decisions consistently appear in build artefacts, tickets, or architecture records. If teams can only show late-stage findings or ad hoc reviews, the programme is detecting problems rather than preventing them.

Technical breakdown

How security design review works before code is written

Security design review examines architecture diagrams, requirements, and implementation plans to identify where a system will trust identities, move data, or enforce access. Unlike scanning tools, it operates on intent, not code. That means it can catch missing authentication steps, weak authorisation boundaries, or unsafe data flows before implementation bakes them in. In practice, the value comes from turning security requirements into design constraints while the system is still cheap to change.

Practical implication: require security review at the point where architecture and requirements are still editable, not after implementation starts.

Why AI-generated code increases the need for architectural controls

LLM-generated code can look polished while omitting the security decisions an experienced developer would normally make instinctively. That changes the AppSec problem from code quality alone to design fidelity, because code may faithfully implement a weak design. AI also increases throughput, which makes manual review even less scalable. The control surface shifts upward: teams need architecture-level checks that validate whether the design itself includes the controls the code should later realise.

Practical implication: treat AI-assisted development as a reason to strengthen design review, not to rely more heavily on downstream scanning.

How automation changes the security design review bottleneck

Modern design analysis can extract structure from unstructured artefacts such as Jira tickets, Confluence pages, and product requirements. That matters because security teams do not usually receive neat architecture documents. Automation helps identify components, trust relationships, and missing controls at scale, while human reviewers focus on novel or ambiguous risk. The architecture analysis model only scales when security becomes part of the development workflow rather than a separate gate.

Practical implication: embed review outputs into developer tools so security requirements travel with the work item, not behind it.

Threat narrative

Attacker objective: The objective is to exploit predictable design weaknesses before they are corrected, so insecure system behaviour is shipped into production.

1. Entry occurs at the design stage, where incomplete requirements or ambiguous architecture decisions allow insecure trust relationships to be specified before implementation.
2. Escalation follows when those design flaws are translated into code, making weak authentication or authorisation assumptions pervasive across the system.
3. Impact appears in production as avoidable vulnerabilities, expensive rework, and compliance evidence that cannot be reconstructed cleanly after the fact.

NHI Mgmt Group analysis

Design review is becoming a control plane, not a documentation exercise. BSIMM16 reinforces that the security decisions made before code exists determine whether downstream controls can ever work properly. Once authentication paths, trust boundaries, and data flows are baked into design, later testing mostly measures how faithfully the team implemented the flaw. For IAM and NHI programmes, this means governance must begin where system trust is first defined. The practitioner conclusion is straightforward: security design review should be treated as a mandatory control point for any system that creates identities, tokens, or delegated access.

AI-assisted development is exposing architecture debt faster than most AppSec programmes can absorb it. Generated code can accelerate delivery while silently reproducing weak or incomplete security assumptions from the underlying design. That shifts the failure mode from insecure implementation to insecure specification. In identity-heavy systems, the risk is sharper because service accounts, machine-to-machine trust, and authorisation scope are often encoded indirectly. The practitioner conclusion is that architecture review must verify intent, not just validate code output.

Security feature review is now a mainstream practice, but coverage remains the real governance problem. BSIMM16’s 80.2% observation rate shows the activity is widely recognised, yet widespread adoption does not equal comprehensive assurance. Manual review inevitably concentrates on the highest-value systems, leaving long tails of services and features unevaluated. Design-review coverage gap: the governance failure is not absence of review in principle, but inconsistent review across the portfolio. The practitioner conclusion is to measure which designs are actually reviewed, not simply whether the programme claims to do review.

Compliance is moving upstream into evidence created at design time. The EU Cyber Resilience Act and similar obligations make it harder to rely on post-build scans alone. Teams need traceable proof that security requirements were considered when the system was defined, not reconstructed after release. This is particularly relevant where identity and access decisions affect product behaviour, because those decisions are often among the hardest to remediate later. The practitioner conclusion is to connect design review outputs directly to control evidence and standards mapping from day one.

What this signals

Design-review governance will become more measurable as organisations push security earlier in the delivery chain. That means AppSec leaders should expect pressure to show not only that reviews happen, but that they happen before identity, trust, and access assumptions are cemented. For programmes that handle secrets and machine identities, this is the point where design evidence starts to matter as much as runtime telemetry.

Architecture analysis will increasingly overlap with identity governance. As systems rely on service accounts, delegated tokens, and AI-assisted development, security teams will need to prove that trust relationships were explicit before implementation. The practical shift is toward traceable security requirements that connect architecture decisions to identity controls, supported by standards such as the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

Coverage, not just capability, will define maturity. The programmes that win are the ones that can show which services were reviewed, which trust decisions were challenged, and which requirements were carried into delivery without manual follow-up. That creates a clearer line from design choice to risk reduction, and it is where the next generation of AppSec reporting will be judged.

For practitioners

• Embed security review at requirements intake Require authentication, authorisation, trust boundary, and data-handling questions to be answered before implementation tickets are approved. Capture the security decision in the design artefact itself so later reviews can validate against a defined intent, not guess at it.
• Prioritise reviews for identity-bearing systems Flag services that create, consume, or delegate identities, tokens, certificates, or service accounts for mandatory design review. These systems carry disproportionate blast radius because access assumptions become durable quickly once they enter production.
• Automate extraction from design artefacts Use workflow-integrated analysis to read Jira tickets, Confluence pages, and architecture notes for missing controls and undefined trust relationships. Automation should triage routine cases and route only ambiguous or novel designs to senior reviewers.
• Measure review coverage, not just review volume Track what percentage of features, services, and release trains received a security design review before build starts. Coverage metrics expose the gap between programme intent and actual governance better than raw activity counts.

Key takeaways

• Security design review is moving upstream because design decisions determine whether authentication, authorisation, and trust controls can work at all.
• BSIMM16 shows broad adoption, but the governance challenge is coverage, not awareness, especially as AI speeds up code generation.
• AppSec leaders should measure whether security requirements are defined before build starts and tied directly to delivery evidence.

Key terms

• Security Design Review: A security process that evaluates architecture and implementation choices before they become production risk. It aims to catch unsafe design decisions early, when fixes are cheaper and broader impact is avoidable. In mature programmes, it is governed like a control, not treated as an informal consultation.
• Architecture Analysis: Architecture analysis is the structured assessment of how a system is put together from a security perspective. It looks at components, dependencies, boundaries, and intended behaviour to determine whether the design can safely support the controls the organisation expects to enforce.
• Security Feature Review: Security feature review is a design-level activity that checks whether security capabilities are present, correctly specified, and suitable for the system’s risk. It is often used to validate that features such as access control, encryption, and authentication are not assumed but explicitly designed.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

What's in the full article

Seezo's full blog covers the operational detail this post intentionally leaves for the source:

• A walkthrough of how the vendor analyses unstructured design artefacts such as Jira tickets and Confluence pages.
• Examples of how security requirements are converted into developer-facing workflow outputs before implementation starts.
• The article's mapping of design review outputs to compliance evidence for security assurance and audit preparation.

👉 Seezo's full post covers the design-review workflow, AI-assisted analysis, and compliance implications in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that complements upstream design and AppSec controls. It is suited to practitioners who need to connect identity risk to broader security architecture and governance decisions.