The current threat pattern

Supply chain attacks on open source have shifted toward a familiar playbook: steal secrets such as API keys, then use that access to publish malicious packages and compromise additional projects. These campaigns frequently begin with a compromised GitHub Actions workflow. Blocking that entry point and improving how package publication is authorized are the two areas with the most immediate payoff for defenders.

Hardening workflows today

For any workflow you control, the highest-impact change is enabling CodeQL to review GitHub Actions implementations. The built-in Action queries are available free on public repositories and can surface risky patterns in how your workflows are written.

Beyond static analysis, GitHub’s Actions security guidance points to several concrete practices:

  • Avoid triggering workflows on pull_request_target, which exposes privileged contexts to untrusted code changes.
  • Pin third-party Actions to full-length commit SHAs rather than tags or branches. This pinning should be performed by you or Dependabot; be suspicious of external pull requests that modify pinned versions.
  • Watch for script injection risks when referencing user-submitted content in workflow steps, and escape or validate any input before using it in shell commands.

When an attack is discovered, GitHub publishes details on compromised dependencies in the Advisory Database. You can also rely on Dependabot’s malware alerts—again free for public repositories—to be notified if a dependency you use is flagged as malicious or vulnerable.

Moving secrets out of pipelines

One structural fix to the secret-exfiltration problem is to stop using long-lived secrets entirely. OpenID Connect tokens carrying the workflow’s workload identity let workflows authorize actions without embedding credentials. GitHub has worked with cloud providers, package registries, and other hosted services to accept this form of authentication, and partners with the OpenSSF to promote the resulting pattern under the name trusted publishing.

Trusted publishing is now available across npm, PyPI, NuGet, RubyGems, Crates, and other package repositories. Its value goes beyond removing secrets from build pipelines: when a maintainer who previously used trusted publishing suddenly stops doing so, that divergence is a meaningful signal worth investigating, because an attacker with stolen credentials is likely to publish without the mechanism.

Malware scanning at npm scale

npm is the largest package repository in the world, with more than 30,000 packages published each day. GitHub scans every new npm package version for malware, and detection rules are updated continuously as campaigns evolve. Hundreds of newly published packages contain malicious code daily. Each detection requires human confirmation before action, and the false-positive bar is deliberately low because at this scale even a 1% error rate would disrupt hundreds of legitimate publishes each day.

The near-term roadmap

Late 2025 brought renewed attention to supply chain security when the Shai-Hulud attack campaign hit npm. GitHub responded by accelerating work that was already in progress: rolling out trusted publishing for npm, expanding malware detection and removal capabilities, and consulting maintainers on which security upgrades of fc00 would have the largest positive impact. The stated goal is to make these changes with as little workflow disruption as possible, even where backwards compatibility is a concern.

A similar acceleration is happening on the GitHub Actions side. In response to the most recent attack wave, GitHub is revisiting its Actions security roadmap and has published a detailed plan alongside a community discussion thread where maintainers can weigh in on priorities and transition challenges.

Open source will remain an attack target, but the combination of workflow-level hardening, trusted publishing, and faster response at the registry level gives project owners and security teams practical levers to reduce exposure today.