Topic starter
02/08/2026 11:23 am
TL;DR: Safe remediation is now as important as finding vulnerable dependencies, as software supply chain attacks accelerate and nearly a third of known vulnerabilities are exploited on or before disclosure, according to Aikido. Patch workflows need to preserve production stability while reducing the window between disclosure and exploitation.
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: 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.
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.
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.
Glossary terms: Software Supply Chain Security, Patchability gap, Non-Human Identity (NHI), CI/CD runner
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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: Root acquisition puts patchable supply chain risk in focus
This post was modified 2 days ago by NHI Mgmt Group