A dependency vulnerability exception needs a specific affected component and scope, a reason the normal fix cannot yet land, a named decision owner, temporary controls, an expiry date, and a recheck that can end in a real decision. Keep the vulnerability's technical status separate from the exception. “Accepted until Friday” does not mean patched, not affected, or safe. At expiry, verify that the fix was deployed, renew with new evidence and approval, or escalate the unresolved risk. The answer changes if the package was never in the shipped product, a compensating control truly blocks the relevant path, or evidence of exploitation appears: those facts require a new assessment, not silent extension of the old note.
OWASP's vulnerable dependency management guidance recognizes that teams may accept a dependency risk after technical analysis and calls for an authorized risk owner to make that decision. NIST's patch management guide describes patching as identifying, prioritizing, acquiring, installing and verifying updates. A time-limited exception is the bridge between the current exposure and a verified resolution, not a replacement for either analysis or verification.
Illustrative case: a patch exists but breaks a required workflow
Illustrative case, with invented names, dates and advisory: Northstar Ledger uses invoice-parser@3.7.2 to ingest files supplied by business customers. Advisory DEMO-ADV-42 names that version as affected by a parsing flaw. An upgrade to 4.0.1 is available, but an authorized staging check shows it rejects an older invoice format still used by a major customer. The developer can adapt the importer, but estimates six working days. The service owner confirms the importer runs in production; the security engineer has traced a plausible customer-upload path but has not demonstrated exploitation or resolved every parser condition. The team cannot label the service unaffected.
The proposed temporary action is to restrict upload privileges to approved accounts, cap file size and processing time at an existing gateway, watch for abnormal parser failures, and complete compatibility work. Those controls may reduce risk, but their effectiveness must be checked. A gateway timeout may stop waiting for a response while parsing continues in the worker; record where CPU, memory and execution-time limits are actually enforced. If the precise flaw bypasses the controls, the exception needs a different plan or a release/feature restriction.
A filled exception record
Use a ticket or register that can retain revisions and evidence links. This is an example record, not a claim about a live system:
| Field | Filled example for Northstar Ledger |
|---|---|
| Exception ID and scope | DEP-EX-17; invoice import service, production release r211, invoice-parser@3.7.2 through the application lockfile. No blanket exception for other services or versions. |
| Advisory and technical status | DEMO-ADV-42 (illustrative); vulnerable version present; application exploitability under investigation. Link to the reviewed advisory and current lockfile evidence in the actual record. |
| Customer or business effect | A successful parser compromise could affect the import worker and the data it can access. Exact effect depends on the worker's permissions, still being verified. |
| Why immediate upgrade is blocked | Staging compatibility check rejects legacy invoices after moving to 4.0.1; importer adaptation assigned to the ledger team. |
| Temporary controls and evidence | Approved-account upload restriction; input size/time bounds; alert on parser failures. Service owner to show configuration at r211 and a controlled validation record. |
| Alternatives considered | Disable legacy imports now; adapt importer; upgrade plus compatibility shim. Product owner chose the temporary controls while adaptation proceeds, subject to security review. |
| Approving authority | Named risk owner under the organization's policy; AppSec provides technical analysis and does not self-approve a business tradeoff it lacks authority to accept. |
| Start, expiry and reminder | Starts 18 October 2026; expires 1 November 2026 at 12:00 UTC; review scheduled 29 October. These dates are illustrative. |
| Closure evidence | New resolved version in release artifact, compatibility check for both formats, security review of the original parser path, and deployment confirmation. A merged PR alone is insufficient. |
| Reopen triggers | Active exploitation evidence, advisory revision, newly exposed upload path, failed control, new affected service, missed delivery date, or changed worker privileges. |
The most important field is scope. If a second service uses the same package, this exception does not cover it until its own artifact, input path and owner are assessed. Nor does a valid exception become a “not affected” declaration. CISA's VEX guidance describes product-specific reasons for that declaration and cautions that status justifications are assertions a consumer may assess. Risk acceptance is a different decision: the team may believe the product is affected and still defer remediation within its policy.
Run the exception as a short workflow
- Confirm the subject. The AppSec lead pins the package name, ecosystem, resolved version, parent dependency path, service, release and advisory. Ask the release owner to verify what actually ships. If the package is absent, correct the inventory rather than opening an exception for a nonexistent exposure.
- Write the open technical question. State what is known about the vulnerable behavior and the application path. Record unknown deployment, configuration or attacker prerequisites. A source-traced path is not an executed exploit. The output is a risk description the decision owner can understand without pretending the analysis is complete.
- Assess choices and temporary controls. Ask the developer for the upgrade obstacle, alternative versions or a narrow code change. Have the relevant owner show that each claimed control applies to the path and is active in the target environment. A firewall rule in a diagram, for example, is not proof that the upload worker is protected by it.
- Get a decision from the right owner. The authorized risk owner decides whether the delay and residual risk are acceptable for the named scope and duration. The AppSec lead records technical dissent or uncertainty. A developer's inability to upgrade is a fact for the decision, not an approval by itself.
- Schedule the review before expiry. Assign a developer owner, a security reviewer and a calendar reminder. At the review, fetch a fresh advisory, dependency inventory, deployment record and control evidence. Record who must act if the exception expires and which workload restrictions they can apply; an expired ticket alone does not stop processing. CISA's Known Exploited Vulnerabilities catalog is one useful escalation input when a CVE is listed, but the team must still determine whether that CVE concerns its actual component and product. The catalog is updated over time; absence today is not a guarantee of no exploitation.
- Close, renew or escalate. Close the exception only after positive fix or non-applicability evidence. Renew only with a new reason, current controls, changed risk facts, new expiry and new approval. If neither is available at expiry, mark it expired and escalate under policy; do not auto-renew, hide the finding or relabel it fixed.
Read the exception as a dated dependency history
Continue Northstar's synthetic record rather than replacing its original approval. The dates, artifacts and outcomes below are invented to show the decisions the register must preserve.
| Date / record revision | New evidence | Decision and effect on the exception |
|---|---|---|
| 18 October / v1 | Parser 3.7.2 present; compatibility failure blocks 4.0.1 | Authorized owner accepts the named import scope until 1 November, with controls and unresolved applicability visible |
| 24 October / v2 | Compatible upstream parent release becomes available | Original “no compatible path” reason is obsolete; replace it with actual adaptation/release work and owner |
| 29 October / v3 | API artifact uses fixed parser; scheduled legacy worker still uses 3.7.2 | API task can close with artifact/deployment evidence; exception remains scoped to the worker |
| 30 October / v4 | Gateway size/time controls protect API upload, but worker reads files directly from an import bucket | Withdraw gateway controls from the worker's rationale; reassess residual exposure before expiry |
| 1 November, 12:00 / v5 | Worker still affected; no new approved acceptance | Mark expired and escalate; do not extend the date automatically |
| 1 November, 14:00 / v6 | Owner disables the legacy ingestion schedule and blocks new admissions while completing adaptation | Record precautionary containment and its evidence; package still present, not fixed |
| 3 November / v7 | Fixed worker artifact deployed; old attempts ended; legacy/new formats meet acceptance criteria | Close worker exception with positive evidence and retain the earlier expired interval |
The critical change is v4. “We have gateway limits” was plausible for the API and irrelevant to the worker's direct input path. Removing that claim makes the register more useful even though it makes the position less comfortable. A control belongs to a particular path and artifact, not to the package name globally.
At v5, the technical state remains “affected version present; exploitability under investigation.” The governance state becomes “exception expired.” At v6, containment changes the admitted workload but does not turn the dependency into a fixed version or a universal not-affected declaration. At v7, closure needs the full worker rollout, including scheduled launch configuration and remaining old attempts. A new API image from three days earlier cannot supply that evidence.
A renewal could have been valid if an authorized owner had approved a new, supported worker-specific rationale before expiry. That would be a new decision with its own duration and evidence. Here no such approval exists, so the history says so. Do not rewrite v1 to imply its controls always covered the worker.
The dependency-specific record should retain the parent package, resolved version, artifact identities, advisory revision, upstream-fix availability and deployment split alongside the approval history. That is what makes it different from a generic exception template and lets the next owner detect when the original obstacle has disappeared.
Make expiry actionable for the person on call
The reminder must say what decision is due and who can take it. “Exception expires tomorrow” is not enough when the assigned developer is away, the risk owner has changed roles, or a deployment spans several teams. In Northstar's record, identify a backup service owner and the operational action available if no renewal or verified fix exists. The response might be to pause legacy import admission while preserving already received customer files under the normal handling process. It should not depend on someone guessing which production switch the exception meant.
Before the review meeting, collect the specific evidence that can change the decision: the new parent package release, compatibility result, worker artifact, current launch configuration and status of older attempts. If one item is missing, name it. A long list of completed development tasks does not compensate for a missing deployment fact. Conversely, do not keep a resolved API exception open merely because an independent worker remains affected; narrow the record and make the remaining owner visible.
Treat changes to the temporary control as changes to the exception. If an account restriction is relaxed for a new customer, or the worker receives broader storage permissions, the original rationale may no longer describe the running service. The owner should compare the changed assumption with the approved scope before relying on the old expiry date. This avoids turning a time limit into permission for any intervening configuration.
After closure, retain a concise explanation of the blocked upgrade and what removed the obstacle. Northstar might learn that legacy-format examples were missing from the ordinary release process, or that the API and scheduled worker had different rollout owners. Those observations support a specific improvement: add the missing compatibility evidence or link both artifact owners in future dependency work. They are more useful than treating every exception as a failure or celebrating an expiry date that was repeatedly extended.
For the next blocked upgrade, copy the table and fill the missing fields before requesting approval. Use how to prioritize vulnerable dependencies in a real application to decide which exposure needs attention first. Use how to verify that a vulnerability was fixed in a new commit when the patch is ready for closure.