Scope a vulnerability exception to one finding, on one component version, in one asset and one environment. A waiver on a CVE across every repository quietly covers systems nobody reviewed, including ones created next year. Narrow scope keeps the approval honest and the exception easy to retire.
The blanket waiver problem
Many scanners let you ignore a CVE globally. It is fast. It is also the reason exception lists turn into places where risk goes to hide. The approver judged one service. The waiver now applies to forty, with different exposure, different data and different compensating controls.
The risk is not only today's assets. A new service that pulls in the same library inherits the waiver without anyone choosing to accept anything.
Four dimensions of scope
| Dimension | Narrow | Too broad |
|---|---|---|
| Finding | One CVE or advisory ID | A whole severity class |
| Component | Name plus exact version | Any version of the package |
| Asset | One repository, image or service | Every asset in the organization |
| Environment | Production only, or staging only | All environments |
If a finding appears in several assets, you can still decide the same thing for each. Do it as separate records or as one record with a listed set of assets. The list is the scope, and a new asset is not on it until someone adds it.
Write scope as data
Keep scope in fields a tool can check, not in a paragraph a reader must interpret:
- advisory or CVE ID,
- package URL with version,
- asset identifier,
- environment,
- exposure at approval time,
- expiry date.
A gate can then match a finding to an exception exactly. If any field differs, the exception does not apply, and the finding fails as normal.
Handle version changes
When a dependency is upgraded but remains vulnerable, the old exception should not silently carry over. Either the version in scope changes and the record is reviewed, or the exception ends. A version bump to another vulnerable release is a chance to fix, not to extend.
When broad scope is right
A few cases justify a wider net, such as a finding in a test-only fixture used across many repositories. Even then, state the reason, limit the duration, and name the paths in scope. The test is whether the approver would sign off if they saw the full list of assets.
Where Safeguard fits
Safeguard policies and gates evaluate findings per asset and component, and its asset discovery helps you find where else a component lives before you widen an exception.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how one component shows up in several places, which is exactly why scope matters.
Quick check
Is it ever fine to waive a CVE for the whole organization?
Rarely. If you do, list the assets covered at approval time, add an expiry, and require a new review for any asset added later.
What if the same exception applies to ten repositories?
Use one record with an explicit list of ten, or ten linked records. Either way each asset is named and reviewable.
Last reviewed: 19 October 2026.
