Safeguard
Security Guides•

How do I report a suspicious package I find in week one?

Found a package that looks malicious? Stop installing it, keep evidence, tell your security contact, and report it to the registry. Steps for new hires.

Safeguard Security Team
3 min read

Stop installing it, write down what you saw, tell your internal security contact, and then report it to the registry. For npm, open the package page and use Report malware. Report a plain vulnerability privately to the maintainers instead, since those are handled differently.

Malware or vulnerability?

The npm documentation separates the two. Malware in a package goes to the npm Security team. A vulnerability in a package is reported directly to the package maintainers, and the docs advise doing it privately. If the source is on GitHub, check the repository's security policy. You can find maintainer contact information with npm owner ls and the package name.

What to do in the first hour

  1. Stop. Do not run the install again or import the package.
  2. Note the facts. Package name, version, where you found it, and what looked wrong.
  3. Preserve evidence. Save the file listing or a screenshot. Do not execute the code to "see what it does".
  4. Tell your security contact. Internal first, because they know whether the package is already in your builds.
  5. Check where it landed. Search lockfiles and recent builds for the name. If your machine installed it, tell security before cleaning up, since credentials on that machine may need rotating.
  6. Report to the registry. Provide the details below.

What the npm report form asks for

The documentation lists: your name, an email the security team can use, the package name, the package version (include all affected versions), and a description of the malware and its effects, with references, commits or code examples that help researchers confirm it. After a valid report, npm Security removes the package, publishes a security placeholder and an advisory, and decides whether to ban the account.

Signs that deserve a report

  • A name one character off from a famous package.
  • An install script that downloads or runs something unexpected.
  • Code that reads environment variables or credential files for no clear reason.
  • A sudden new maintainer on an old package, combined with other oddities.

Any one of these is a reason to ask, not proof. When unsure, ask your security contact before reporting externally.

Make it easy to do

Put the reporting steps in your onboarding doc, with the security contact's name. A new hire who is afraid of embarrassment will stay quiet. Tell them a false alarm costs ten minutes and a missed one can cost far more. See our first-day checklist when a maintainer account is compromised.

Where Safeguard fits

Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a newly disclosed issue is matched to the software you actually run.

Quick check

Should I test the package in a sandbox to be sure?

Only if your team has a prepared, isolated environment and a process. Otherwise leave analysis to security.

Do I report before or after telling my manager?

Tell your security contact first. They will coordinate the external report and any customer impact.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.