Security Review

Origin & evolution

The security review grew out of the secure development lifecycle, formalised when Microsoft published its Security Development Lifecycle in the mid-2000s and made design review and threat modelling mandatory phases before code shipped. The practice spread as DevSecOps pushed security checks earlier, so that review became a continuous gate woven through delivery instead of a single pre-launch event.

The field now distinguishes the review's modes by what each one reads. A threat model🏴‍☠️Threat ModelSecurityA threat model for the systemView reference → is done best in the plan phase, before code exists, examining the design from an attacker's point of view (Forward Security). A secure code review reads the source itself, which reveals edge cases and hard-to-reach states a remote test would never hit (spyro-soft). These are complementary lenses on the same system at different stages, and mature teams run more than one.

How it works in practice

A team is two weeks from launching a payments feature⭐FeatureProduct SpecificationA product capability or featureView reference →. The security review gate has three parts. First, a threat-model review of the design surfaces a missing authorisation check on a refund endpoint: an attacker could refund to an account they do not own. The team fixes the design before a line is written, a change that would have cost ten times as much after release🚢ReleaseProduct SpecificationA shipped version of the productView reference →. Second, a secure code review of the implementation finds an input that reaches a database query unsanitised. Third, because the review judges the residual risk🎲RiskComplianceA risk to the product or businessView reference → too high to sign off on assertion alone, it commissions a penetration test🗡️Penetration TestSecurityA penetration testView reference → against the staging environment to confirm the running system holds. The review does not break things itself; it decides what evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → is needed and who must produce it.

Security review vs. its neighbours

• Penetration test attacks the running system from the outside to prove exploitability. The review is broader and earlier; it reads designs and source, and it often commissions a pentest as one input. The review reasons about the whole system; the pentest demonstrates one breach.
• Threat model is the structured artefact a design review produces: the catalogue of assets, attackers, and mitigations. The review is the activity; the threat model is one of its outputs, revisited each time the design moves.
• Security audit🛃Security AuditComplianceA security auditView reference → is external and verifies compliance against a standard for a third party. A review is the team's own assessment for its own assurance, with no certificate at the end and far more freedom in what it examines.

In the graph

In the Unified Product Graph, a security review sits in the security region as the assessment activity. The product connects through product_reviewed_by_security_reviewProductreviewed bySecurity Reviewhierarchy, recording that an assessment happened against this specific system. The review is governed from above by security_policy_schedules_security_reviewSecurity PolicyschedulesSecurity Reviewhierarchy, which ties the cadence of review to the written policy that demands it rather than to anyone remembering. When a review needs🫀NeedUserA user need, pain, desire, or constraintView reference → harder evidence, security_review_commissions_penetration_testSecurity ReviewcommissionsPenetration Testhierarchy links it to the test it triggers, so the chain from policy to review to proof is one connected path the graph can walk.