GitHub's Plan to Stop Supply Chain Attacks on Actions

TL;DR

• Attackers are compromising GitHub Actions workflows to steal secrets and publish malicious packages
• Enable CodeQL scanning on your workflows now — it's free for public repos
• GitHub is accelerating Actions security features and expanding trusted publishing across package registries
• npm scans 30,000+ packages daily and catches hundreds of malicious publishes

The Big Picture

Open source supply chain attacks have shifted tactics. Instead of targeting package maintainers directly, attackers are exploiting GitHub Actions workflows to exfiltrate API keys and publishing credentials. Once they have those secrets, they publish malicious packages from their own machines and use the compromised access to spread laterally across more projects.

This isn't theoretical. The Shai-Hulud attacks in late 2025 forced GitHub to accelerate its entire npm security roadmap. Now GitHub is applying those lessons to Actions itself, rolling out detection tools and authentication changes that remove secrets from the equation entirely.

The stakes are high. npm alone sees over 30,000 package publishes every day, and hundreds of those contain malicious code. At that scale, even a 1% false-positive rate in automated detection would block hundreds of legitimate developers daily. GitHub has to balance speed with accuracy while attackers continuously evolve their techniques.

How It Works

The attack pattern is consistent. Attackers scan for vulnerable GitHub Actions workflows — specifically ones that trigger on pull_request_target events or use unpinned third-party actions. They submit malicious pull requests designed to execute code in the context of the target repository, exfiltrating secrets stored in the workflow environment.

Those stolen secrets give attackers publishing rights to package registries. They push malicious versions of popular packages, which then get installed by downstream projects. The malicious code often includes additional credential harvesting, allowing the attack to spread.

GitHub's defense strategy has three layers. First, CodeQL now includes built-in queries specifically for Actions workflow security. It flags common misconfigurations like unsafe event triggers, unpinned action versions, and script injection vulnerabilities where user-submitted content gets evaluated as code.

Second, GitHub has been working with the OpenSSF to implement trusted publishing across major package registries. Instead of using long-lived API tokens, workflows authenticate using short-lived OpenID Connect tokens that contain the workflow's identity. npm, PyPI, NuGet, RubyGems, and Crates.io all support this now. When a package that previously used trusted publishing suddenly switches to credential-based publishing, it's a red flag that the maintainer's credentials may have been compromised.

Third, GitHub scans every npm package version for malware using continuously updated detection rules. When the system flags a package, a human reviewer confirms it's actually malicious before GitHub takes action. This manual review step is necessary because automated systems can't achieve the precision required at npm's scale.

The technical challenge is that these defenses have to work without breaking existing workflows. Forcing every npm package to use trusted publishing would be the most secure option, but it would also break backward compatibility for thousands of projects. GitHub is trying to thread the needle between security and usability.

What This Changes For Developers

If you maintain any open source project with GitHub Actions, you need to audit your workflows now. The most dangerous pattern is triggering workflows on pull_request_target, which runs in the context of the base branch with access to secrets. Attackers know this and actively search for it.

Pin your third-party actions to full commit SHAs, not tags or branch names. Tags can be moved, branches can be force-pushed. A commit SHA is immutable. When Dependabot sends you a PR to update an action, that's fine. When a random external contributor sends one, be suspicious.

If you publish packages to npm or other registries, switch to trusted publishing. It eliminates the need to store publishing credentials as repository secrets, which removes the primary target attackers are after. The setup is straightforward — you configure your package registry to accept OIDC tokens from your GitHub workflow, then remove the API token from your secrets.

For projects that depend on npm packages, enable Dependabot alerts. GitHub's Advisory Database gets updated as soon as malicious packages are confirmed. Dependabot will notify you if you're using a compromised dependency, often within hours of detection.

The workflow changes are minimal, but the security impact is significant. GitHub is betting that removing secrets from the supply chain will force attackers to find new vectors, buying time for additional defenses to roll out.

Try It Yourself

Enable CodeQL scanning for your Actions workflows by adding this to .github/workflows/codeql.yml:

name: "CodeQL"
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: read
      security-events: write

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Initialize CodeQL
      uses: github/codeql-action/init@v3
      with:
        languages: javascript

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v3

This configuration scans your workflows for security issues on every push and pull request. CodeQL will flag unsafe patterns and suggest fixes directly in your pull request checks.

The Bottom Line

Use CodeQL scanning on your workflows immediately if you maintain any public repository with Actions. The free tier covers public repos, and the security benefit is substantial. Switch to trusted publishing if you publish packages — it's supported on every major registry now and eliminates the credential theft vector entirely.

Skip the manual workflow audits if you're already using CodeQL. The automated scanning catches the same issues faster and doesn't miss edge cases. The real risk here is complacency. These attacks are happening daily, and the pattern is well-established. GitHub is shipping defenses, but they only work if you enable them.

The opportunity is that GitHub is accelerating its Actions security roadmap based on community feedback. If you have opinions on what features matter most, the community discussion is where GitHub's product team is listening. The next wave of supply chain attacks is already being planned. The question is whether the defenses will be in place first.

Source: GitHub Blog