6 Steps to Safeguard Your Enterprise from the Shai-Hulud Worm and NPM Vulnerability

2. Isolate the runner during publish. Token revoke before isolation. Monitor for direct POSTs, especially from unusual locations

Runners are often shared among workflows. Runners may have access to secrets used in other workflows. Developers may forget to revoke tokens after an incident.

The worm exfiltrated the OIDC token from runner memory. Revoking tokens after the incident would not prevent the worm from extracting them. Monitoring for unusual POSTs may not catch the attack if it originates from a trusted runner. The attacker’s direct POST from /proc/pid/mem would be normal behavior.

3. Limit token scope to the workflow that needs it. Enforce read-only tokens where possible

Developers may request broader access than necessary for convenience. Sensitive data might be stored in unencrypted environment variables.

The worm extracted the OIDC token from runner memory. If the token scope was limited to the specific workflow that needed it, the attack might have been prevented. Read-only tokens would limit the damage the attacker could do with stolen credentials.

4. Implement regular token rotation and auditing for unusual activity

Token rotation is often done infrequently or reactively. Auditing might not catch all unusual activity.

The worm was able to extract the OIDC token and use it to publish malicious packages. Regular token rotation could have limited the window of opportunity for the attacker. Auditing for unusual activity may have detected the attack sooner.

5. Enforce least privilege for secrets and credentials

Developers may request more access than necessary. Secrets might be stored in plaintext files.

The worm harvested a wide range of credentials from developer workstations, including AWS keys, SSH private keys, and more. Enforcing least privilege would limit the number of credentials the attacker could access. Storing secrets securely, such as in a secure vault, would also help prevent their theft.

6. Conduct regular security training for developers on secure coding practices and recognizing social engineering attacks

Training might be infrequent or limited to basic concepts. Developers might not be aware of the latest attack techniques.

The worm was able to compromise multiple packages and steal sensitive credentials from developer workstations. Regular security training could help developers recognize suspicious activity and prevent social engineering attacks. Keeping developers informed about the latest threats and attack techniques is essential for maintaining a secure development environment.

The comprehensive solution involves pinning and constraining the id-token: only allowing writing to the publish job and ensuring that the job utilizes a clean, unshared cache.

Teams should not solely rely on SLSA provenance but also incorporate behavioral analysis at install time to enhance package safety. Valid Sigstore provenance badges are considered proof of a package’s safety, but behavioral analysis provides an additional layer of security.

To prevent malicious attacks, isolate GitHub Actions cache per trust boundary, invalidate caches after suspicious PRs, and avoid checking out and executing fork code in pull_request_target workflows. It is crucial to maintain separate cache namespaces for fork-triggered and release workflows to prevent cache contamination.

Auditing optionalDependencies in lockfiles and dependency graphs is essential to block github: refs pointing to non-release commits. The presence of optionalDependencies with github: commit refs can introduce vulnerabilities that may go undetected by standard tools.

Separately auditing Python dependency imports and applying necessary controls is crucial, especially for AI/ML pipelines consuming specific Python packages. Applying npm mitigations to JavaScript stacks may not be sufficient to protect against Python package vulnerabilities.

When responding to security incidents, it is important to isolate and image affected machines before revoking stolen tokens to prevent further damage. Revoking npm tokens without proper forensic preservation can trigger destructive actions on compromised systems.

To enhance security measures, rotate credentials in the order of npm tokens, GitHub PATs, and cloud keys after isolating affected machines. Additionally, conduct thorough audits of GitHub Actions workflows to address potential security gaps and implement necessary precautions.

At the board level, funding behavioral analysis at the package registry layer and conducting CI/CD security audits are recommended. Provenance verification alone may not be adequate for ensuring the security of the software supply chain, necessitating additional security measures.

As the threat landscape evolves, defenders must adapt and strengthen their security measures. The emergence of new attack techniques underscores the importance of proactive security measures and continuous vigilance in safeguarding software supply chains.

The Importance of Provenance in Package Security

One of the most critical aspects of package security is understanding the provenance of a package. Provenance provides valuable information about where a package was built, which can help identify any potential security risks. However, simply knowing where a package was built is not enough to ensure its security. It is also essential to verify whether the build was authorized.

Recently, there was an attack that bypassed two security controls because the gap was not in the signing process, but rather in the scope of the controls. This incident highlights the importance of thorough security measures beyond just the surface level.

Provenance, while important, is only one piece of the puzzle when it comes to package security. It can tell you where a package originated from, but it cannot guarantee the legitimacy of the build. This is where audits play a crucial role in closing the gap in security.

An audit is designed to verify the authorization of a build, ensuring that it meets the necessary security standards. By conducting regular audits, organizations can identify any unauthorized builds and take the necessary steps to mitigate any potential risks.

When it comes to package security, it is essential to look beyond just the provenance of a package. While knowing where a package was built is important, it is equally important to verify the authorization of the build. By implementing thorough security measures, such as audits, organizations can better protect themselves from potential security threats.