The recent supply chain attack on SAP-related npm packages, dubbed mini Shai-Hulud, has sent shockwaves through the developer community. This campaign targeted npm packages used in SAP's JavaScript and cloud application ecosystem, exposing vulnerabilities in developer workflows, CI/CD pipelines, and the broader software supply chain. By understanding the attack mechanics and implications, security teams can better defend against similar threats. Below are 10 key takeaways from this incident, with internal links to explore each lesson in depth.
1. The 'mini Shai-Hulud' Campaign: A New Breed of Supply Chain Attack
This campaign specifically targeted @cap-js packages and the mbt package, which are integral to SAP's cloud application development. Attackers published malicious versions including mbt@1.2.48, @cap-js/db-service@2.10.1, @cap-js/postgres@2.2.2, and @cap-js/sqlite@2.2.2 on April 29. The compromised versions were later replaced by safe releases, but not before damage was done. This incident underscores how a single tainted dependency can cascade through developer tools, CI/CD pipelines, and eventually into production environments.
2. Malware Capabilities: Credential Harvesting on a Massive Scale
The malicious npm packages included installation-time code designed to steal developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes environments. This multi-cloud credential harvesting made the attack particularly dangerous. As Sakshi Grover, senior research manager at IDC, noted, the ability to grab all these credentials in a single pass turns the developer workstation into a master key for attackers. Organizations must treat developer machines as critical attack surfaces, not just production servers.
3. Data Exfiltration via Victim GitHub Repositories
Stolen data was encrypted and sent to public GitHub repositories created from victims' own accounts. This clever technique allowed attackers to blend in with normal development activity. The malware also used stolen tokens to add malicious GitHub Actions workflows to accessible repositories and publish further poisoned package versions. This demonstrates how attackers leverage existing trust—if they compromise one identity, they can spread malware across multiple repositories and projects.
4. Abusing npm OIDC Trusted Publishing: A Configuration Gap
For the @cap-js packages, the attackers exploited a configuration gap in npm's OIDC trusted publishing setup. This misconfiguration allowed them to bypass normal authentication checks and publish malicious versions. The compromise of the mbt package, on the other hand, is suspected to have involved a static npm token. Security teams should review their npm package publishing configurations, ensure OIDC is properly scoped, and avoid using static tokens where possible.
5. Persistence Through Developer Environment Configurations
Attackers also attempted to persist through Visual Studio Code and Claude Code configuration files. By injecting malicious code into these widely used configuration files, they could maintain access even after initial detection. This technique places AI-assisted coding tools and developer workstations squarely at the center of supply chain security concerns. It's a reminder that any configuration file—whether for an IDE, terminal, or CI/CD tool—can become an attack vector.
6. The Tainted Dependency Ripple Effect
Once a malicious package is installed in a CI/CD pipeline, it can quickly move beyond the build process. The compromised package can inject malicious code into downstream builds, affecting not only the immediate project but also any library or application that depends on it. This ripple effect is why supply chain attacks are so dangerous—one weak link can compromise hundreds of organizations. CISOs must enforce rigorous dependency scanning and vetting for all third-party packages.
7. Developer Workstations: The Weakest Link in Security
The mini Shai-Hulud attack highlights that developer environments are still not governed with the same rigor as production systems. As Sakshi Grover stated, attackers treat the developer workstation as a master key because it often has broad access to code repositories, CI/CD systems, and cloud services. Organizations need to implement strong authentication, least-privilege access, and continuous monitoring for developer machines, just as they do for production infrastructure.
8. The Growing Role of AI in Supply Chain Risk Analysis
According to IDC's Asia Pacific Security Survey 2025, 46% of enterprises plan to deploy AI for third-party and supply chain risk analysis within the next 12 to 24 months. However, many organizations are still in the planning stage. The mini Shai-Hulud campaign underscores the urgency of moving from planning to action. AI-driven defenses can analyze package behavior, detect anomalies in CI/CD pipelines, and identify malicious patterns faster than manual reviews.
9. A Case of 'Living off the Land' in Software Supply Chains
Security analyst Sunil Varkey described this campaign as a case of living off the land, where attackers use legitimate tools and processes—like npm publishing, GitHub Actions, and configuration files—to carry out malicious activities. This makes detection extremely challenging because the malicious behavior mimics normal developer actions. Defenders must focus on behavior analysis and anomaly detection rather than relying solely on signature-based tools.
10. Key Takeaways for CISOs and Security Teams
This attack serves as a wake-up call for security leaders. First, implement strict access controls for npm tokens and OIDC configurations. Second, continuously monitor developer workstations and CI/CD pipelines for unusual activity. Third, invest in AI-powered supply chain security tools that can analyze package integrity and behavior. Finally, foster a culture of security awareness among developers, as they are the first line of defense. The mini Shai-Hulud attack may be over, but the lessons it teaches are timeless.
In conclusion, the SAP npm package attack reveals critical vulnerabilities in the modern software supply chain. By learning from this incident, organizations can strengthen their defenses against similar threats. The key is to treat developer tools, workstations, and CI/CD pipelines as integral parts of the security perimeter—not just as assets that support production. Proactive measures, such as adopting zero-trust principles for package publishing and leveraging AI for threat detection, can help mitigate risks. The battle for supply chain security is ongoing, but with awareness and action, we can reduce the chances of falling victim to the next 'mini Shai-Hulud.'