When a registry proxy blocks a package, the developer should see a clear reason, a way to request an exception, and a fast decision from a named approver. The exception should expire and be recorded. If any of those is missing, people will route around the proxy and the control quietly stops working.
Why the exception path is the real product
Blocking rules are easy to write. The part that decides whether the control survives is what happens on the day a developer needs a package that is blocked. If the answer is "open a ticket and wait three days", they will find another route: a personal laptop, a mirror, a vendored copy.
The workflow in six steps
- Explain the block at the point of failure. The error should name the package and version, the rule that fired, and where to ask for help. "403 forbidden" is not an explanation.
- Offer the safe alternatives first. If a fixed version or a different package exists, say so in the message.
- Make the request short. Package, version, why it is needed, what it will be used for, and who is asking.
- Route to a named approver with a response target. State how fast you aim to reply and keep to it.
- Grant narrowly. Allow a specific version for a specific project, not the package everywhere.
- Set an expiry and record it. Every exception gets a review date. Keep the decision, the reason and the approver in one log.
What the approver should check
| Check | Question |
|---|---|
| Reason for the block | Is it a known vulnerability, a malicious report, a licence rule or a new release hold? |
| Reachability | Is the affected code used in this project? |
| Alternatives | Is there a patched version or a replacement? |
| Blast radius | Where will it run: a test tool or a production service? |
| Compensating controls | Can the exposure be reduced, for example by isolating the job? |
A block caused by a malicious package report should almost never be excepted. A block caused by a new release hold may only need a short wait or a manual review of the changelog.
Common mistakes
- Global allow after one complaint. It turns a narrow exception into a rule change.
- No expiry. Exceptions pile up and become the actual policy.
- No feedback to the rule owner. If the same package is excepted ten times, the rule is probably wrong. Review frequent exceptions monthly.
- Approver is a single person. Name a backup.
Measuring whether it works
Track how many requests arrive, how long decisions take, and how many requests are repeats. Do not invent targets from other companies. Set your own after a month of data. A rising repeat rate means rules need tuning, and a falling request rate with rising direct registry traffic means people are bypassing.
For the underlying quarantine steps, see malicious package quarantine procedures.
Where Safeguard fits
Safeguard provides dependency scanning, SBOM generation, and policies and gates that you can tie to an exception process, plus a free scan at gold.safeguard.sh/scan.
Quick check
How long should an exception last?
As short as the need allows, with a review date. Pick a period you will actually review.
Who should approve exceptions?
Someone who understands both the risk and the project, with a named backup. Avoid having the requester approve their own.
Last reviewed: 19 October 2026.
