AIGovHub
Vendor Tracker
CCM PlatformSentinelProductsPricing
AIGovHub

The AI Compliance & Trust Stack Knowledge Engine. Helping companies become AI Act-ready.

Tools

  • AI Act Checker
  • Questionnaire Generator
  • Vendor Tracker

Resources

  • Blog
  • Guides
  • Best Tools

Company

  • About
  • Pricing
  • How We Evaluate
  • Contact

Legal

  • Privacy Policy
  • Terms of Service
  • Affiliate Disclosure

© 2026 AIGovHub. All rights reserved.

Some links on this site are affiliate links. See our disclosure.

The Mini Shai-Hulud Attack: Why NPM Supply Chain Security Is Now a NIS2 and DORA Compliance Imperative
NPM supply chain attack
software supply chain security
NIS2 compliance
DORA compliance
SBOM requirements
supply chain risk monitoring

The Mini Shai-Hulud Attack: Why NPM Supply Chain Security Is Now a NIS2 and DORA Compliance Imperative

AIGovHub EditorialMay 22, 20260 views

Introduction: A Wake-Up Call for Software Supply Chain Security

In early 2025, a sophisticated software supply chain attack dubbed "Mini Shai-Hulud" compromised over 320 NPM packages, multiple GitHub Actions, and a VS Code extension. The attack, attributed to the threat group TeamPCP, hijacked the maintainer account 'atool' in the @antv namespace and published 639 malicious versions across data visualization and React ecosystems. Packages like echarts-for-react (with 1.1 million weekly downloads) were weaponized, affecting countless downstream applications.

This incident is not an isolated event—it follows a pattern of escalating supply chain attacks that regulators in the EU and US are racing to address. For organizations subject to NIS2 (Directive (EU) 2022/2555) or DORA (Regulation (EU) 2022/2554), the Mini Shai-Hulud attack underscores the urgent need for robust software supply chain security measures, including Software Bill of Materials (SBOMs), dependency scanning, and continuous vendor risk monitoring.

Inside the Mini Shai-Hulud Attack: A Multi-Stage Infection Chain

The attack exploited a compromised NPM maintainer account to inject malicious code into legitimate packages. The infection chain was unusually sophisticated:

  • Stage 1 – Account Hijacking: The attacker gained control of the 'atool' account in the @antv namespace, a trusted publisher of data visualization libraries.
  • Stage 2 – Malicious Package Publication: 639 malicious versions were published across 320+ packages, including popular libraries like echarts-for-react.
  • Stage 3 – CI/CD Secret Theft: The malware read GitHub Actions runner memory to extract CI/CD secrets, harvest credentials from 130+ file paths (AWS, GCP, Azure, Kubernetes, and cryptocurrency wallets), and exfiltrated data via GitHub repositories and a fallback server.
  • Stage 4 – Remote Access & Persistence: Unlike earlier campaigns, this attack downloaded and executed Python code for remote access and dropped persistent backdoors into Claude Code, a coding assistant.
  • Stage 5 – Registry Abuse: The payload included logic to republish malicious packages, amplifying the attack surface.

Over 2,200 GitHub repositories were found to contain exfiltrated data. Microsoft's Durabletask Python SDK and the GitHub Action actions-cool/issues-helper were also compromised, demonstrating that even enterprise-grade tools are not immune.

Parallels to Recent Supply Chain Incidents

The Mini Shai-Hulud attack shares characteristics with previous high-profile supply chain breaches:

  • SolarWinds (2020): A compromised build pipeline led to trojanized updates affecting 18,000 customers.
  • Codecov (2021): A Docker image credential leak allowed attackers to modify a bash uploader script used by 29,000 customers.
  • Log4j (2021): A vulnerability in a widely used logging library exposed millions of systems.

These incidents highlight a common weakness: the reliance on third-party open-source components without adequate verification. The Mini Shai-Hulud attack adds a new dimension by targeting CI/CD pipelines and developer tools, making it a critical case study for NIS2 compliance and DORA compliance.

NIS2 and DORA Supply Chain Security Requirements

Both NIS2 and DORA impose strict requirements on supply chain security for organizations in their scope.

NIS2 Directive (EU) 2022/2555

NIS2 applies to "essential" and "important" entities across 18 sectors, including digital infrastructure and ICT service management. Key supply chain obligations include:

  • Risk management measures: Entities must implement technical and organizational measures to manage risks to the security of network and information systems, including supply chain security.
  • Incident reporting: Entities must report significant incidents within 24 hours (early warning) and 72 hours (full notification).
  • Management accountability: Senior management is liable for compliance failures, with penalties up to EUR 10 million or 2% of global turnover.

NIS2 explicitly requires entities to address security in the acquisition, development, and maintenance of software, including open-source components.

DORA Regulation (EU) 2022/2554

DORA applies to financial entities (banks, insurers, investment firms, etc.) and has been applicable since 17 January 2025. Its supply chain requirements are even more prescriptive:

  • ICT risk management framework: Financial entities must have a comprehensive framework that covers third-party ICT risk.
  • Third-party risk management: Entities must assess and monitor risks from ICT third-party service providers, including cloud services and software vendors.
  • Incident reporting: Major ICT-related incidents must be reported to competent authorities within timelines specified by the regulation.
  • Digital operational resilience testing: Regular testing, including threat-led penetration testing, is required.

For both frameworks, the use of open-source components introduces risk that must be actively managed.

Actionable Guidance for Compliance

To meet NIS2 and DORA supply chain security requirements and defend against attacks like Mini Shai-Hulud, organizations should implement the following measures:

1. Software Bill of Materials (SBOM)

An SBOM provides a machine-readable inventory of all components in a software product. The US Executive Order 14028 and EU initiatives have made SBOMs a cornerstone of supply chain security. For NIS2 and DORA compliance:

  • Generate SBOMs for all software, including proprietary and open-source.
  • Use standardized formats like SPDX or CycloneDX.
  • Automate SBOM generation in CI/CD pipelines using tools like Syft or Trivy.
  • Cross-reference SBOMs with vulnerability databases (e.g., NVD, GitHub Advisory Database) to identify known vulnerabilities.

2. Dependency Scanning and Continuous Monitoring

Automated scanning of dependencies for vulnerabilities and malicious code is essential. The Mini Shai-Hulud attack would have been detected earlier if organizations had:

  • Used tools like Snyk, Dependabot, or OWASP Dependency-Check to scan for known vulnerabilities.
  • Implemented runtime monitoring to detect anomalous behavior (e.g., unexpected network calls or file access).
  • Monitored for package name squatting or typo-squatting in registries.

3. Vendor Risk Assessments

Both NIS2 and DORA require organizations to assess the security posture of their third-party vendors. For software supply chains:

  • Evaluate vendors' security practices, including their use of SBOMs, vulnerability management, and incident response.
  • Require contractual clauses that mandate security standards and incident notification.
  • Use continuous monitoring tools that track vendor risks in real time. Platforms like AIGovHub's SENTINEL module provide geopolitical and supply chain risk intelligence, monitoring 435+ sources including OFAC sanctions and CISA alerts.

4. Incident Response and Reporting

Under NIS2 and DORA, incident response must be swift and structured. The Mini Shai-Hulud attack demonstrates the importance of:

  • Having a dedicated incident response team and playbook for supply chain incidents.
  • Automating detection and response where possible. For example, AIGovHub's CCM module provides continuous compliance monitoring with ERP connectors and anomaly detection, enabling rapid identification of suspicious changes in software dependencies or CI/CD pipelines.
  • Reporting incidents to authorities within the mandated timelines (24h early warning, 72h full report under NIS2).

5. Secure CI/CD Pipelines

The attack specifically targeted CI/CD secrets. Organizations should:

  • Use short-lived credentials and secret management tools (e.g., HashiCorp Vault, GitHub Actions secrets).
  • Apply least-privilege principles to CI/CD workflows.
  • Audit and monitor GitHub Actions and other automation tools for unauthorized changes.

Key Takeaways

  • The Mini Shai-Hulud attack is a textbook example of a modern supply chain compromise, exploiting trusted maintainer accounts and targeting CI/CD pipelines.
  • NIS2 and DORA impose binding obligations on organizations to manage software supply chain risks, including SBOMs, vendor assessments, and incident reporting.
  • Automated tools for dependency scanning, SBOM generation, and continuous vendor risk monitoring are no longer optional—they are compliance necessities.
  • Integrating compliance monitoring into ERP and CI/CD systems, as offered by platforms like AIGovHub's CCM module, can streamline compliance while reducing risk.

Conclusion: From Reactive to Proactive Supply Chain Security

The Mini Shai-Hulud attack is a stark reminder that software supply chain threats are evolving rapidly. For organizations subject to NIS2 or DORA, compliance is not just about ticking boxes—it's about building resilience. By adopting SBOMs, continuous scanning, vendor risk assessments, and robust incident response, companies can not only meet regulatory requirements but also protect themselves from the next generation of supply chain attacks.

To assess your organization's readiness for NIS2 and DORA supply chain requirements, use AIGovHub's interactive compliance tools to benchmark your current posture and identify gaps in your software supply chain security program.

This content is for informational purposes only and does not constitute legal advice.