# Dependency monitoring | Precursor Intelligence

**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.

Canonical page: https://www.precursorintelligence.com/features/dependency-monitoring
Breadcrumb: [Home](https://www.precursorintelligence.com/) > [Features](https://www.precursorintelligence.com/features) > Dependency monitoring
Start free: https://www.precursorintelligence.com/register · Book a demo: https://www.precursorintelligence.com/contact

Over 5,300 bad packages tracked. Ten package ecosystems. Saved files kept under watch.

Example data on this page uses the fictional company Acme. The one matched package shown, @ctrl/tinycolor 4.1.1, is a real entry in our incident catalogue.

## Contents

1. [What do we watch?](#what-do-we-watch)
2. [How does a check work?](#how-does-a-check-work)
3. [What does a match tell you?](#what-does-a-match-tell-you)
4. [What if a package goes bad later?](#what-if-a-package-goes-bad-later)
5. [Questions](#questions)
6. [Related features](#related-features)

## 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.

**What we compare against:** over 200 known supply-chain incidents covering more than 5,300 hijacked or malicious packages in 10 package ecosystems. Each incident lists the open-source packages it affected, and every package in your file is checked against all of them.

Files you can upload or paste:

| File | Language | What it lists |
|---|---|---|
| `package.json` | npm | The packages your project asks for, by name and version range |
| `package-lock.json` | npm | The exact version of every package npm installed |
| `pnpm-lock.yaml` | npm | The exact versions installed by pnpm |
| `yarn.lock` | npm | The exact versions installed by Yarn |
| `requirements.txt` | Python | The Python packages your project installs, usually with versions |

## How does a check work?

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.

1. **Give us a file (any time).** Upload or paste a dependency file from your project, such as `package-lock.json`. It lists every package the project installs.
2. **Every package is checked (when you check).** We compare each package in the file with our catalogue of known supply-chain incidents.
3. **See what matched (on screen).** Any package that matches an incident is listed with the incident it belongs to. A clean file says so.
4. **Save it to keep watching (from then on).** Save the file to your projects. We keep checking it and tell you if a package you use is affected by a new incident.

Example (Acme): `acme-portal / package-lock.json`, 1,284 packages checked, one match: `@ctrl/tinycolor` at 4.1.1, a malicious release.

## What does a match tell you?

**Findings.** 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.

Example: `@ctrl/tinycolor` 4.1.1 matches the incident "Original Shai-Hulud npm worm" (critical, published 15 September 2025), a self-spreading worm released through hijacked package versions. Versions 4.1.1 and 4.1.2 were affected; earlier versions such as 4.1.0 were not. Moving to a clean version clears the match.

Looking for known flaws (CVEs) in the software you run, rather than tampered packages? That is [vulnerability management](https://www.precursorintelligence.com/features/vulnerability-management).

## What if a package goes bad later?

**Saved projects.** 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](https://www.precursorintelligence.com/features/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. See [how alerts work](https://www.precursorintelligence.com/features/alerts-and-reporting).

## Questions

### Which files can you check?

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.

### What do you compare my packages with?

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.

### Do you keep checking after the first time?

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.

### Do you need access to our code or repositories?

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.

### Can the alerts go to our own tools?

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.

## Related features

- [Vulnerability management](https://www.precursorintelligence.com/features/vulnerability-management): tell us the software you run and see only the known flaws that affect it.
- [Alerts and reporting](https://www.precursorintelligence.com/features/alerts-and-reporting): alerts by email, in the app or by webhook as soon as we spot something, plus PDF reports you can share.
- [Integrations](https://www.precursorintelligence.com/features/integrations): a REST API, webhooks, Tenable sync and scan-file upload to connect the tools you already use.
- [Threat intelligence](https://www.precursorintelligence.com/features/threat-intelligence): who targets businesses like yours, how they work and which flaws they use.
- [All features](https://www.precursorintelligence.com/features)

## Get started

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.

- Start free: https://www.precursorintelligence.com/register
- Book a demo: https://www.precursorintelligence.com/contact
- Nothing to install · Unlimited team members · Data stored in London · Two-factor sign-in for everyone