Software supply chain risk is the chance that malicious code enters through dependencies, packages, or build tools. NHI risk is the exposure that follows when those tools can access live credentials, service accounts, or tokens. In practice, the two overlap whenever developer systems hold secrets that production services trust.
Why This Matters for Security Teams
Software supply chain risk and NHI risk are often discussed together because both can start in developer tooling, build systems, or dependencies. The difference is where the blast radius lands. A malicious package is bad on its own; a malicious package that can reach live secrets, service accounts, or production tokens becomes an identity problem. That is why NHI governance sits at the point where code integrity meets access control.
Practitioners should also recognise that secrets exposure is a recurring pattern, not an edge case. NHIMG’s 52 NHI Breaches Analysis shows how often compromised machine identities are tied to downstream incidents, while the Ultimate Guide to NHIs — What are Non-Human Identities helps frame why service accounts, tokens, and automation credentials deserve their own control model. External guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 reinforces the same point: identity hygiene and access governance must extend beyond human users.
In practice, many security teams encounter the identity side of supply chain risk only after a trusted build system has already used stolen credentials to reach production.
How It Works in Practice
The operational difference is straightforward. Software supply chain risk focuses on the integrity of what gets built, fetched, and executed. NHI risk focuses on what those systems can touch once they are trusted. If a CI runner, dependency installer, or build plugin has access to long-lived secrets, the attacker does not need to stay inside the original malicious package for long. They can pivot into the identity layer and reuse the trust that production already grants.
That is why current guidance suggests treating secrets as the bridge between the two problems. A package compromise becomes an NHI event when it can read tokens from environment variables, vault mounts, artifact stores, or developer workstations. NHIMG’s Top 10 NHI Issues and the Shai Hulud npm malware campaign illustrate how code execution and secret theft can become the same incident. The Reviewdog GitHub Action supply chain attack is another reminder that trusted automation often has wider access than teams realise.
- Reduce standing access in build and automation systems.
- Use short-lived credentials where possible, not static secrets baked into workflows.
- Separate package verification from runtime privilege so a poisoned dependency cannot automatically reach production trust.
- Track which service accounts, tokens, and API keys are reachable from developer tooling.
Security teams should align this with least-privilege controls and runtime monitoring, not just dependency scanning. The problem is not only whether code is malicious, but whether code execution can reuse trusted NHI permissions. These controls tend to break down in legacy CI/CD environments that rely on shared runners and long-lived secrets because every job inherits more privilege than it needs.
Common Variations and Edge Cases
Tighter secret controls often increase operational overhead, requiring organisations to balance deployment speed against credential churn and access review effort. That tradeoff is especially visible in fast-moving engineering teams, where ephemeral credentials and per-job authorisation can feel slower than a shared token. Best practice is evolving, but the direction is clear: the fewer standing secrets exposed to tooling, the less supply chain compromise can turn into identity compromise.
One common edge case is open-source dependency pipelines. A package may be malicious, but the higher risk appears only when the pipeline can access cloud credentials, signing keys, or internal APIs. Another is developer workstations. Compromise there can look like ordinary endpoint risk until an attacker discovers cached tokens, SSH keys, or cloud CLI profiles. NHIMG’s LiteLLM PyPI package breach and Cisco DevHub NHI breach show how quickly a software trust issue becomes an identity exposure when credentials are reachable.
There is no universal standard for this yet, but the practical pattern is consistent: treat build systems, agents, and automation as NHIs with scoped authority, monitor their secret access, and shorten the lifetime of every credential they can see. That approach lines up with both the Ultimate Guide to NHIs and the OWASP NHI Top 10, because the real hazard is not just compromised code. It is compromised code with someone else’s trust still attached.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret exposure is the pivot from supply chain compromise to NHI risk. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits how far compromised build systems can move. |
| NIST AI RMF | Autonomous tooling needs governance over how machine actors use access. |
Inventory secrets in tooling and replace standing credentials with short-lived access.
