Over the past year, a new pattern has emerged in attacks on the open source supply chain. Attackers are focusing on exfiltrating secrets (like API keys) in order to both publish malicious packages from an attacker-controlled machine as well as gain access to more projects in order to propagate the attack. These attacks often start by compromising a workflow on GitHub Actions.

What You Can Do Today to Secure Your GitHub Actions Workflows

The most critical action you can take is to enable CodeQL to review your GitHub Actions workflow implementation (available for free on public repositories) to inspect your workflows for security best practices. Next, review our detailed actions security guidance. In particular:

• Don't trigger workflows on pull_request_target - This can expose your repository to malicious pull requests
• Pin third-party Actions to full-length commit SHAs - This pinning should be done by you or Dependabot; be suspicious of external pull requests that update this content
• Look out for script injection when referencing user-submitted content - Always validate and sanitize inputs

When an attack happens, we publish information about compromised dependencies in our Advisory Database. You can get up-to-date information directly from the Advisory Database or use tools like Dependabot (also free for public repositories) to notify you when you have malicious or vulnerable dependencies.

GitHub's Comprehensive Security Response

These attacks follow the same pattern: they focus on exfiltrating secrets to publish malicious packages from an attacker-controlled machine, as well as using those malicious packages to gain access to more projects to propagate the attack.

Instead of using secrets in your workflows, you can use an OpenID Connect token that contains the workload identity of the workflow to authorize activities. We've worked with many systems to integrate with Actions this way, including cloud providers, package repositories, and other hosted services.

Specifically, GitHub partners with the Open Source Security Foundation (OpenSSF) to support this security capability, called trusted publishing, in package repositories, which is now supported across npm, PyPI, NuGet, RubyGems, Crates, and other package repositories.

Not only does trusted publishing remove secrets from build pipelines, it also provides a valuable signal when a newly published package stops using trusted publishing: the community uses this signal to investigate if the package came from an attacker using exfiltrated credentials.

The Scale of the Challenge

npm is the largest package repository in the world, with over 30,000 packages published each day. We scan every npm package version for malware, and our detections are constantly updated and improved as attacks evolve. Hundreds of newly published packages contain malicious code daily, so when detected, a human reviews to confirm it's a true positive before we take action. At this scale, even a 1% false-positive rate would disrupt hundreds of legitimate publishes daily.

What to Expect in the Coming Months

In late 2025 the Shai-Hulud attacks motivated a revamped security roadmap for npm, which we talked about in Our plan for a more secure npm supply chain and Strengthening supply chain security: Preparing for the next malware campaign.

In response to Shai-Hulud we accelerated the roll-out of capabilities like npm trusted publishing, continued work on malware detection and removal, and engaged with open source maintainers on what npm security capabilities would have the biggest positive impact.

Even when the community agrees a change must be made, those changes can mean that people need to change their workflow, or worse, cause backwards incompatibility. We're working to provide as smooth a transition as possible.

Similarly, with the most recent round of attacks we are revisiting our security roadmap for GitHub Actions and accelerating actions security capabilities where work was already underway. You can give us feedback on the GitHub Actions security roadmap in the community discussion post.

The Future of Open Source Security

Open source is a global public good and one of humanity's greatest collaborative projects. We have not seen the end of attacks on open source, but GitHub is committed to defending it across npm, actions, or whatever comes next.

As we work on rolling out these security capabilities, we look forward to your feedback on what's most impactful and how we manage the transition to a more secure future.

Related Security Initiatives

• A year of open source vulnerability trends: CVEs, advisories, and malware - Reviewed advisories hit a four-year low, malware advisories surged, and CNA publishing grew
• GitHub expands application security coverage with AI-powered detections - CodeQL and AI-powered detections work together in GitHub Code Security to identify vulnerabilities across more languages and frameworks
• Investing in the people shaping open source - GitHub is investing in open source security funding maintainers, partnering with Alpha-Omega, and expanding access to help reduce burden and strengthen software supply chains

GitHub's comprehensive approach to supply chain security demonstrates the critical importance of defending open source infrastructure. By combining technical controls like trusted publishing, community-driven threat intelligence through the Advisory Database, and proactive engagement with maintainers, GitHub is building a more resilient ecosystem for the future of software development.