CIO Influence caught up with Aaron Mitchell to discuss the growing gap between what AI can uncover and what companies and maintainers can realistically fix and how enterprises can adapt software supply chain security to keep pace with AI-driven vulnerability discovery. Catch the complete Q&A:
_________
AI-driven vulnerabilities are becoming a growing concern for IT teams, CIOs, and CISOs. What are some of the latest AI vulnerabilities that have been most challenging for these teams lately?
AI is scaling vulnerability discovery at machine speed, but remediation still depends on human teams to validate findings, develop fixes, test patches, and deploy them. A recent analysis of Anthropic’s Project Glasswing shows how quickly that gap can grow. Claude Mythos generated more than 26,000 vulnerability findings, but only about 10% reached disclosure, and just 202 were listed as fixed in VulnCheck’s analysis. AI can dramatically increase the number of potential vulnerabilities teams need to address, but it does not eliminate the work required to turn those findings into fixes.
We’re also starting to see AI systems move beyond vulnerability discovery into active exploitation. In the recent Hugging Face incident, an AI agent operating during a cybersecurity evaluation escaped its test environment, exploited vulnerabilities, reached production systems, and accessed internal datasets and credentials. That kind of incident highlights a growing concern for CIOs and CISOs: AI can compress the time between identifying a weakness and acting on it, while defenders still have to validate, patch, test, and deploy fixes through normal operational processes.
That challenge becomes even greater when AI uncovers vulnerabilities in unsupported or end-of-life software. With actively maintained software, there is typically an upstream team responsible for validating vulnerabilities and releasing patches. Once software reaches end of life, that path may no longer exist. The original maintainers may have moved on and official security patches may have stopped, even though enterprises still rely on the software in critical production systems.
Also Read: CIO Influence Interview with Srinivasan Panchapakesan, Chief Platform Officer at Hexaware
For enterprises relying on open source components, what optimization processes should be established as core fundamentals?
Open source is foundational to modern enterprise software, but organizations may be managing hundreds of components and thousands of dependencies across their environments, including aging or unsupported software they may not even realize they are running. In fact, 93% of commercial code bases contain open source components that have gone at least two years without active maintenance, creating a significant visibility and security blind spot for enterprises.
The fundamentals come down to knowing what open source components you rely on, understanding their support status and criticality to your applications, and having a plan to keep them secure over time.
Enterprise leaders should focus on three priorities:
Build complete visibility. Maintain visibility across direct and transitive dependencies, including where they are used, whether they are actively supported, and which business-critical applications depend on them. Unsupported software should be identified before a vulnerability, audit, or incident forces the issue.
Plan ahead for lifecycle changes. Build lifecycle planning into development, procurement, and modernization strategies. Teams should know when critical software is approaching end of life and have a plan to keep it secure while an upgrade or migration is underway.
Make supportability a shared responsibility. Open source risk does not end with the engineering team. When critical software becomes unsupported, it can create security, compliance, and operational risk across the business. Organizations need clear ownership and a long-term strategy for maintaining the software their operations depend on.
How can enterprises adapt software supply chain security to keep pace with AI-driven vulnerability discovery?
AI has accelerated the pace of vulnerability discovery, but it doesn’t solve for the finite time and resources security teams have to validate findings, determine exposure, and remediate what matters.
That makes prioritization critical. As organizations introduce more AI-powered security tools, they may also receive conflicting recommendations. One tool may recommend an immediate migration, another may flag compliance exposure, while a third surfaces a vulnerability that is not actually exploitable in the organization’s environment.
Enterprises need a clear framework for separating signal from noise and determining what requires immediate remediation, what can be mitigated, and what belongs in a longer-term modernization plan. That requires understanding not only the vulnerability, but where the affected software is running, whether it is reachable, whether it is still supported, and who owns remediation.
Just as importantly, software supply chain security needs to account for whether a remediation path actually exists. If a vulnerable component is end-of-life and the original maintainers are no longer issuing fixes, detecting the problem is only the first step. Enterprises need a plan for securing that software through trusted patches and ongoing support while they modernize on a timeline that works for the business.
How can engineering teams spot risky open source dependencies earlier?
The starting point is visibility. The biggest open source risk in an application may be a dependency no one knowingly chose.
A single open source package can bring in a chain of direct and transitive dependencies, each with its own security and maintenance lifecycle. Teams need to understand not only what is in their environment, but whether those components are actively maintained, how security issues are handled, when support ends, and who is responsible when it does.
Too often, open source security becomes a game of whack-a-mole: scan, find a CVE, patch it, and repeat. As AI increases the volume of vulnerabilities being discovered, that approach becomes harder to sustain. Engineering teams need to identify lifecycle risk earlier and continuously track whether the software they depend on remains supported and secure.
What should companies do before critical open source reaches end of life, limiting their options for upgrading or remediation?
End of life should be a planning event, not an emergency.
Organizations should know when critical components are approaching the end of life and determine their path forward in advance. That may mean upgrading, migrating to another technology or putting extended security support in place while a longer-term modernization effort is underway.
“Just upgrade” is not always realistic. Business-critical applications may have years of custom code, integrations and downstream dependencies tied to a particular version. Moving off that software can take months or years, and rushing the process can introduce additional operational risk.
What does it take in terms of processes to ensure complete compliance and security today: breakdown what you feel IT teams should be doing more of on a day to day basis?
There is no process that guarantees complete security or compliance, but there are a few fundamentals enterprises should practice continuously.
It starts with treating software security as an ongoing process rather than a point-in-time exercise. Teams need to continuously monitor what software is running across the organization, track changes in its support and security status, and understand where vulnerabilities create actual exposure.
From there, organizations need clear ownership. When a new vulnerability is identified, there should be a defined process for determining who is responsible, how quickly it needs to be addressed, and whether the right response is to patch, mitigate, upgrade, or plan for a longer-term migration.
Catch more CIO Insights: The Overlooked Security Risk Behind Enterprise AI Rollouts
[To share your insights with us, please write to psen@itechseries.com ]
