Before a release, check seven things in the SCA report: the scan is fresh and matches the release lockfile, no known exploited findings are open, reachable runtime findings have a fix or a recorded decision, exceptions have owners and dates, and the report covers every service in the release. Anything else is a note, not a blocker.
Why a short checklist
Release time is the worst moment to read 200 findings. A checklist replaces judgment under pressure with decisions made earlier. The aim is to block on a small, defensible set of conditions and to record everything else.
The checklist
- Fresh scan. The scan ran against the exact commit and lockfile being released. The npm documentation notes that without a lockfile, results may differ on every run because the tree is rebuilt each time, so a scan not tied to a lockfile is weak evidence.
- Full coverage. Every service in the release appears in the report.
- No open known exploited findings. CISA's catalog lists vulnerabilities with reliable evidence of active exploitation and a clear remediation action. If one is present in released code, fix it or document the mitigation.
- Reachable runtime findings handled. Each has a fix, a mitigation or a recorded acceptance.
- Exceptions recorded. Every accepted finding has an owner, a reason and a review date.
- No new findings from the change. Compare to the previous release report and explain each new finding.
- Container images scanned. The image that ships was scanned, not just the source.
Go and no-go rules
| Condition | Decision |
|---|---|
| Known exploited and reachable, no mitigation | No-go |
| Reachable runtime, fix available and low risk | Fix before release |
| Reachable runtime, no fix, mitigation in place | Go with record |
| Not reachable or development only | Go, schedule the fix |
| Scan older than the release commit | Rescan first |
Adapt the table to your own risk tolerance and write it down so it is applied the same way each time.
Automate what you can
A gate in the pull request or pipeline can enforce items 1, 3 and 6 without a meeting. The npm documentation notes its audit command can use an audit level setting so that a failure threshold applies in continuous integration, and that this option changes the failure threshold without filtering the report output. Whatever tool you use, keep the threshold visible and the exceptions logged.
After the release
Keep the report with the release record. If an advisory lands next week for something you shipped, the saved report tells you immediately whether you are affected.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate decides to pass or block based on scan results.
Where Safeguard fits
Safeguard's policies, gates and guardrails can enforce these checks in the pipeline, with evidence retained for later review.
Quick check
Should every high severity finding block a release?
Not automatically. Block on exploited and reachable conditions, and record the rest with owners and dates.
Is a scan from last week acceptable?
Only if the lockfile and code have not changed. Otherwise rescan against the release commit.
Sources
Last reviewed: 19 October 2026.
