Notifications
Clear all
Topic starter
04/07/2026 7:48 pm
TL;DR: Supply chain compromises can turn trusted build and release paths into credential-harvesting channels, as shown by the Trivy and LiteLLM incidents in Widefield Security's analysis. Static secrets, mutable tags, and unpinned dependencies create identity exposure that conventional pipeline controls do not contain.
NHIMG editorial — based on content published by Widefield Security: How Supply Chain Attacks Turn Into Identity Risks
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams prevent supply chain compromise from becoming NHI exposure?
A: Security teams should isolate build trust from secret access, pin dependencies to immutable references, and treat every pipeline credential as a governed non-human identity.
Q: Why do unpinned dependencies increase identity risk in CI/CD pipelines?
A: Unpinned dependencies let an attacker change the code a trusted workflow executes without changing the name the pipeline expects.
Q: What do teams get wrong about secrets in build automation?
A: Teams often assume build secrets are safe because the job is temporary, but the credential usually outlives the run.
Practitioner guidance
- Pin dependencies to immutable commit SHAs Replace version tags with full commit hashes for build inputs that can influence privileged execution.
- Separate code checkout from privileged steps Run untrusted pull request content in a context that cannot access repository secrets, publishing tokens, or registry permissions.
- Treat every pipeline secret as an NHI Catalogue PATs, package publish tokens, cloud keys, and service account credentials with owners, scopes, and expiry.
What's in the full article
Widefield Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step reconstruction of the Trivy and LiteLLM attack path through GitHub Actions, tag poisoning, and downstream package release
- Specific malware behaviours used to harvest SSH keys, cloud tokens, Kubernetes credentials, and registry secrets
- Concrete hardening guidance for pull_request_target, dependency pinning, and repository-level secret separation
- Widefield Security's explanation of how ITDR and behavioural baselines help identify legitimate-looking credential abuse
👉 Read Widefield Security's analysis of the Trivy and LiteLLM supply chain compromises →
Supply chain attacks and NHI risk: what IAM teams need to know?
Explore further
04/07/2026 7:52 pm
Software supply chain trust is really NHI trust in disguise. The article shows that the decisive asset is not the code artifact itself but the credentials embedded in the build, release, and dependency path. Once a pipeline can execute external code and inherit broad permissions, the attacker is no longer attacking software integrity alone. The implication is that NHI governance has to extend into the software delivery chain, not sit beside it.
A few things that frame the scale:
- 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, which helps explain why build-time leakage remains a repeatable identity failure mode.
A question worth separating out:
Q: Who is accountable when a compromised pipeline publishes malicious packages?
A: Accountability usually sits with the organisation that issued the publishing credential, maintained the pipeline trust boundary, and failed to constrain release authority. In practice, this is an IAM, DevSecOps, and platform governance issue together, not a developer-only mistake.
👉 Read our full editorial: Supply chain attacks are now identity risks for NHI teams
