Shai-hulud post-mortem: A call to action on AppSec

A post-mortem by Trigger.dev delving into how it got hit by the Shai-hulud attack on the npm package registry shows that weaknesses in dependency execution and credentials hygiene can allow modern supply chain attacks to quietly cascade into widespread compromise.

Shai-hulud is a self-replicating worm that researchers at ReversingLabs (RL) discovered on npm in September 2025. The worm abused preinstall scripts to steal developer credentials and spread across hundreds of npm packages and thousands of JavaScript repositories.

The incident at Trigger.dev began in November, during the second wave of Shai-hulud, when an engineer working on a new project executed a standard npm install, a command that downloads and installs all required dependencies for a JavaScript/Node.js project. In this case, one of the dependencies was a malicious package that silently executed its payload via a preinstall script. 

The installation completed successfully and appeared normal, but in the background the Shai-hulud payload stole the engineer’s credentials — including GitHub tokens — and exfiltrated them to an external attacker.

After validating the stolen credentials, the attacker accessed the engineer’s GitHub account and remained undetected for roughly 17 hours, during which time they cloned 669 Trigger.dev repositories and created multiple new repositories with randomly generated names to store stolen data. The following day, in a span of about 10 minutes, the attacker overwrote code on 199 branches across 16 repositories and closed 42 pull requests — 12 of them in just three seconds, suggesting the activity was automated.

Crucially, the attacker made several attempts to push malicious code directly into the production branches of Trigger.dev’s most important repositories, but GitHub branch protection rules automatically blocked those actions, preventing what could have escalated into a far more damaging compromise.

The incident left the compromised engineer feeling guilty, but Trigger.dev CTO Eric Allam wrote in the post-mortem report that the same thing could have happened to any other team member, and the blame lies elsewhere. 

Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run arbitrary code silently.

Eric Allam

Here's what you need to know about the post-mortem takeaways — and why you need to take action to modernize your AppSec in the age of such sophisticated supply chain attacks.

See webinar: The 2025 Supply Chain Breach Roundup

An overabundance of trust

Trigger.dev has implemented several changes to its environment following the incident. One of the biggest is its decision to disable npm scripts globally so packages cannot automatically run code during installation. Trigger.dev has also completely eliminated long-lived npm tokens, switching to short-lived, ephemeral OpenID Connect (OIDC) tokens for authentication. Other measures include enabling branch protection on all repositories — not just the crucial ones — to protect against unauthorized code changes, and upgrading to npm 10, which ignores scripts by default and requires explicit whitelisting of trusted packages.

Shane Barney, chief information security officer at Keeper Security, said the Shai-hulud incident shows how a repository design that allows packages to silently execute arbitrary code during installation makes even routine dependency management an undetectable security risk that no amount of developer caution can prevent, said .

Dependency installation commonly involves executing third-party code with limited visibility into what that code is doing or what it can access. In practice, this extends trust far beyond an organization’s own codebase.

Shane Barney

The Trigger.dev incident showed how attackers can exploit these trust assumptions, not by bypassing a single control, but by taking advantage of how dependency execution and credentials access are structured in modern development environments, he said. This includes having long-lived, high-privilege GitHub tokens accessible on a developer workstation and allowing insufficient isolation between dependency execution and sensitive credentials. 

The central issue is the trust placed in the package maintainer’s ability to protect their publishing credentials, said Venky Raju, field CTO at ColorTokens. 

If attackers are able to access the maintainer’s system via social engineering or other techniques, they can access their publishing credentials and publish a malicious version of the JavaScript package.

Venky Raju

The danger from long-lived tokens

The Shai-hulud attack was largely about credentials theft and reuse. The adversary used compromised credentials to access and compromise npm packages and then cascaded this kill chain to infect other packages, Raju said. The incident makes a strong argument for eliminating long-lived local tokens and using ephemeral identities such as OIDC.

In OIDC environments, apps verify a user’s identity via a trusted login service like Google or Okta. Instead of dealing with passwords, the app gets a secure token that proves who the user is and enables seamless login, often with single sign-on across multiple sites. 

While OIDC is a more secure alternative to long-lived tokens, adoption requires a tooling and culture shift among developers, as they can no longer freely publish from a local token stored on their laptop.

Venky Raju

Moving away from long-lived local credentials toward ephemeral, just-in-time access significantly reduces risk when a compromise occurs, Barney said. Eliminating standing credentials on developer machines limits both the duration and scope of access if credentials are exposed. 

Even when an endpoint or dependency is compromised, access is constrained by default and expires automatically. While this requires changes to developer workflows and CI/CD pipelines, it aligns with zero-trust principles by ensuring access is granted only when needed and removed by default, reducing the overall impact of supply-chain attacks.

Shane Barney

Why you need supply chain security organization-wide

Shai-hulud underscores a critical reality: supply chain security is an enterprise-wide infrastructure problem, not something that can be solved by simply teaching developers to be more careful, said Jason Soroko, senior fellow at Sectigo. The attack succeeded precisely because legitimate tools worked exactly as designed but were hijacked in the process.

This shows why defenses must operate at the organizational level through enforced policies and automated monitoring rather than relying on manual code review.

Jason Soroko

Barney said the incident also exposes the limits of controls that focus solely on individual developers or endpoints. Even when developers follow best practices, long-lived credentials and standing access on local machines create openings for attackers once a dependency is compromised.

Organization-level controls prove more effective because they enforce least-privilege, eliminate standing access, and centralize oversight of privileged identities — reducing impact no matter how the initial compromise occurs.

Still, developer-centric security controls remain essential. Rotating tokens and protecting credentials address the root of the problem, Raju stressed. “But there’s always the possibility that a single miss can lead to compromise,” he said.

Any ecosystem that allows third-party code to execute automatically carries a risk similar to that of Shai-hulud, Barney said. While registries and maintainers play an important role, organizations should assume that upstream trust can fail and therefore design controls that limit access, execution, and credentials exposure across the environment as a whole, he noted.

Why package validation is essential

The challenge for development teams is that traditional security checks may not catch every threat. Package managers such as npm operate on a trust model; if a package is published with valid credentials, the system assumes it’s legitimate. This creates a blind spot that attackers can exploit, Raju said. 

It may not be possible to reliably detect compromised packages all the time. npm assumes a package is legitimate if it was published with a valid token.

Shane Barney

Fortunately, npm does support provenance and attestation features that can help close this gap, Barney said. These tools verify that a package was created by a legitimate workflow rather than by a malicious actor wielding stolen credentials. Development teams should leverage this attestation data whenever available to prevent compromised packages from entering their pipeline, he said. 

Raju noted that tools such as Google’s deps.dev project make this easier by providing a convenient way to scan for all dependencies of a package.

Why advanced application security controls are key

Randolph Barr, CISO at Cequence Security, said incidents like the Shai-hulud breach aren’t just about code quality — they are also about trust across the entire CI/CD system. While protecting the environment might appear daunting to organizations without a dedicated API security platform or runtime supply chain monitoring, even relatively basic measures can have a big impact.

This includes things like pinning dependencies to prevent automatic malicious updates, using software composition analysis (SCA) tools to scan for vulnerabilities, preventing hardcoded secrets in repositories, limiting build system permissions, and implementing centralized logging to detect suspicious behavior.

Critically, organizations need to move from preventative static scanning alone to runtime monitoring that can detect anomalous behavior such as unauthorized API calls, unusual network destinations, or attempts to access cloud credential services, Barr said. The key point is that modern attackers use automation to hunt for credentials at scale, so defenders must respond with equally automated protections, better developer security practices, and comprehensive visibility across their entire CI/CD pipeline — not just code review at one point in time. 

This is a reminder that secrets aren’t just leaked; they’re actively hunted through automation. Defenders must match that speed with automated guardrails, developer hygiene, and visibility across the pipeline.

Randolph Barr

Patrick Enderby, senior product marketing manager at RL, said that traditional vulnerability scanning fails to prevent the most dangerous supply chain attack vectors.

Enderby said the gap can be closed with binary analysis, which assesses the compiled binaries of the software, not just metadata or source code. Binary analysis allows for the detection of modern supply chain threats — including Shai-hulud.

It provides the missing layer of independent validation needed to close the chain between trust and verification.

Patrick Enderby

Enderby added that the bulk of modern supply chain security compromises occurs at the binary level within build systems or dependencies long before deployment. The SolarWinds breach was executed through a malicious build process. XZ Utils embedded a backdoor deep within compressed binary artifacts, he noted. 

Conventional SCA or SBOM checks can’t detect these because they rely on self-reported component data rather than examining the delivered binaries themselves.

Patrick Enderby