npm Publish Security: Monitor and Audit Package Releases

Do you know who published your last package version? Supply chain attacks on npm packages are increasingly common. Monitoring publish activity helps you detect unauthorized releases quickly and maintain an audit trail for compliance.

In this guide:

Why Monitor OIDC vs Token Best Practices Audit Trail

Why monitor npm publishes?

npm package compromises have affected major projects like event-stream, ua-parser-js, and coa. In each case, attackers gained publish access and released malicious versions. Early detection is critical.

Detect unauthorized access

Know immediately when a version is published — especially if you didn't trigger it.

Verify automation

Confirm that CI/CD publishes are working correctly and using the expected method (OIDC).

Compliance requirements

Many security frameworks require audit logs of software releases.

Team visibility

Keep everyone informed about releases without checking npm manually.

OIDC vs token publishing

npm supports two authentication methods for publishing. Each appears differently in notification emails and has different security implications.

RECOMMENDED

Trusted Publishing (OIDC)

GitHub Actions, GitLab CI, or other CI providers authenticate directly with npm using short-lived tokens. No secrets to store or rotate.

In notification emails:

Published via OIDC by github:actions

Access Token

Traditional npm tokens stored as secrets. Can be used from CI or manually. Requires careful secret management.

In notification emails:

Published via token

⚠

A "via token" publish when you expect OIDC could indicate a stolen token or unauthorized access. Investigate immediately.

Security best practices

✓Use Trusted Publishing (OIDC) for CI/CD

Configure your GitHub Actions or GitLab CI to use npm's Trusted Publishing instead of storing tokens as secrets.

npm Provenance documentation →

✓Enable 2FA for all maintainers

Require two-factor authentication for everyone with publish access. For organizations, enforce this at the org level.

✓Use granular access tokens

When tokens are necessary, create tokens scoped to specific packages rather than using tokens with full account access.

✓Regularly audit maintainers

Check who has publish access to your packages:

npm access ls-collaborators <package>

Remove anyone who no longer needs access.

✓Monitor publish notifications

Don't ignore npm emails. Every publish should be expected. If you see one you didn't trigger, investigate immediately.

Maintaining an audit trail

npm notification emails contain valuable audit information, but they get buried in your inbox — especially if you maintain many packages or publish frequently.

npm notification email

Successfully published @acme/core@2.1.0
Package: @acme/core
Version: 2.1.0
Published: via OIDC by github:actions
Time: 2024-12-14 09:15:32 UTC

The problem: if you maintain 20 packages and do weekly releases, that's 80+ emails per month. Important security signals get lost in the noise.

Consolidate your audit trail

npmDigest aggregates all your publish notifications into a single digest email. See all releases at a glance, grouped by scope, with publishing metadata (OIDC, token, timestamps) preserved.

✓Daily, weekly, or monthly digest frequency
✓OIDC vs token clearly visible
✓Packages grouped by @scope
✓Export data as JSON for compliance

Start 14-day free trialOnly charged for months you use it

If you suspect a compromise

If you see a publish you didn't authorize, act fast:

Deprecate the suspicious version

npm deprecate <package>@<version> "Security issue - do not use"

2
Revoke all access tokens
Go to npmjs.com/settings/tokens and delete all tokens. Regenerate only what you need.
3
Audit maintainer access
Review who has publish access and remove anyone suspicious or unnecessary.
4
Publish a patched version
Release a new version that supersedes the compromised one.
5
Report to npm security
Email security@npmjs.com with details about the incident.

Frequently asked questions

How do I know if someone published to my npm package?

npm sends a 'Successfully published' email to all maintainers whenever a new version is published. This email includes the package name, version, and publishing method (OIDC or token). You can also check the package's version history on npmjs.com or use 'npm view <package> time' to see publish timestamps.

What is npm Trusted Publishing (OIDC)?

Trusted Publishing uses OpenID Connect to let CI/CD systems like GitHub Actions publish packages without storing npm tokens as secrets. The CI provider authenticates directly with npm using short-lived tokens, reducing the risk of token theft and improving auditability.

How can I tell if a publish was automated or manual?

npm notification emails include the publishing method. 'via OIDC' indicates automated publishing through Trusted Publishing (GitHub Actions, GitLab CI). 'via token' indicates someone used an npm access token, which could be automated CI or a manual publish.

What should I do if I see an unauthorized publish?

Immediately: 1) Run 'npm deprecate <package>@<version>' to warn users, 2) Revoke all access tokens at npmjs.com/settings/tokens, 3) Review organization members and their permissions, 4) Publish a patched version, 5) Consider enabling npm's two-factor authentication requirement for publishing.

How do I require 2FA for publishing?

Go to npmjs.com → Settings → Access Tokens. When creating automation tokens, you can require 2FA for publish operations. For organizations, admins can enforce 2FA at the org level. Note that OIDC publishing bypasses token-based 2FA since it uses a different authentication mechanism.