Record every exception against a specific package URL and version range, with an owner, a reason and an expiry date. Then an SBOM diff can reopen it automatically when that component changes version, and an expiry check can surface it when time runs out.
The problem with free text exceptions
An exception written as "ignore the log library finding" has no end and no edge. Which version? Which service? Who agreed? Months later the library is upgraded, the finding changes, and the exception still silences something else. Exceptions without structure become permanent holes.
What a good record contains
| Field | Purpose |
|---|---|
| Package URL | Exact identity of the component |
| Version or range | The versions the decision applies to |
| Service or product | Where it applies |
| Finding or rule | What is being accepted |
| Reason | Why, in plain words, such as not reachable |
| Owner | A named person or team |
| Approver | Who accepted the risk |
| Expiry | A date after which it must be renewed |
| Review trigger | Component change, new advisory detail |
How the diff helps
Run the exception check as part of the diff step:
- For each exception, look up the component in the new SBOM.
- If the version moved outside the range, close the exception and re-evaluate the finding.
- If the component was removed, mark the exception retired.
- If the version is unchanged, check the expiry. Past it, flag for renewal.
- If a new finding appears on the same component, do not let the old exception cover it. Exceptions apply to named findings.
Choosing expiry periods
Match the period to the risk. Higher severity or broader exposure should get shorter exceptions. There is no universal number. Set a default, allow shorter, and require an approver for longer. Review the whole list on a regular schedule so renewals are decisions, not reflexes.
Reason fields worth standardising
Use a short list: not reachable, mitigated by another control, no fix available, fix scheduled, accepted business risk. A fixed list lets you count and sort. Reachability evidence strengthens the first reason, since "the vulnerable function is never called" can be checked rather than asserted.
For vulnerabilities that do not affect a product, a VEX statement is the standard way to record and share the conclusion, and it keeps the justification attached to the component.
What to avoid
Do not allow exceptions on a whole package family or on a severity level. Do not let the approver and the requester be the same person. Do not store exceptions only in a chat thread.
Audit view
Auditors like a list showing each exception, its owner, approver and dates, and evidence that it was reviewed. If the data is structured, that report is a query.
Safeguard applies policies and gates over component data and offers compliance and evidence automation, which suits keeping exceptions with their reviews. The free scan gives a first look at a project.
Quick check
Should an exception survive a version upgrade?
No. Tie it to a version range so an upgrade reopens the decision.
Can the requester approve their own exception?
They should not. Separate requester and approver.
Last reviewed: 19 October 2026.
