Notifications
Clear all
Topic starter
11/06/2026 11:19 pm
TL;DR: Supply chain attacks exploit trusted dependencies, packages, and third-party services to distribute malicious code and steal secrets downstream, according to Orca Security. The real problem is not just compromise, but the trust assumptions built into build pipelines, integrations, and least-privilege boundaries.
NHIMG editorial — based on content published by Orca Security: supply chain attacks and how they exploit trusted dependencies
Questions worth separating out
Q: How should security teams reduce supply chain risk in CI/CD pipelines?
A: Security teams should limit the privilege of build, test, and deployment identities, isolate pipelines by environment, and verify upstream artifacts before they execute.
Q: Why do supply chain attacks so often become identity incidents?
A: They become identity incidents because attackers frequently target the credentials that automation already uses.
Q: What do organisations get wrong about trusting signed packages and tools?
A: They often treat a signature or popular package as proof that runtime execution is safe.
Practitioner guidance
- Tighten build-time secret scope Issue tokens and API keys only to the job that needs them, with the shortest viable lifetime and no reuse across pipelines or repositories.
- Isolate pipeline identities Separate runner, deployment, and registry credentials so compromise in one repository cannot automatically reach unrelated workloads or environments.
- Verify upstream execution before install Check package provenance, maintainer trust, and signing status, but also block unapproved execution paths in CI/CD and developer workstations.
What's in the full article
Orca Security's full blog covers the operational detail this post intentionally leaves for the source:
- Walkthroughs of the SolarWinds, npm, XZ Utils, and GitHub Actions cases with the full attack chain.
- Specific examples of how malicious scripts, post-install hooks, and build-time execution harvested secrets.
- Orca's recommended monitoring approach for cloud workloads, repositories, and CI/CD telemetry.
- The vendor's explanation of how agentless side scanning is positioned across code-to-cloud workflows.
👉 Read Orca Security's analysis of supply chain attacks across code and cloud →
Supply chain attacks: what IAM and DevOps teams miss?
Explore further
12/06/2026 7:55 am
Supply chain security is really trust-chain security. The article shows that the breach path is not limited to code integrity. It includes who is allowed to publish, sign, execute, and inherit trust inside the pipeline. That makes supplier trust, build trust, and execution trust one continuous control problem, not separate ones. Practitioners should treat upstream trust as an identity decision, not a software preference.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: How do teams contain a supply chain compromise before it spreads?
A: Teams should revoke exposed secrets, isolate affected runners, and cut off access from automation identities that could reuse the same credentials elsewhere. The containment goal is to stop the poisoned trust path from reaching other repositories, registries, or cloud environments. The faster the shared identity is disabled, the smaller the blast radius.
👉 Read our full editorial: Supply chain attacks expose the trust model behind modern software
