A worked example. Nothing here belongs to you — start your own assessment to see yours.
198 weight covered221 weight not covered
Do we have the necessary security controls everywhere we need them?
Are those controls actually effective, or do scanners just run alongside?
Has this become a governable, measurable, continuously improved process?
NIST SSDF and OWASP SAMM as views over the same controls — nothing here is recomputed.
10 requirements were assessed of 19. The percentage is over those and nothing else.
NIST · version 1.1
| Requirement | Status | Controls |
|---|---|---|
| PO.1 Define Security Requirements for Software Development | 0% | 1 of 3 controls counted |
| PO.2 Implement Roles and Responsibilities | beyond your profile | 2 controls, none counted |
| PO.3 Implement Supporting Toolchains | beyond your profile | 1 control, none counted |
| PO.4 Define and Use Criteria for Software Security Checks | beyond your profile | 4 controls, none counted |
| PO.5 Implement and Maintain Secure Environments for Software Development | 50% | 2 of 3 controls counted |
| Requirement | Status | Controls |
|---|---|---|
| PS.1 Protect All Forms of Code from Unauthorized Access and Tampering | beyond your profile | 2 controls, none counted |
| PS.2 Provide a Mechanism for Verifying Software Release Integrity | beyond your profile | 3 controls, none counted |
| PS.3 Archive and Protect Each Software Release | beyond your profile | 3 controls, none counted |
| Requirement | Status | Controls |
|---|---|---|
| PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks | 50% | 2 of 4 controls counted |
| PW.2 Review the Software Design to Verify Compliance with Security Requirements and Risk Information | 100% | 1 of 2 controls counted |
| PW.4 Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality | 83% | 3 of 7 controls counted |
| PW.5 Create Source Code by Adhering to Secure Coding Practices | 0% | 1 of 6 controls counted |
| PW.6 Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security | not measured here | nothing maps |
| PW.7 Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements | 92% | 6 of 9 controls counted |
| PW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements | 28% | 6 of 11 controls counted |
| PW.9 Configure Software to Have Secure Settings by Default | not measured here | 2 controls, none counted |
| Requirement | Status | Controls |
|---|---|---|
| RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis | 72% | 3 of 8 controls counted |
| RV.2 Assess, Prioritize, and Remediate Vulnerabilities | 100% | 3 of 7 controls counted |
| RV.3 Analyze Vulnerabilities to Identify Their Root Causes | beyond your profile | 3 controls, none counted |
| CI Pipeline |
In place looks like The scanner holds valid test credentials, stays authenticated for the whole run, and its coverage report shows the pages behind the login.
| REST |
| Test |
| CI Pipeline |
In place looks like A harness drives the application's parsers and interfaces with generated malformed input on a regular run, and each crash is kept with an input that reproduces it.
| Test | any | Operate | Manual Review |
In place looks like A qualified tester works against the application on a defined cadence and after significant architectural change, with an agreed scope and a written report.
| CI Pipeline |
| Test | REST | Operate | Continuous Scan |
| Production | REST | Test | CI Pipeline |
| Production | REST | Operate | Continuous Scan |
In place looks like Endpoints are exercised with valid and with wrong identities to check authentication, authorization and input handling, driven from the current API specification.
Why it maps PW.8 exists to correct vulnerabilities before release; the gate enforces that outcome without adding test coverage.
