A useful entry names the component and version, the specific risk, the evidence for it, who owns it, the mitigation and its status, and a review date. Keep it to a few lines. An entry without an owner and a date is a note, not a control.
Why bother
Risks that live only in people's heads disappear when those people move teams. A short register lets a product manager answer questions from executives, customers, and auditors without a scramble, and it ties dependency worries to roadmap items.
The template
| Field | What to write |
|---|---|
| Component and version | Name, version, where it is used |
| Risk | One sentence, such as maintainer count, end of support, license change, known vulnerability |
| Evidence | Link to the advisory, release page, or project statement |
| Likelihood and impact | Simple low, medium, high with a reason |
| Mitigation | Wrapper, pin, upgrade, replacement, monitoring |
| Owner | A named person, not a team alias |
| Status | Open, mitigating, accepted, closed |
| Review date | When it will be looked at again |
| Related work | Link to the ticket or roadmap item |
Examples of good risk statements
- "Single maintainer, last release over a year ago, used in the export module only." This follows the maintenance checks in the OpenSSF evaluation guide.
- "Framework major version reaches end of security support on the date in the project's policy; migration needed." Under Semantic Versioning, the move is across a major boundary, so plan it as a project.
- "Component listed in the Known Exploited Vulnerabilities catalog; fixed version available." CISA describes the catalog as an input to prioritization.
Each states a fact, points at evidence, and implies an action.
Accepted risks need extra fields
If you accept a risk, add who accepted it, the reason, and an expiry. Acceptance without an expiry becomes permanent. A not affected statement is different: it says the vulnerability cannot be exploited in your product, and it should cite a justification such as the code not being in the execute path.
Keep it light
Review the register in a monthly meeting of fifteen minutes. Close entries when work finishes. Delete entries that no longer apply rather than letting the list grow into something nobody reads.
Quick check
How many entries are too many?
When the team stops reading them. Keep the list to risks that need a decision or an action.
Who should own an entry?
The engineer closest to the component, with the product manager reviewing.
Is a risk acceptance the same as a closed risk?
No. It stays open with an expiry until fixed or reviewed.
Safeguard's compliance and evidence automation and its dependency scanning can feed the evidence column, and the free scan is at gold.safeguard.sh/scan.
Sources
- OpenSSF Concise Guide for Evaluating Open Source Software
- Semantic Versioning 2.0.0
- CISA Known Exploited Vulnerabilities Catalog
- OpenVEX specification
Last reviewed: 19 October 2026.
