Dependency pinning
Pin every dependency by hash and serve it from a mirror that you control. In the mini board the mirror kept 100 percent of 400 fetches/s working through a 20 s registry outage, and 0 unreviewed versions entered a build.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | Version ranges from the public registry | Pinned hashes from a private mirror |
|---|---|---|---|
| Throughput (Unreviewed) | none | 13 req/s Fail | 0 req/s Pass |
| Availability (Pinned) | at least 99% | 66.7% Fail | 100% Pass |
| p99 latency (Pinned) | under 1 s | 600 ms Pass | 31 ms Pass |
| Monthly cost | 16 USD/mo | 32 USD/mo | |
| Error rate | 33.3% | 0% |
Key numbers
| Number | Value |
|---|---|
| Mirror read, median | 0.1 ms |
| Reads per second, one mirror | 100,000 ops/s |
| Public registry call, median | 150 ms |
Separate reader · 0 of 100 attacks reach a tool
How it works
Your software is mostly other people's code. A build fetches hundreds of packages. If an attacker takes over a popular package and publishes a poisoned version, a build that accepts any new version pulls it in. With version ranges, a takeover can reach your build within minutes.
Pinning fixes the version and the content. You record the hash of each package that you have reviewed. A changed file has a different hash, so the build rejects it. A new version enters only after a person reviews it and updates the pin.
Pinning alone does not solve availability. If builds fetch from the public registry, they still fail when it is down. In the mini board CI fetches 400 packages/s, and the registry is down from 0:20 to 0:40. Builds need 99 percent availability.
A private mirror solves both. It holds the pinned, reviewed packages, and CI fetches only from it. The mirror serves the files from its cache, so builds keep running through the outage. With the mirror, 100 percent of the fetches work, and 0 unreviewed versions enter a build.
The mirror becomes a part that you must run and protect. Check signed build records on the way in, and keep the list of pins in version control.
In the levels you choose the dependency policy and check the count of unreviewed versions.