Thirty days after a release, review four things: new advisories against what you shipped, what the logs and monitoring show, whether accepted risks are still acceptable, and whether any checks were skipped. A 30 minute review catches the problems that appear only after real use.
Why look back at all
A release passes its checks on the day it ships. After that, the world changes. New vulnerabilities are published for components you already shipped, users do things you did not test, and risk acceptances age. NIST's Secure Software Development Framework reflects this in its vulnerability response practices: it asks organizations to continue to identify vulnerabilities, assess and prioritize them, and analyze their root causes to improve the process.
The checklist
| Area | Question |
|---|---|
| New advisories | Has anything been published against a component in this release? |
| Monitoring | Are there unusual errors, denied requests or spikes? |
| Risk acceptances | Are the review dates still ahead, and are the reasons still true? |
| Skipped checks | Did we waive anything at release that needs closing? |
| Support and feedback | Did customers report anything that smells like a security issue? |
| Evidence | Are the release scan results and approvals saved? |
New advisories
Compare the release's software bill of materials against current advisories. A component that was clean at release can have a new issue a week later. Prioritize by whether the vulnerable code is actually used, and by whether the issue is known to be exploited.
Monitoring
Look at error rates, authentication failures and denied requests since release. You are looking for patterns that differ from the previous version, not for perfect numbers.
Risk acceptances
Open every accepted risk tied to this release. If the review date has arrived or the reason has changed, decide again. Extend, fix or escalate.
Who runs it
The tech lead or release manager, with the product owner for risk decisions. Keep it to 30 minutes and a single page of notes. Ask a security representative to join only if there are open findings.
Steps
- Pull the release's SBOM and scan results.
- Re-run the scan against current advisories.
- Review monitoring from the first month.
- Walk the open risk acceptances.
- Close or create backlog items for each finding, with an owner.
- Record what you learned for the retrospective.
Feed it back
The SSDF root cause practice, RV.3, asks organizations to review the SDLC and update it where appropriate so a root cause does not recur. If the 30 day review keeps finding the same kind of miss, change the definition of done or the pipeline, not just the code.
What this review is not
It is not an audit, and it is not a replacement for continuous monitoring. It is a calendar prompt that makes sure someone looks. Continuous checks should still raise new advisories as they appear, and this review confirms that they did.
Safeguard offers continuous monitoring of dependencies and SBOMs, so new advisories against a shipped release can be surfaced between reviews. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a component that passed at release can raise a new alert later.
Quick check
Why 30 days and not 7 or 90?
Thirty days is a practical default: enough time for real usage and new advisories, short enough that fixes are still cheap. Adjust it to your release cadence.
Can automation replace the review?
Automation should raise advisories continuously. The review checks that it did, and covers judgement items such as risk acceptances and skipped checks.
Sources
Last reviewed: 19 October 2026.
