Topic starter
02/08/2026 11:23 am
TL;DR: As supply chain attacks accelerate and nearly a third of known vulnerabilities are exploited on or before disclosure, the governance challenge is no longer just finding vulnerable dependencies, but controlling how fast organisations can patch them without creating new operational risk, according to Aikido.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Aikido acquires Root to secure the supply chain”.
By the numbers:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
Key questions
Q: What breaks when software supply chain patching is too slow?
A: Teams end up with a widening gap between vulnerability discovery and safe remediation.
Q: Why do vulnerable dependencies remain a security problem after they are found?
A: Because discovery does not equal remediation.
Q: What are the signs that supply chain patching is failing?
A: Look for long remediation queues, repeated exceptions for the same libraries, frequent production breakage after upgrades, and growing reliance on manual triage rather than repeatable fix workflows.
Practitioner guidance
- Inventory patchability by dependency version Map which production packages can be safely patched today, which require code changes, and which have no viable upgrade path without service disruption.
- Govern build and release identities Review the service accounts, tokens, and CI/CD runners that can publish or replace artefacts, and narrow their permissions to the minimum needed for each pipeline stage.
- Set remediation SLAs by exploitability and deploy risk Prioritise actively exploited vulnerabilities first, but score each item for operational impact so high-risk fixes do not get blocked behind generic severity queues.
Bottom line: The article shows that software supply chain security is now as much about safe remediation as it is about vulnerability detection.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:40 pm
Software supply chain patchability is now a governance control, not just an engineering convenience. The article shows why discovery-first security fails when remediation cannot keep pace with disclosure. A team can know a CVE exists and still remain exposed if the fix is incompatible, unavailable, or too disruptive to deploy. Practitioners should treat patchability as part of the control design itself.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should security teams govern software supply chain risk when CI/CD identities can publish code?
A: Security teams should treat CI/CD accounts, signing keys, and release tokens as high-risk identities with least privilege, scoped access, and rotation requirements. The goal is to make one compromised credential unable to sign, publish, and deploy in the same chain. That means separate duties, short-lived access where possible, and logging that ties every build action to a specific identity.
👉 Read our full editorial: Aikido acquires Root: supply chain patching and NHI risk