The finding that was silenced, not triaged.
NIST SP 800-218, the Secure Software Development Framework (SSDF) v1.1, asks software producers under PW.7 to review and/or analyze human-readable code to identify vulnerabilities and verify it meets security requirements. It has two tasks. PW.7.1: decide, as the organization defines it, whether code review (people), code analysis (tools) or both are used (the examples point to a risk-based choice of which code gets which). PW.7.2: perform the review or analysis against the organization's secure coding standards, and record and triage every issue found, with its recommended remediation, in the team's workflow or issue tracker.
The second half of PW.7.2 is the part that breaks quietly. Analysis tools are easy to run and easy to silence, and an inline suppression turns a finding into nothing: no record, no triage, no remediation.
The shapes the same control failure takes.
PW.7 weakens when review or analysis still appears to run, but its output stops reaching anyone. The recurring shapes:
A finding is suppressed inline
A code-analysis warning is silenced with an inline disable comment so the check passes, and the issue is never recorded or triaged anywhere.
Analysis stops covering new code
An exclusion, a path filter or a language setting leaves a new directory, service or language out of analysis, so the code most likely to be unreviewed is also unanalyzed.
The baseline swallows new issues
The analysis baseline or allowlist is regenerated in a change, and new findings are absorbed into it as if they were accepted debt.
Review is bypassed for a class of change
Bot, agent or generated-code pull requests are exempted from the review or analysis the organization decided under PW.7.1 applies to them.
High-risk code gets the lightest review
Authentication, cryptography or payment code changes merge on the same single approval as a copy edit, where the organization's own PW.7.1 decision called for deeper review.
A command-injection warning, suppressed inline.
An internal document-conversion endpoint shells out to a converter, and the security lint rule for child processes flags it. The pull request is blocking a release, so the author adds a disable comment with a note that it is internal only. The endpoint takes the file name from the request body.
+ import { exec } from "node:child_process";+ // eslint-disable-next-line security/detect-child-process -- internal only+ exec(`convert ${req.body.file} /tmp/out.pdf`);The analysis flagged this call and the change silences the warning instead of fixing or recording it. The file name comes from the request body and is interpolated into a shell command, so a crafted name runs arbitrary commands on the server; internal-only reduces who can reach it, not what it can do. PW.7.2 expects issues found by review or analysis to be recorded and triaged with a remediation, and an inline suppression leaves no record at all. Call the converter with an argument array (execFile) and a validated path, and if a suppression is ever warranted, record it in the tracker with its reason.
Security reading of the same pull request
heygrc reviews this pull request against PW.7. Aevral, an AI security reviewer from the same company, reads the same diff for security flaws such as command injection, and posts them on the pull request as leads with evidence.
What that contributes to PW.7: automated analysis of each change it reads, one input to PW.7.2. It does not decide which code gets review under PW.7.1, and does not record and triage findings in your tracker. Aevral reads source, not running software, so PW.8 testing of executable code is not covered. At most two findings per review.
PW.7 is shown with records, not with a tool list.
SSDF is attested to, not certified, so the questions come from customers, assessors and your own internal review: which code gets review or analysis and who decided, what the last few months of findings were, and how each was triaged. A tool that runs on every pull request answers the first half. The second half is the record: findings with a disposition and a remediation. An inline suppression that was never logged is the kind of gap that surfaces when someone compares the suppression comments in the code with the triage records, and it started as a one-line diff.
A review, not your review policy.
heygrc flags changes that stop review or analysis from producing a record and cites the practice so the fix happens in the pull request. It does not decide which code needs review under PW.7.1, keep your issue tracker, or sign an SSDF attestation. Available when NIST_800_218 is selected in org config.