Is there bad code in what you build? Check every package.
Dependency monitoring checks the open-source packages your software is built on against a catalogue of known supply-chain incidents, where a package was hijacked or published to do harm. Upload or paste an npm or Python dependency file and see the result on screen. Save it and we keep checking it as new incidents appear. It is for any business that builds software.
What do we watch? Ten package ecosystems.
We track hijacked and malicious packages across npm, PyPI, NuGet, RubyGems, Cargo, Packagist, Go, GitHub Actions, Open VSX and Docker. Upload or paste a dependency file and we check every package in it.
- npm
- PyPI
- NuGet
- RubyGems
- Cargo
- Packagist
- Go
- GitHub Actions
- Open VSX
- Docker
Files you can upload or paste
- package.jsonnpmThe packages your project asks for, by name and version range.
- package-lock.jsonnpmThe exact version of every package npm installed.
- pnpm-lock.yamlnpmThe exact versions installed by pnpm.
- yarn.locknpmThe exact versions installed by Yarn.
- requirements.txtPythonThe Python packages your project installs, usually with versions.
How does a check work? Four steps, nothing to install.
There is no agent and nothing to add to your build. You give us the file, we compare it with what is known to be bad, and if you save it we keep comparing.
- Any time
Give us a file
Upload or paste a dependency file from your project. Your developers will know it: it lists every package the project installs.
- When you check
Every package is checked
We compare each package in the file with our catalogue of known supply-chain incidents.
- On screen
See what matched
Any package that matches an incident is listed with the incident it belongs to. A clean file says so.
- From then on
Save it to keep watching
Save the file to your projects. We keep checking it and tell you if a package you use is affected by a new incident.
What does a match tell you? Which package, and why.
A supply-chain attack does not break into you directly. Someone hijacks a package you trust, or publishes a harmful one, and it arrives with an ordinary update. A match shows you exactly where.
- The package and the version in your file, so your developers know what to change.
- The incident it belongs to, with when it was published and how serious it is.
- Hijacked and malicious packages both count: a trusted package taken over, or one made to do harm.
- Look it up from your own tools. The REST API and our MCP server can query the same incidents and affected packages.
Looking for known flaws (CVEs) in the software you run, rather than tampered packages? That is vulnerability management.
Supply chain · Incident catalogue · Ten ecosystems
What if a package goes bad later? We keep checking.
A clean result today is not a clean result for ever. New incidents are published all the time, often for packages that were fine yesterday. Save a file and we keep checking it.
- Checked again as new incidents appear, against every incident in the catalogue, including the newest.
- An email if a package you use is affected, sent to your team and your organisation's alert recipients.
- Or straight to your own systems by webhook, as JSON, filtered to supply-chain alerts if you like.
- Ask your AI assistant. Our MCP server can list your saved files and check your exposure to an incident.
We keep watching, and you hear about it as soon as we know a package you use is affected. How alerts work
Ongoing re-checks · Email · Webhook
You can upload or paste package.json, package-lock.json, pnpm-lock.yaml and yarn.lock for npm projects, and requirements.txt for Python projects. Every package in the file is checked against our whole catalogue.
A catalogue of known supply-chain incidents, where an open-source package was hijacked or published to do harm. It holds over 200 incidents covering more than 5,300 hijacked or malicious packages across ten package ecosystems, from npm and PyPI to NuGet, RubyGems, Cargo, Go and GitHub Actions.
Yes, if you save the file. We keep checking saved files, and you get an alert as soon as we know a package you use is affected by a newly published incident.
No. You upload or paste a dependency file and we read the package list in it. Nothing is installed and nothing connects to your code repositories.
Yes. Alongside the alert email, webhooks send JSON to a web address you choose, and can be filtered so that only supply-chain alerts are sent.
Know what is in your code. And hear if it goes bad.
Check every package in your dependency files against hijacked and malicious packages from ten ecosystems, then save them and we keep checking and tell you as soon as a package you use is affected.