Tie each security assertion to a tested boundary
What This Concept Is
Security review maps selected risks to implemented controls and evidence. It is scoped verification, not a claim that an application is secure in every possible way.
Why It Matters Here
The capstone’s SSDF/ASVS matrix must expose untested controls rather than treating a checklist as certification.
Concrete Example
For two tenants, create a record as tenant A, prove A can read it, then attempt the same read as B and unauthenticated. Include export and background-worker paths if they can reach the record. A denied UI link alone does not prove API authorization. Record identifiers, expected result and redacted actual response.
Common Confusion / Misconception
A scanner pass does not establish business authorization or recovery. A requirement marked not applicable needs a reason tied to the system boundary, not a desire to shorten the audit.
How To Use It
Pin the framework version, select relevant requirements, map each to code/config and observed tests, and record gaps/owners. Keep secret rotation, supply-chain and telemetry evidence linked rather than copied.
Check Yourself
Which alternate path bypasses the UI? What positive control rules out deny-all? Which requirement remains untested?
Mini Drill or Application
Choose one high-risk access control and one input or session control. Run positive/negative cases and have a reviewer challenge the scope.
Read This Only If Stuck
Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.