Notifications
Clear all
Topic starter
01/08/2026 10:45 pm
TL;DR: BSIMM16, based on observations across 111 organisations, reports that security feature review is now seen in 80.2% of participating firms, reflecting a shift toward design-level assurance before code exists, according to Seezo. The real challenge is no longer whether teams can scan faster, but whether they can define security properties early enough for implementation to inherit them safely.
NHIMG editorial — based on content published by Seezo: The Evolution of Security Design Review
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Embed security review at requirements intake Require authentication, authorisation, trust boundary, and data-handling questions to be answered before implementation tickets are approved.
- Prioritise reviews for identity-bearing systems Flag services that create, consume, or delegate identities, tokens, certificates, or service accounts for mandatory design review.
- 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.
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.
👉 Read Seezo's analysis of BSIMM16 and security design review →
Security design review and BSIMM16: what AppSec teams should do now?
Explore further
01/08/2026 10:54 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Security design review is becoming the control point for AppSec
