Notifications
Clear all
Topic starter
18/08/2026 2:16 pm
TL;DR: AI-assisted development and AI-assisted exploitation are accelerating vulnerability volume, supply chain risk, and remediation pressure, while teams still need to decide which flaws are reachable, widespread, and worth fixing first, according to Kusari. The practical shift is from chasing every finding to prioritising exploitability, production impact, and dependency lifecycle risk.
NHIMG editorial — based on content published by Kusari: vulnerability prioritisation in the age of AI-driven supply chain risk
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when security teams try to fix every vulnerability equally?
A: Teams lose time on low-value findings, miss exploitable issues, and create remediation fatigue.
Q: When should organisations prioritise dependency control over patch volume?
A: They should prioritise dependency control when upstream packages change quickly, when builds auto-promote artifacts, or when the same library is reused across many services.
Q: What do security teams get wrong about software supply chain risk?
A: They often focus on known vulnerabilities inside dependencies and miss the trust path that delivers the software.
Practitioner guidance
- Add reachability to vulnerability triage. Score findings by whether the vulnerable code path is actually invoked in production, whether the feature is enabled, and whether the component is externally reachable.
- Introduce dependency cooldown policies. Delay automatic promotion of new packages for a defined validation period unless the update is security-critical.
- Audit CI/CD and release credentials. Inventory the service accounts, tokens, and signing keys that move code from commit to production, then reduce their standing access and shorten their lifetime.
What's in the full article
Kusari's full blog post covers the operational detail this post intentionally leaves for the source:
- Reachability analysis logic for deciding when a vulnerability is exploitable in a specific code path.
- AutoFix workflow detail for verifying dependency updates before they reach production.
- Inspector feedback mechanics for pull request review and developer-side prevention.
- VEX generation context for communicating non-reachable vulnerabilities to customers or regulators.
👉 Read Kusari's analysis of AI-driven vulnerability prioritisation and supply chain risk →
AI-driven vulnerability sprawl: what appsec teams need to prioritise?
Explore further
18/08/2026 3:09 pm
AI has turned vulnerability prioritisation into a governance discipline, not a scanner output problem. The article is right that teams cannot treat every finding equally when code volume and attack volume are both accelerating. The control question is no longer whether a vulnerability exists, but whether it is reachable in production and whether it can realistically move an attacker toward impact. That is a governance failure mode, not just an engineering backlog issue. Practitioners should use reachability and business context as the first triage filters.
A question worth separating out:
Q: How should teams govern build and release identities in appsec?
A: Treat build and release credentials as privileged machine identities with limited scope, short lifetimes, and strict ownership. If those identities can sign, deploy, or fetch dependencies broadly, a code flaw can become a platform-wide incident. Identity controls should be part of every vulnerability remediation discussion.
👉 Read our full editorial: Vulnerability sprawl and AI-driven attack chains are reshaping appsec
