Treat an unconfirmed compromise report as a hypothesis with a clock on it. Within 30 minutes, check whether you use the package and version, stop new installs of it, and decide whether it graduates to an incident. Do not rotate every secret on a rumor, and do not wait for an advisory to look.
Where these reports come from
Early warnings usually arrive as a post from a maintainer, a note from a researcher, or a message in a community channel. They often arrive before a formal advisory exists. GitHub's documentation on its advisory database is a useful reminder of how uneven the sources are: unreviewed advisories are published automatically from the National Vulnerability Database feed and are not checked for validity or completeness, while malware advisories come from the npm security team and the OpenSSF Malicious Packages repository. A missing advisory therefore means little in the first hours.
The 30 minute triage
- Write down the claim. Package name, ecosystem, affected versions if stated, the time of the report, and the link. Note who said it and whether they own the package.
- Search for use. Check lockfiles, SBOMs and built artifacts for the name. This answers the question that matters most: are we even exposed?
- If there is no match, log it and set a recheck. Add the name to a watch list and look again when the advisory lands.
- If there is a match, check versions. Compare your pinned version with the claimed range. A version outside the range is not cleared until the report is confirmed, but it is lower priority.
- Stop new installs of the suspect versions. A block at your mirror or a policy rule limits spread while you verify.
- Decide the state. Use the table below.
| State | Meaning | Next step |
|---|---|---|
| Watch | You do not use it | Recheck on a schedule |
| Hold | You use it, version not in the claimed range | Block new upgrades, keep verifying |
| Incident | You use a version in the claimed range, or an install happened in the window | Open the incident and run your dependency runbook |
What not to do yet
Skip these until you reach Incident state: mass credential rotation, public statements, and removal of the package from production. Each has a real cost, and the first two can create noise that hides the real signal.
Do not skip evidence collection. If a match turns up, preserve the lockfile, CI logs and build outputs before you clean anything. The guide on preserving evidence before cleaning up a supply chain incident covers what to keep.
Keep the reporter useful
Reply to the maintainer or researcher with thanks and a question or two, such as the exact versions and indicators they have seen. Do not argue about attribution in public threads. Ask what they would check next, and share your findings if they help others.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an early signal gets matched against what you run.
Quick check
Should I wait for an official advisory?
No. Run the search for use now. It costs minutes and tells you whether the advisory will matter to you.
When does a rumor become an incident?
When you find a claimed version in your lockfiles or artifacts, or evidence that a build installed it during the stated window.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
