Proxy that filters high risk packages from registry.npmjs.org
$npm --registry https://strict.bytesafe.tech install
What is removed?
The proxy checks each version returned from the upstream registry against a few basic rules. While the rules are strict compared to common practice, the ruleset is not unreasonable. However most projects still break.
Vulnerabilities
Packages with known vulnerabilities of severity high or higher.
Pre-releases
All pre-release versions as defined by semver.org.
New releases
Packages released in the last 14 days - unless they are patches for known vulnerabilities.
Install scripts
of 423k versions seen
Frequently Asked Questions
Is this marketing?
Yes. We are building a Dependency Firewall that can be configured to do this kind of filtering and much more. Besides npm, we also support Maven, Nuget and PyPI. Learn more at bytesafe.dev
How does it work?
When npm installs a package it fetches a JSON document with all the available versions for the package. It then resolves a specific version locally before downloading the contents and updating the lockfile. This proxy filters the versions in the JSON before returning the document. All other type of requests are redirected to registry.npmjs.org.
Is this actually useful?
Sure. Test installing your existing project and see what breaks. Or use it as a quick sanity check when setting up a new project.
Should I use this for production builds?
No. It's a technology demo. It exists as a conversation starter about software supply chains, (the lack of) security practices, npm ecosystem security expectations and tooling.
What is the reasoning behind delaying releases?
Many critical vulnerabilities and malware attacks are found and fixed quickly, often within hours or days, by the community and security researchers. So letting the dust settle for a week or two before considering upgrading a dependency avoids a lot of headaches. As an application developer you very seldom need to be on the bleeding edge anyway. The exception is patches for vulnerabilities, which are let through without delay.
My project won't build!
We are not surprised, that is the point of the proxy. Most projects rely on many more risky dependencies than most developers realize.
Is the ruleset too strict to be used in practice?
Probably, unless you are starting a new project. But are the rules unreasonable? Should application developers rely on unreleased, or just released, dependencies? Vulnerable dependencies? Is running unsigned code automatically by just installing a package a good idea?
Better errors than 'not found' please!
Not really a question, but the proxy just removes the risky versions from the response. So npm might resolve a different version or, if no matching version was found, respond with 'not found'. You can check why versions of a specific package are removed here.
Nothing is removed when running 'npm ci'?
npm only resolves versions when running 'npm install'. When running 'npm ci' the package content is downloaded directly using the resolved versions from the package-lock.json file. Run 'npm install --registry https://strict.bytesafe.tech' to recreates the lockfile using versions available from the proxy.
What happens with the @latest tag?
If the version tagged with @latest is removed, the proxy tags the highest surviving SemVer version as @latest. This is fine for demonstration purposes, but may end up pointing to a less than ideal version (ex. the next major version). In our commercial product the tag is just removed in those cases. Production systems should never build against @latest anyway.