Notifications
Clear all
Topic starter
22/08/2026 12:00 pm
TL;DR: Supply chain attacks succeed because they target trusted upstream components, bypassing perimeter assumptions and spreading through software update channels, according to ArmorCode. The article argues that CVSS-only prioritisation and fragmented tooling leave teams blind to real exposure, so unified visibility and context-rich remediation are now essential.
NHIMG editorial — based on content published by ArmorCode: Supply Chain Attacks: How They Happen, Why They Succeed, and How to Stop Them
By the numbers:
- The average cost of a single breach has now reached $4.99 million, a 12% increase over last year.
- The September 2025 NPM supply chain attack compromised at least 27 packages through a phishing campaign.
Questions worth separating out
Q: What breaks when a package maintainer account is compromised?
A: When a maintainer account is compromised, the attacker inherits trusted publishing rights and can turn legitimate release channels into malware distribution paths.
Q: Why do supply chain attacks stay effective even with vulnerability scanners?
A: Scanners are useful, but they cannot by themselves determine whether a dependency is reachable, deployed, or being pulled into production through automation.
Q: How can organisations reduce risk from vulnerable dependencies without slowing delivery?
A: Set risk thresholds that allow routine updates to flow while forcing review for high-severity or internet-exposed components.
Practitioner guidance
- Map trusted release identities Inventory maintainers, signing keys, CI service accounts, and package publishing tokens that can introduce code into production.
- Tie SBOM data to runtime exposure Connect software bills of materials to production inventory so you can answer which deployed applications contain a vulnerable dependency and where it entered the pipeline.
- Prioritise by exploitability and reachability Use EPSS, known exploited vulnerability data, package reachability, and business impact to rank remediation work.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- The article’s workflow for unified visibility across SCA, container, and CI/CD findings so teams can trace exposure faster.
- The prioritisation model combining EPSS, CISA KEV, business impact, reachability, and exploitability for remediation triage.
- The discussion of agentic remediation and how teams can compress MTTR from months to hours in practice.
- The supply chain control plane approach for correlating SBOM data with runtime and build-path context.
👉 Read ArmorCode's blog on how supply chain attacks happen and how to stop them →
Supply chain attacks and the governance gap teams keep missing?
Explore further
22/08/2026 12:02 pm
Trust is the real attack surface in supply chain compromise. The article shows that attackers do not need to break encryption or exploit a perimeter if they can hijack a maintainer account, package registry identity, or build workflow. That makes identity governance part of software supply chain security, especially where publishing credentials and automation tokens are persistent. Practitioners should treat upstream trust as a governed identity lifecycle, not a static vendor relationship.
A question worth separating out:
Q: Who is accountable when a trusted upstream package is poisoned?
A: Accountability usually spans the publishing organisation, the platform team that allowed persistent release credentials, and the security team that failed to govern supply chain trust end to end. Frameworks such as NIST CSF and NIST SP 800-53 expect access control, monitoring, and lifecycle management for high-risk identities and release paths.
👉 Read our full editorial: Software supply chain attacks exploit trust, not just vulnerabilities
