Put dependency risk in the register as a few scenarios, not as individual findings. For example, "an attacker exploits a vulnerable library in our customer facing service". Rate each scenario using whether the vulnerable code is reachable and exposed, assign an owner, and link the scan results as evidence.
Findings are not risks
A dependency scan can produce thousands of findings. Most describe a flaw in a library, not a consequence for your business. A register entry needs an asset, a threat, a weakness and a result. Findings supply the weakness and some evidence. They do not stand alone.
Group into scenarios
Useful groupings:
- By service. "Vulnerable third party code in the payments service."
- By exposure. "Internet facing services run libraries with known exploited flaws."
- By supply chain event. "A compromised package update enters our build."
- By end of life. "Components that no longer receive fixes sit in production."
Two to six scenarios usually capture a whole application estate.
Rate with evidence
Likelihood factors that change the answer:
- Is the vulnerable function actually called by your code, or only present in the tree?
- Is the service reachable from the internet or only from a private network?
- Is there known exploitation or a public exploit?
- Which compensating controls exist?
Impact factors: what data or function the service holds, and how many customers it touches.
Reachability analysis helps here because it separates flaws that your code can trigger from those that sit unused. The result is a shorter, more honest list.
Click through it at your own pace, or open it full screen.
Assign the owner
The owner is the engineering lead for the service, not the person running the scanner. They decide whether to upgrade, replace, mitigate or accept, and set dates. Link the register entry to the tickets that carry out the work.
Define the treatment and the evidence
- Reduce: upgrade the library, remove the unused feature, add a gate that blocks new critical issues.
- Avoid: drop the dependency.
- Share: rely on a vendor commitment where a supplier owns the component, and record the dependency.
- Accept: documented, dated, owned, with a review date.
Evidence can be a before and after scan, a pull request, or a policy configuration.
Where Safeguard fits
Safeguard can scan dependencies, build an SBOM, apply reachability analysis and enforce policies or gates, so findings arrive with context for the register entry. You can try a free scan at gold.safeguard.sh/scan. The register itself, the owners and the acceptance decisions stay your own.
Quick check
Should every critical finding be a register entry?
No. Group them under a scenario. Track individual fixes in your engineering backlog.
How often should this entry be re-rated?
At least quarterly, and after new exploitation reports, major releases or dependency changes.
Sources
Last reviewed: 19 October 2026.
