A registry proxy catches the moment of download. CI scanning runs after a package has been resolved and often installed. The proxy therefore covers developer laptops, ad hoc installs, and install time code execution on any machine that points at it, none of which a pipeline scan can see.
Definition
A registry proxy is a service that sits between clients (developers, build runners, containers) and a public package registry. Clients ask the proxy for packages. The proxy fetches, caches and can apply rules before it hands anything back. Those rules can include blocking known malicious packages, blocking versions with serious advisories, or holding very new releases.
What CI scanning cannot see
CI scanning reads a manifest or lock file and compares it against vulnerability data. That is useful, but it has built-in limits.
- It runs after the install. In a typical pipeline, the install step comes first and the scan second, or the scan reads files while the install has already happened.
- It only covers the pipeline. A developer who runs an install on a laptop, tries a package in a scratch folder, or follows a tutorial is outside the pipeline.
- It leans on known data. A package that is malicious but not yet in any advisory database passes a vulnerability scan.
npm documents that scripts in a package can run during install, and that a config option can stop npm running scripts specified in package.json files. pip's documentation says that by default it involves running arbitrary code from distributions and does no check against remote tampering unless you enable hash checking. Both point to the same fact: the install itself is an execution point.
What a proxy adds
| Question | CI scan | Registry proxy |
|---|---|---|
| Is this package blocked before it reaches the machine? | No | Yes |
| Does it cover laptops and scratch projects? | No | If they use the proxy |
| Can it hold back brand new releases? | Only by policy in CI | Yes, centrally |
| Does it show one inventory of what was fetched? | Per pipeline | Across all clients |
| Does it know how your code uses the package? | Yes, with the right tool | No |
The last row matters. A proxy sees requests, not your code. It cannot tell whether a vulnerable function is reachable. Pair it with analysis in CI or on the pull request.
What a proxy costs
- Someone has to run it and keep it available. If it goes down, installs stop.
- Developers need a configured client. Without that, they can bypass it.
- Rules need an exception path, or people will route around it. See what to do when the proxy blocks a package.
A practical combination
- Proxy for download time decisions: malicious packages, severe advisories, very new releases.
- Pull request check for what is changing now.
- Build scan of the full resolved tree with the result stored.
- Scheduled re-scan for advisories published after release.
For a worked example of the cooldown idea, see minimum release age policies for new package versions.
Where Safeguard fits
Safeguard handles the analysis stages described here: dependency scanning, SBOM generation, reachability analysis and gates that can block a pull request. Try the free scan at gold.safeguard.sh/scan to see your current dependency picture.
Quick check
Does a proxy replace a vulnerability scan?
No. It controls what gets fetched. You still need scanning of the resolved tree and re-scans over time.
What if developers bypass the proxy?
Set the registry in a committed project config and block direct registry access from build runners. Without that, the proxy is a suggestion.
Sources
- npm Docs, config: ignore-scripts
- pip documentation, Secure installs
Last reviewed: 19 October 2026.
