Notifications
Clear all
Topic starter
18/08/2026 2:31 pm
TL;DR: AI models are compressing the time between disclosure and exploitation, with Rapid7 finding the median gap to CISA’s KEV catalog fell from 8.5 days to 5 days in one year, according to FOSSA. That shift makes dependency freshness and remediation throughput a governance problem, not just an engineering backlog.
NHIMG editorial — based on content published by FOSSA: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- A study reported a 1,466 percent increase in release frequency between 2014 and 2023.
- Before 2016, there had never been a year with more than 8,000 published CVEs, but 2023 climbed past 28,000.
Questions worth separating out
Q: How do security teams reduce risk from AI-assisted exploit research?
A: By assuming research timelines are shorter and by tightening the time between disclosure, validation, and mitigation.
Q: Why do outdated dependencies matter more when attackers use AI?
A: AI lets attackers scan more code, identify likely weaknesses faster, and chain known issues with less manual effort.
Q: What do security teams get wrong about vulnerability backlogs?
A: They often treat the backlog as a queue of work rather than a warehouse of unresolved risk.
Practitioner guidance
- Measure exploitability latency for critical dependencies Track the time from vulnerability disclosure to patch deployment for packages that sit near authentication, secrets, or service-to-service trust paths.
- Prioritise dependencies that can expose NHIs Classify packages by whether a flaw could reveal tokens, API keys, service credentials, or workload identities, then route those items ahead of generic code-quality work.
- Automate upgrade completion, not just upgrade discovery Use workflows that can research breaking changes, apply compatible code updates, and hand back a completed pull request instead of another backlog item.
What's in the full article
FOSSA's full article covers the operational detail this post intentionally leaves for the source:
- How fossabot researches breaking changes and turns dependency updates into completed pull requests.
- The specific workflow for handling upgrades that require engineering judgment instead of simple version bumps.
- Why AI-assisted remediation is framed as a complement to, not a replacement for, conventional software composition analysis.
- The article’s view on how Project Glasswing may influence secure software development and open source maintenance.
👉 Read FOSSA’s analysis of AI-enabled vulnerability exploitation and dependency risk →
AI-driven exploit speed: what IAM and security teams need to change?
Explore further
18/08/2026 3:18 pm
AI has turned remediation speed into a primary security control. The article is right to focus on exploit velocity, but the governance change is broader than patch management. When exploitation follows disclosure in days, organisations are no longer judged only on whether they found the weakness. They are judged on whether they can complete remediation before the weakness becomes operationally relevant. That aligns directly with NIST-CSF and the operational intent of continuous improvement, but the real lesson is that slow remediation is now exposure, not backlog. Practitioners should treat upgrade throughput as a measurable control outcome.
A question worth separating out:
Q: How do organisations prove a control remediation is working?
A: They need repeated evidence over a meaningful period, not a single clean test. That means the control must operate under normal conditions, produce auditable artefacts, and address the original root cause. In practice, sustained performance matters more than a one-time validation exercise.
👉 Read our full editorial: AI-driven exploit speed is shrinking defenders’ patch windows
