A practical guide to detecting and responding to open source supply chain compromises using SAST, SCA, and proactive security monitoring.
Software supply chain attacks have evolved from theoretical risks to front-page news. The attacks keep coming, and they’re getting more sophisticated:
Log4Shell (2021) taught us that a single vulnerability in a ubiquitous logging library could expose millions of applications overnight. Organizations scrambled to answer one question: “Do we even use Log4j?”
Polyfill.io (2024) showed how a trusted CDN service could be weaponized after acquisition, injecting malicious code into over 100,000 websites that thought they were loading a legitimate JavaScript polyfill library.
Shai-Hulud (2025) represents the next evolution—a self-replicating worm spreading through the node package manager (npm) ecosystem, compromising developer accounts and poisoning packages in a cascading chain of infections. Named after the giant sandworms of Frank Herbert’s Dune, this threat burrows through the open source landscape, consuming everything in its path.
The question isn’t whether your organization will face a supply chain attack: The question is whether you’ll know about it before it’s too late.
Unlike vulnerability disclosures, where a CVE is published, and vendors rush to patch, Shai-Hulud operates differently, which makes it particularly dangerous.
The worm exfiltrates GitHub tokens, CI/CD credentials, and cloud secrets from compromised developer machines. These stolen credentials become the keys to the next wave of infections.
Using stolen credentials, attackers gain maintainer access to legitimate npm packages. They inject malicious preinstall scripts that execute during the build process—often before any security scanning occurs.
Each compromised package potentially compromises more developers, who maintain more packages, creating an exponential spread pattern. As of this writing, over 700 npm packages have been impacted, and that number continues to grow.
The malicious code often executes during npm install , before your application even runs. Traditional runtime security tools never see it.
The challenge with Shai-Hulud and generally with supply chain attacks is that you’re not looking for a single CVE. You’re looking for:
No single tool or approach solves this completely but with the right combination of Kiuwan capabilities, you can significantly reduce your exposure and response time.
Your defensive strategy depends on your relationship to the open source ecosystem.
You’re a potential target for credential theft and package hijacking. Your defenses should include:
Vigilant Code Review: Block any pull requests from contributors you don’t recognize, especially those modifying build scripts, package.json, or CI/CD configurations.
SAST Scanning of Your Own Code: Use Kiuwan Code Security to scan your repository regularly. Look for:
Credential Hygiene: Rotate your npm tokens regularly. Enable 2FA on npm and GitHub. Never store credentials in code—Kiuwan’s hardcoded credentials detection, coming in 2026, can help enforce this.
This is most organizations. You depend on packages maintained by others, and you need visibility into what you’re actually using.
Many organizations can’t answer this question with confidence. Transitive dependencies (dependencies of your dependencies) often outnumber direct dependencies 10:1.
There’s no single authoritative list of Shai-Hulud-infected packages, and the list keeps growing. By the time a package is publicly identified, it may have been compromised for days or weeks.
Pin to the last known-good version? Remove the dependency entirely? Wait for the package to be cleaned up?
Let’s walk through how Kiuwan helps with each of these challenges.
Kiuwan Insights, our Software Composition Analysis (SCA) solution, is your first line of defense for understanding what you’re actually using.
Run a Kiuwan Insights scan against your codebase to generate a complete Software Bill of Materials (SBOM). This gives you:
For a Node.js project, Kiuwan analyzes your package.json and package-lock.json (or yarn.lock) to build the complete dependency tree.
Pro Tip: Run this scan regularly, not just once. Your dependency tree changes with every npm install or npm update. Set up automated scans in your CI/CD pipeline to maintain current visibility.
Once you have your SBOM, you can export it for analysis. For a threat like Shai-Hulud where the list of affected packages keeps growing, you’ll want to:
Here’s a simple approach using exported SBOM data:
# Example: Cross-reference SBOM against compromised packages
compromised_packages = load_compromised_list()
# Your threat intel source
sbom_components = load_sbom_export()
# Kiuwan Insights export
for component in sbom_components:
if component.name in compromised_packages:
print(f"ALERT: {component.name}@{component.version} is potentially compromised")
print(f" - Introduced by: {component.parent_dependency}")
Set up Kiuwan to scan on every commit or at least daily. When the compromised package list updates, your next scan will flag any new exposures.
While SCA tells you what packages you’re using, SAST (Static Application Security Testing) can look for specific patterns in your code—including patterns associated with known attacks.
Kiuwan Code Security supports custom rules that let you hunt for specific strings, patterns, or code constructs. You can observe this being implemented with the Log4j and Polyfill detection.
Create a custom rule that searches for the package name or malicious pattern. For example, here’s a guide to adding a rule that flags any import of polyfill.io.
We have rules that detect Log4j usage and flag versions vulnerable to Log4Shell (CVE-2021-44228). The rule triggers on the presence of vulnerable Log4j patterns, allowing you to catch exposure even in projects where dependency management is incomplete.
Here’s where Shai-Hulud gets tricky. With 700+ compromised packages and counting, creating individual rules for each package name isn’t practical. Instead, consider these approaches:
Create a single rule with a large pattern set that matches known compromised package names. Update the rule as the threat intelligence updates.
// Conceptual approach
Patterns: [
"compromised-package-1",
"compromised-package-2",
// ... hundreds more
]
Reference this Polyfil.io blog post to learn how to add a custom rule. The downside: maintaining this list requires ongoing effort, and the rule file becomes unwieldy.
Create SAST rules for the most critical or commonly-used compromised packages (the “greatest hits”), while relying on SCA for comprehensive coverage. This gives you:
Create a Kiuwan Model that contains only your supply chain threat rules. Run this model in a separate scan, perhaps daily via Jenkins, with aggressive Kiuwan Audit settings. If anything triggers, break the build or send alerts.
This approach lets you:
Here’s how to put it all together:
When you identify a compromised package in your dependency tree:
These previous incidents taught us valuable lessons that apply directly to Shai-Hulud:
The biggest challenge during Log4Shell wasn’t patching—it was finding all the places Log4j was used. Organizations with mature SCA practices and current SBOMs responded in hours. Those without spent weeks hunting.
Apply to Shai-Hulud: Your SBOM is your inventory. If you don’t have one, start now. If you have one, make sure it’s current.
Polyfill.io was a trusted service for years. Developers included it without a second thought. When it was compromised, the trust model broke completely.
Apply to Shai-Hulud: Even “trusted” packages can be compromised. The npm ecosystem’s trust model—where a maintainer’s credentials grant publishing rights—is exactly what Shai-Hulud exploits.
In both cases, the organizations that responded fastest were those with:
Apply to Shai-Hulud: Don’t wait for the next incident to set up your defenses. The infrastructure you build today is the response capability you’ll have tomorrow.
If you’re not already using Kiuwan, here’s how to begin protecting yourself against supply chain threats:
Run Kiuwan Insights against your main codebase to generate your first SBOM. Understand what you’re working with.
Review the Kiuwan dashboard for any dependencies with known CVEs. Prioritize critical and high-severity findings.
Connect Kiuwan to your build pipeline. Start with monitoring mode (scan and report) before enabling blocking policies.
Set up Audit rules that match your risk tolerance. At a minimum, consider blocking builds that introduce critical vulnerabilities.
Schedule regular scans, export SBOMs for threat intelligence cross-referencing, and keep your custom rules updated.
Shai-Hulud is a reminder that software supply chain security isn’t a one-time project—it’s an ongoing practice. The worm is still spreading, the compromised package list is still growing, and the attackers are still finding new maintainer accounts to compromise.
You can’t control the npm ecosystem. You can’t prevent packages from being compromised. But you can control what enters your codebase, and you can know what you’re using at any given moment.
That visibility, combined with automated scanning, policy enforcement, and rapid response capabilities, is the difference between finding out about a supply chain attack from your security tools versus finding out from your customers.
The sandworm is out there. Make sure you can see it coming.
Ready to secure your software supply chain? Start your free Kiuwan trial and get visibility into your dependencies today.
JD Burke is the Director of Security Products at Sembi with more than 20 years of experience in product management and application security. He has held senior technical roles at Snyk, CyberRes/Fortify, and Kiuwan, with expertise across SAST, SCA, and DevOps integration. JD combines hands-on security knowledge with product leadership, guiding cross-functional teams through planning, feature development, and market positioning while maintaining deep expertise in vulnerability assessment and compliance frameworks.
