Exception model
Why waivers in the firewall are scoped to one rule, carry a reason, and expire on their own.
Every blocking policy eventually collides with a legitimate need: a security patch younger than your delay window, a vulnerable version with no upgrade path that your code cannot trigger. The failure mode of most policy systems is what happens next: the rule gets widened, or the policy gets bypassed, and either way the control quietly erodes. Exceptions are the firewall's designed answer. For the step-by-step, see Manage exceptions; this page is why they work the way they do.
An exception belongs to one rule
An exception is attached to a single rule and consulted only after that rule's selector has matched. If the exception's own selector also matches, the rule is skipped for that request; every other rule still runs.
This is the property that makes exceptions safe to grant. Waiving the vulnerability rule for one package does not exempt it from the malware rule, the delay rule, or anything added later. There is no "allowlist this package everywhere" primitive, deliberately.
Scope is a selector
The exception's selector has the same shape as a rule selector, so scope is expressed in the same vocabulary: package name, version, upstream, wildcards. The narrower the selector, the smaller the hole. lodash at 4.17.20 is a decision about one artifact; lodash at any version is a standing exemption that outlives the situation that justified it.
Expiry makes waivers temporary
An exception can carry an expiry timestamp. Once it passes, the exception stops matching and the rule's block returns, with no cleanup task, no review meeting, no one having to remember. If the need persists, someone has to actively renew the exception, which is exactly the review point you want.
The alternative, permanent waivers that someone intends to revisit, is how policy systems accumulate silent holes. Prefer short expiries and cheap renewals.
Reasons make the log auditable
Every exception records a reason from a fixed vocabulary (not_exploitable, no_upgrade_path, evaluating_component, and so on; the full list is in the reference) plus free-text notes. When an exception allows a request through with logging enabled, the log entry carries the exception ID.
Together these answer the auditor's question, why was this blocked package allowed, from the log alone: which rule was waived, on what grounds, by which exception, until when.
From block to exception
A block is not a dead end but a request for a decision:
The developer never needs registry bypass rights, and the policy owner never needs to weaken a rule to unblock one team.
Related
- How-to: Manage exceptions
- Reference: Exceptions
- Concept: Rule evaluation
Deployment models
The two ways to run the Bytesafe Dependency Firewall, SaaS or self-hosted on your own infrastructure, and what changes between them.
Execution phases
What each execution phase sees during an install, and why filtering versions keeps builds running while download rules are the hard stop.