Mini Shai-Hulud supply chain attack exposes SAP secrets

At a glance

What this is: This is a supply chain attack against SAP development ecosystem packages that used malicious preinstall hooks to steal secrets from developer machines and CI environments.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat build-time dependencies as identity-risk entry points where tokens, cloud credentials, and Kubernetes access can be exposed and reused.

👉 Read Semgrep's analysis of the Mini Shai-Hulud npm supply chain attack

Context

The primary problem here is not just malware in a package, but secret exposure inside developer and CI identity paths. In this case, malicious npm dependencies were inserted into SAP workflow tooling and used preinstall execution to reach credentials that security teams often do not inventory as first-class identities.

For identity programmes, this is a classic NHI governance failure mode: secrets in build systems are frequently overtrusted, long-lived, and poorly segmented from developer machines. When those tokens can reach GitHub, cloud consoles, secret managers, and Kubernetes, the blast radius extends well beyond the original package compromise.

Key questions

Q: How should teams respond when a malicious npm package can steal build secrets?

A: Treat the package as a credential exposure event, not just a dependency incident. Revoke and rotate every secret that the affected build environment could access, then inspect GitHub, CI runners, and secret manager logs for abnormal access, repository creation, and unexpected automation artefacts.

Q: Why do supply chain attacks on developer tools create such large identity risk?

A: Developer tools often run with trusted access to cloud, source control, and orchestration systems, so compromise turns one execution context into a multi-system identity event. Attackers can validate stolen secrets immediately and use them for discovery, lateral movement, and bulk extraction before normal review cycles respond. That is why pipeline trust must be governed like privileged access.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: What should organisations do first after detecting suspicious package installation behaviour?

A: Preserve evidence, stop the affected build paths, and inventory which identities and secret stores were reachable from those systems. Then look for repository markers, unexpected script files, and commit patterns that indicate the attacker already exfiltrated data before containment.

Technical breakdown

How malicious preinstall hooks turn dependencies into execution paths

npm preinstall hooks run automatically during installation, before a developer has a chance to inspect runtime behaviour. That makes them a high-trust execution path for supply chain abuse because package code can fetch additional payloads, stage obfuscated scripts, and start collecting local artefacts immediately. In this campaign, the malicious packages downloaded the Bun runtime and launched an obfuscated payload from the install process itself. The technical risk is not just the package contents, but the authority granted to installation-time code in developer and CI environments.

Practical implication: block or tightly control install-time script execution for high-risk dependencies and review package provenance before allowing automated builds.

How credential theft from developer machines becomes NHI compromise

Once a malicious package reaches a workstation or runner, it can collect the same secrets that identity teams use to connect systems: GitHub tokens, npm tokens, cloud credentials, secret manager values, Kubernetes tokens, and environment variables. These are non-human identities in practice because they authorize machines and pipelines, not people. The attacker then uses the stolen material to write exfiltrated results, create marker repositories, and potentially pivot into wider automation and deployment systems. The core issue is that one compromised build context can expose multiple downstream identities at once.

Practical implication: classify developer tooling secrets as governed NHI credentials and segment them by purpose, environment, and blast radius.

Why encrypted exfiltration and GitHub markers matter for detection

This campaign used encrypted result files and a distinctive GitHub repository description to signal successful theft and potentially support propagation. The attacker path left artefacts such as results JSON files, unexpected setup scripts, and commits that look like dependency maintenance. These markers matter because supply chain attacks often avoid obvious malware signatures and instead blend into normal developer activity. Detection therefore depends on identity-aware telemetry, repository behaviour monitoring, and build artefact inspection rather than simple binary scanning.

Practical implication: monitor for anomalous repository creation, commit metadata, and unexpected secret access from build accounts and developer identities.

Threat narrative

Attacker objective: The attacker aims to steal reusable development and cloud credentials that can be used for broader access, persistence, and downstream supply chain abuse.

1. Entry occurred through compromised npm packages embedded in SAP development workflows, where preinstall hooks executed before normal developer scrutiny.
2. Credential access followed as the payload gathered GitHub tokens, npm tokens, cloud credentials, secret manager values, Kubernetes tokens, and local environment secrets from developer machines or CI runners.
3. Impact came from secret theft and exfiltration, with attacker-created repositories and encrypted result files indicating successful collection and possible follow-on abuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mini Shai-Hulud is not just package malware, it is identity theft through build trust. The campaign shows that software installation paths can function as credential collection channels when packages are allowed to execute code during install. For identity governance, the important boundary is not the repository alone but every identity that the build process can touch. Practitioners should treat install-time execution as an identity exposure surface, not a development convenience.

Build secrets are NHI assets, even when humans first handle them. GitHub tokens, cloud keys, Kubernetes tokens, and secret manager values become machine identities once they are embedded in automation or developer tooling. This campaign exposed how many programmes still fail to separate developer access from workload access. The practical conclusion is that one compromised workstation can become a multi-system identity breach.

Secret sprawl creates identity blast radius long before exfiltration occurs. The article shows attackers targeting environments where one package can reach multiple secret types across local tooling, CI runners, and deployment systems. That is a governance problem, not just a malware problem, because the same credential often works across several services. The key concept here is developer-to-deployment identity collapse: a single install path can bridge human, NHI, and automation access into one exploitable trust chain. Practitioners need to map that bridge explicitly.

Marker-based exfiltration shows why repository behaviour must be part of security monitoring. The creation of distinctive repositories, suspicious commit messages, and unexpected files indicates that modern supply chain attacks leave behavioural evidence in code platforms. That shifts detection away from static scanning alone and toward identity and activity telemetry. Security teams should assume that a package compromise may manifest first as abnormal repository activity, not as endpoint alerts.

Secret rotation after compromise is a breadth exercise, not a token-by-token task. The payload targets many credential classes at once, so any response based on a single revoked token underestimates the problem. This is exactly the kind of event that exposes weak lifecycle governance across developer and machine identities. The implication is simple: access accountability must extend across every secret class that a build environment can inherit or mint.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That gap is consistent with the Top 10 NHI Issues, which highlights how secret sprawl and weak lifecycle discipline keep expanding the attack surface.

What this signals

Developer tooling is now part of the NHI control plane. When build systems can access tokens for GitHub, cloud services, and secret managers, the distinction between software supply chain risk and identity risk disappears. Organisations that still treat build credentials as peripheral will keep discovering that the compromise path is shorter than their review cycle can react.

With 6 distinct secrets manager instances on average in the broader market, fragmentation makes it harder to know which credentials were reachable from a compromised pipeline, according to The State of Secrets in AppSec. That means the operational challenge is not only rotation, but also proving where secrets live and which identities can touch them.

Developer-to-deployment identity collapse: programmes should now map how one install event can bridge source control, cloud access, and secret storage. The right response is tighter entitlement separation, better telemetry on repository behaviour, and explicit ownership for every credential class used in build paths.

For practitioners

• Treat install-time scripts as a governed execution path Disable or restrict preinstall and similar package hooks in high-risk pipelines, especially where build agents can reach production secrets, cloud consoles, or deployment automation. Review dependency policies so that code execution during install is explicitly approved, not assumed safe.
• Rotate every credential class exposed to build environments If affected packages were installed, rotate GitHub tokens, npm tokens, GitHub Actions secrets, AWS secrets, Azure Key Vault secrets, GCP Secret Manager values, Kubernetes tokens, and any local developer tooling credentials that may have been present.
• Monitor repository activity for supply chain indicators Search for repositories with the description A Mini Shai-Hulud has Appeared, commits containing OhNoWhatsGoingOnWithGitHub, unexpected .claude/ or .vscode/setup.mjs files, and result files under results/results-*.json.
• Separate developer identity from deployment authority Reduce the overlap between interactive developer access and automation credentials so one compromised machine cannot directly reach build, cloud, and secret manager trust zones. Use distinct identities, narrower scopes, and environment-specific credentials for each stage.

Key takeaways

• This attack turned package installation into a secret-harvesting path, showing that build trust and identity trust are now the same problem.
• The compromise mattered because a single malicious dependency could reach multiple credential classes across developer and CI environments.
• Containment requires broad secret rotation, repository investigation, and narrower separation between developer access and deployment authority.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Developer-to-deployment identity collapse: Developer-to-deployment identity collapse is the condition where interactive developer credentials and automation credentials overlap enough to create one shared blast radius. A single compromise can then bridge source control, cloud access, and secret stores instead of staying confined to a workstation.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Credential exfiltration: Credential exfiltration is the theft of usable authentication material such as tokens, keys, or certificates. In NHI environments, the stolen item is often already valid and can be replayed immediately. That is why detection must be paired with revocation and entitlement review rather than relying on alerts alone.

What's in the full analysis

Semgrep's full blog post covers the operational detail this post intentionally leaves for the source:

• Package version checks and advisory matching for the affected SAP development dependencies
• Repository and commit indicators of compromise that help confirm whether exfiltration occurred
• Broader remediation guidance for rotating exposed secrets across GitHub, cloud, and Kubernetes environments
• Specific scan and dependency filter actions for Semgrep customers who need to validate exposure

👉 Semgrep's full post covers the affected package list, indicators of compromise, and remediation guidance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.