Grant the exception per service, because exposure differs by service, but link them under one parent record with a single fix owner and shared evidence. Each service team owns its own acceptance of the risk, while one named coordinator owns the shared upgrade plan.
The two failure modes
One giant exception for everyone. It hides the fact that some services are internet facing and others are not, and it expires for all at once.
Fifty unrelated exceptions. Each team re-does the same analysis, reaches different conclusions, and no one drives the fix.
The sensible middle is a parent and children.
Structure
| Level | Owner | Content |
|---|---|---|
| Parent tracking record | Coordinator, often platform or security | Advisory, library, fix plan, target version, shared evidence |
| Child exception per service | Service owner | Scope, local exposure, approver, expiry |
The parent answers "what is the plan?" The child answers "may this service keep running in the meantime?"
Steps
- Inventory affected services from your SBOMs or dependency data.
- Create the parent record with the advisory and fix options.
- Assess each service for reachability and exposure, using one shared method.
- Issue child exceptions only where needed, with the same maximum expiry.
- Drive the shared fix. One upgrade guide, one internal package version, one pull request template.
- Close children as services upgrade. The parent closes when the last child does.
Evidence you can share
The advisory details, the fix versions and the general analysis of the vulnerable function are the same for everyone. Put them on the parent. What differs is exposure and compensating controls, which go on the child. This saves a lot of duplicated writing and keeps the reasoning consistent.
Handling teams that disagree
Two teams may judge the same library differently, for example one says the function is unreachable while another calls it. That is fine, as long as each decision is evidence based. Use a common reachability check so disagreements come from facts, not opinions. See can reachability analysis justify a risk acceptance.
Escalation
Escalation keeps shared exceptions from drifting. Without a clear owner for the fix, each team waits for another to move first, and the exception quietly outlives its purpose.
If a service owner will not fix or cannot justify an exception, escalate to the approver for that service's risk tier. The coordinator reports aging by team. A shared dashboard helps, though see exception metrics: aging, renewals and coverage for pitfalls.
What the coordinator provides
- A tested upgrade path or internal patched build
- A message to teams explaining the risk in plain words
- A deadline and a review rhythm
- Fix pull requests where possible
Safeguard's autonomous remediation can open fix PRs across repositories (off by default, every category on Manual so your team approves), and its SBOM and dependency scanning show which services include the library.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how one component shows up across an inventory, which is the starting point for a parent record.
Quick check
Should every service have the same expiry?
Use the same maximum, but allow shorter terms for exposed services.
Who closes the parent record?
The coordinator, once every child exception is fixed or closed.
Last reviewed: 19 October 2026.
