A break-glass route is a temporary, logged way to reach a public registry directly when the mirror cannot serve a need. Make it time-limited, granted to a named person, run from a controlled environment, and reviewed afterward. If it is easy and silent, it becomes the normal path.
When you need one
If your build network blocks direct access to public registries, two situations will come up. The mirror is down during an urgent release, or a developer needs a package that has not been through intake and cannot wait. Without a defined route, people will punch holes in the network or install from personal machines.
Design principles
- Time-limited. Access expires on its own, within hours.
- Attributed. Every use is tied to a person and a reason.
- Contained. It runs in a specific environment, not on the general build fleet.
- Logged. Requests and downloads are recorded.
- Reviewed. Someone looks at each use afterwards.
A workable flow
| Step | Detail |
|---|---|
| Request | A developer opens a ticket with the reason and package names |
| Approve | A named approver, not the requester, grants a time window |
| Fetch | The download happens in an isolated environment that can reach the registry |
| Inspect | The fetched files are scanned and recorded before use |
| Import | The vetted artifact is imported into the mirror, not carried around |
| Close | The window expires, the ticket gets a review note |
The key move is the import step. The goal of break-glass is to get a package into the controlled path, not to leave a side channel open.
What to log
- Who requested and who approved.
- Package names, versions and file hashes.
- Start and end of the access window.
- What the scan showed.
- Whether the package was imported or discarded.
Treat a break-glass event as a signal
A single use is normal. A pattern is information.
- The same package requested repeatedly means it should go through standard intake.
- Many requests during mirror outages mean the mirror needs better availability. A related guide covers keeping builds running during a registry outage.
- Requests clustered around one team mean they are missing something in the approved list.
Test the route before you need it
Run a drill each quarter. Ask a volunteer to request access for a harmless package, walk it through approval, fetch, inspection and import, and time each step. Drills reveal broken credentials, unclear ownership and approvers who are on leave, and they are far cheaper than discovering those during a mirror outage. Record the result alongside your other intake evidence.
Avoid these shortcuts
- A shared credential that is always on.
- A developer VPN profile that skips the proxy.
- Approving by chat message with no ticket.
- Granting access with no end date because "we may need it again".
Where Safeguard fits
Safeguard's SBOM and dependency scanning can inspect what came in, and its policies and gates help ensure that only vetted components reach release. See what a scan returns with the free scan.
Quick check
Should break-glass access ever be permanent?
No. A permanent route is just a second front door.
Can the developer who needs the package approve their own access?
No. Keep requester and approver separate, even in a small team.
Last reviewed: 19 October 2026.
