Dependabot can now match dependencies against malware advisories collected by the OpenSSF malicious-packages project. The expanded data covers npm, PyPI, and additional ecosystems. Repositories that already enabled malware alerting receive the broader coverage automatically; other repositories must enable the setting.

A malware alert is different from a normal vulnerable-dependency notice. The question is not merely whether a patched version exists. You must determine whether the package executed, what credentials it could access, and whether the environment needs containment.

Quick answer

Enable malware alerts under repository or organization security settings. When an alert appears, freeze automated dependency changes, identify the first affected install, rotate exposed secrets, remove the malicious version, and rebuild from a trusted lockfile and clean cache.

# Find the resolved version and every dependency path that introduced it.
npm explain suspicious-package
npm ls suspicious-package --all

# Inspect lockfile history around the first appearance.
git log -S 'suspicious-package' -- package-lock.json

Do not begin with npm update. Updating may remove the package while leaving stolen credentials valid.

Turn on the right signal

In GitHub, open the repository or organization settings, go to Advanced Security and the Dependabot section, then enable malware alerts. Existing users can filter advisories with type:malware.

Confirm that security notifications reach an actively monitored team rather than one repository owner. Add an escalation route for production packages and a slower route for development-only tools. A build plugin can still read CI tokens, so “dev dependency” does not automatically mean harmless.

For organizations, document whether new repositories inherit the setting. Security controls that depend on someone remembering a setup page eventually drift.

Verify whether the package executed

Start with the affected version range and the lockfile. Determine whether the package was installed in developer laptops, CI, production images, or build containers. Look for install scripts, postinstall hooks, downloaded binaries, network requests, and files written outside the package directory.

Ask four concrete questions:

  • When did the affected version enter the lockfile?
  • Which jobs installed it without --ignore-scripts?
  • Which credentials were present in those jobs?
  • Which artifacts were built after that point?

Container image history, package-manager logs, CI timestamps, and artifact attestations can narrow the window. Absence from the final runtime image does not prove the build stage was safe.

Contain before repairing

If the package may have executed, treat accessible secrets as potentially exposed. Revoke or rotate npm tokens, cloud credentials, deployment keys, GitHub tokens, signing material, and third-party API keys according to the environment.

Pause release jobs that reuse the same credentials. Preserve logs before retention windows remove them. Block the package or version in dependency policy, then remove it from the lockfile using a reviewed change.

{
  "overrides": {
    "suspicious-package": "0.0.0-security-block"
  }
}

An override can prevent accidental reintroduction, but it is not a universal npm quarantine mechanism. Test the actual package-manager behavior and prefer an internal registry policy where available.

Rebuild trust from clean inputs

Delete dependency caches associated with the affected window. Reinstall from a reviewed lockfile on a clean runner, with lifecycle scripts restricted where practical. Rebuild artifacts and compare provenance, checksums, and expected files.

Do not reuse an image only because a scanner now reports no package. If a build secret was stolen, an attacker may have changed an external system rather than the image.

After containment, determine how the package entered: direct dependency, transitive dependency, typo, compromised maintainer, or automated update. That answer should change the prevention step.

Avoid unsafe automation

Automatically merging every Dependabot suggestion is not a malware response plan. Security updates should move quickly, but malware alerts need context that a version bump cannot provide.

Use automation to collect the dependency path, affected workflows, owners, and deployment history. Keep credential rotation and incident closure under human review. Close the alert only when the package is removed and the exposure question has an evidence-backed answer.

Primary references

The expanded advisory feed is useful detection, not automatic incident resolution. The valuable outcome is a short path from package alert to a verified answer about execution, credentials, artifacts, and recovery.