How to Defend Your CI/CD Pipeline and Developer Tools from Supply Chain Attacks on npm Packages

Introduction

In late April 2025, a supply chain attack dubbed “mini Shai-Hulud” targeted SAP-related npm packages, compromising developer credentials, GitHub tokens, and cloud secrets across AWS, Azure, GCP, and Kubernetes. This incident exploited configuration gaps in npm's OIDC trusted publishing and static tokens, affecting packages like mbt@1.2.48, @cap-js/db-service@2.10.1, and others. The malware stole data via installation-time code and used stolen tokens to spread malicious workflows. This guide provides a practical, step-by-step approach to fortify your developer tools and CI/CD pipelines against similar attacks.

What You Need

• Access to your npm registry (public or private) and GitHub repositories
• npm and GitHub accounts with administrative privileges
• A security auditing tool (e.g., npm audit, Snyk, or similar)
• CI/CD pipeline configuration files (e.g., GitHub Actions YAML)
• Cloud provider credentials (AWS, Azure, GCP) for testing access controls
• Basic knowledge of OIDC and token management

Step-by-Step Guide

Step 1: Audit npm Package Dependencies Regularly

Begin by scanning all project dependencies for known vulnerabilities and suspicious packages. Use npm audit or a third-party tool to generate a report. For the attack in question, check if your package-lock.json or yarn.lock includes any of the malicious versions (mbt@1.2.48, @cap-js/db-service@2.10.1, @cap-js/postgres@2.2.2, @cap-js/sqlite@2.2.2). If found, immediately update to the safe releases published after April 29, 2025.

Tip: Automate audits in your CI/CD pipeline using GitHub Actions or similar tools to catch compromised packages before deployment.

Step 2: Enable and Properly Configure OIDC Trusted Publishing

The attackers abused a misconfiguration in npm’s OIDC trusted publishing for @cap-js packages. To prevent this:

• Enable OIDC for your npm packages via the npm registry settings.
• Restrict the audience claim to your specific GitHub repository or workflow.
• Use environment-specific OIDC tokens (e.g., separate tokens for staging and production).
• Regularly review OIDC configuration logs for anomalies.

Refer to npm’s documentation on trusted publishing for exact steps.

Step 3: Rotate and Limit Static npm Tokens

The compromise of the mbt package involved a static npm token. Reduce exposure by:

• Replacing static tokens with OIDC tokens where possible.
• If static tokens are unavoidable, enforce short expiration periods (e.g., 30 days) and automate rotation.
• Limit token permissions to the minimum required (e.g., read-only for dependency fetching).
• Revoke any tokens exposed in logs or version control.

Step 4: Monitor CI/CD Workflows for Malicious Activity

The attackers added malicious GitHub Actions workflows using stolen tokens. Strengthen monitoring by:

• Reviewing all GitHub Actions workflows in your repositories for unexpected steps or actions.
• Enabling branch protection rules that require pull request reviews for workflow changes.
• Using GitHub’s security features (e.g., secret scanning) to detect leaked tokens.
• Setting up alerts for unusual activity, such as workflow runs triggered by unknown actors.

Step 5: Implement Pre-Installation Code Inspection

The malicious npm packages executed installation-time code. To catch similar behavior:

• Use tools like npm preinstall scripts with static analysis to inspect code before execution.
• Consider sandboxing package installations in isolated environments (e.g., Docker containers or ephemeral CI runners).
• Review the preinstall, install, and postinstall scripts of all dependencies, especially for packages that request network access.

Step 6: Restrict Developer Workstation Access

The attackers used stolen credentials to persist via VS Code and Claude Code configuration files. Mitigate by:

• Applying least privilege principles to developer workstations—limit access to production secrets and cloud APIs.
• Using endpoint detection and response (EDR) tools to monitor configuration file changes.
• Training developers to avoid storing tokens in local files or environment variables.
• Regularly reviewing AI-assisted coding tool integrations for unusual access patterns.

Step 7: Use AI-Driven Supply Chain Risk Analysis

According to IDC’s survey, 46% of enterprises plan to deploy AI for third-party risk analysis. Start now:

• Evaluate AI-based tools that scan package ecosystems for anomalous behavior, such as sudden version changes or suspicious metadata.
• Integrate these tools into your CI/CD pipeline to flag potentially compromised dependencies.
• Combine AI alerts with manual reviews to validate findings before blocking packages.

Tips

• Govern developer environments like production systems: The mini Shai-Hulud attack shows that workstations are now master keys. Apply strict access controls and auditing.
• Increase visibility into dependency tampering: Use Software Bill of Materials (SBOM) generation and regular integrity checks.
• Stay updated on emerging threats: Follow security research from firms like SafeDep, Aikido Security, Wiz, and others that reported this campaign.
• Test your defenses with tabletop exercises: Simulate an attack scenario where a compromised npm package exfiltrates credentials to practice response procedures.