Expire Dependency Risk Exceptions
Set a time limit and recheck trigger for dependency waivers so temporary risk decisions do not become permanent defaults.
A dependency exception records why a known risk cannot be removed immediately. It is not the same as closing an alert. Without an expiry and owner, a temporary decision can survive long after the affected code or available fix changes. OWASP dependency guidance supports assessment and remediation. Use the exception to make the remaining exposure visible and reviewable.
Exception record
| Field | Required decision |
|---|---|
| Advisory | Identifier, package, ecosystem, affected version |
| Deployment | Service, artifact digest, environment |
| Reason | Specific blocker to remediation |
| Exposure | Reachable path and affected data |
| Control | Temporary reduction or detection measure |
| Owner | Person who can change the dependency |
| Expiry | Date and recheck trigger |
| Evidence | Tests, inventory, and approval |
Do not grant an exception because a package is only transitive. Trace the resolved path and the deployed version. If you claim the vulnerable function is unreachable, record the code path and test evidence that support that claim. An absent exploit report is not proof of non-reachability. Keep the replacement or upgrade task linked to the exception.
Review and close
At expiry, refresh the advisory range, fixed version, deployed artifact, and exposure. Check whether a parent dependency, override, or replacement now unblocks the fix. If the exception must continue, require a new explicit approval with updated evidence and a new date. Do not silently extend the old record. Trigger early review after a new exploit notice, exposure change, major release, or control failure.
Close the exception only when the deployed artifact no longer has the affected component or when evidence shows the alert does not apply. Keep the before-and-after lockfile or software inventory, test results, and reviewer decision. If a compensating control is removed, reopen the review. The record should tell an on-call engineer what remains risky today, not merely why a team deferred work months ago. Send an owner reminder before expiry so the review can include current deployment evidence.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.