AI is changing the cybersecurity landscape on both sides: it is helping organisations discover vulnerabilities faster, while also enabling attackers to scale and accelerate their activity. For technology leaders, the challenge is no longer just identifying weaknesses, but understanding which exposures matter most and getting effective fixes safely into production. In this CIONET Trailblazer, Jeff Lo, Vice President, Portfolio at Red Hat, explores how AI is reshaping vulnerability and exposure management, open-source software security, and the practical realities of remediation in complex enterprise environments.

Attackers have been very quick to leverage AI. How is AI increasing organisations’ attack surface, and what should CIOs and CISOs be paying particular attention to?

AI is changing the security equation on both sides. Organisations are giving AI agents access to more applications, data and infrastructure. At the same time, attackers are using AI to automate activities that previously required significant human effort. We’re already seeing this in practice. Google Threat Intelligence reported an attack in which criminals used AI agents to build and execute a credential-harvesting campaign in under six hours. The concern isn’t some science-fiction scenario. It’s that familiar threats are now becoming faster and more scalable.CIOs and CISOs need to focus on identity, access privileges, API security and the dependencies connecting their systems. But just as importantly, they need to ask whether their security and engineering teams can respond at the pace these threats are evolving.

AI has dramatically shortened the time between the discovery of a vulnerability and its exploitation. How are organisations adapting to this new reality?

We’re getting much better at finding vulnerabilities. The harder question is whether we’re getting equally good at fixing them. Google Threat Intelligence reported that monthly vulnerability disclosures rose from 5,045 in January 2026 to 10,740 in August. Observed exploitation also increased, from an average of 10.5 vulnerabilities per month in 2025 to 18 per month in January–August 2026. But not every vulnerability represents the same risk. The same research found that only about 0.23% of disclosed vulnerabilities in its 2026 dataset were observed being exploited. So the answer isn’t simply scanning more or patching everything indiscriminately. It’s understanding what matters and reducing the time between identifying a serious exposure and remediating it.NIST has called for moving beyond periodic patching towards continuous, contextual and increasingly automated vulnerability management. And that’s the real challenge: finding a vulnerability quickly doesn’t mean an enterprise can safely fix it in production just as quickly.

What is the difference between vulnerability management and exposure management, and how can organisations create synergies between the two?

I think about it this way: vulnerability management tells you what’s broken. Exposure management helps you understand what could actually hurt the business. You might have the same vulnerability in two applications, but one is isolated in a development environment while the other supports critical customer transactions. Clearly, they shouldn’t automatically receive the same priority. Exposure management brings in business context, exploitability, reachability and potential attack paths. Vulnerability management and engineering teams then turn those priorities into fixes.CISA’s Known Exploited Vulnerabilities catalogue is one practical example of using evidence of real-world exploitation to inform remediation decisions. The goal isn’t to produce a longer list of findings. It’s to make sure the vulnerabilities that matter most are the ones organisations can act on first.

There used to be a saying that “defenders think in lists and attackers think in graphs”. Is AI now enabling defenders to build a more complete picture of their risk exposure?

I think that’s one of AI’s most promising applications in cybersecurity. An attacker doesn’t look at a spreadsheet of vulnerabilities and stop there. They look for connections: an exposed service, a compromised identity, an outdated dependency and a route into a critical system.AI offers defenders an opportunity to analyse those relationships at scale. Instead of treating each finding independently, security teams can start identifying combinations of weaknesses that could create meaningful attack paths. Of course, AI-generated correlations still need to be validated. A theoretical attack path isn’t necessarily an exploitable one. But the change in thinking is important. Rather than asking how many vulnerabilities we have, we should be asking which weaknesses an attacker could realistically combine to compromise something that matters.

What impact does machine-speed discovery and remediation have on the way organisations design and operate their software architectures?

I think we need to start designing software to be remediable by design, not just secure by design. There’s not much value in discovering a vulnerability in minutes if fixing it requires weeks of engineering work, regression testing and release coordination. That means knowing exactly which dependencies applications use, where software artefacts come from and how changes move through testing into production. NIST’s Secure Software Development Framework reinforces the importance of integrating security throughout software development. But there’s another reality enterprises face. Some business-critical applications depend on software versions that simply cannot be upgraded quickly without introducing significant operational risk. That’s why organisations need more than one remediation path. Upgrade when practical. When it isn’t, have another trusted way to address eligible vulnerabilities without forcing a disruptive application change.

Integrating AI tools into the software development lifecycle is one thing, but what additional risks and considerations arise around open-source dependencies?

Open source is foundational to modern enterprise software, but applications often depend on hundreds of components and versions that developers don’t directly maintain.AI makes this more complicated. It can accelerate development and vulnerability discovery, but it can also introduce dependencies faster than organisations can properly evaluate them. Google Threat Intelligence has documented attackers targeting the intersection of AI-assisted coding and open-source software supply chains. So there are three questions every organisation needs to answer: What software are we actually running? Can we trust where it came from? And what happens when we discover a vulnerability? Software inventories, SBOMs and provenance help address the first two. The third is where things get difficult.A scanner can tell you which library is vulnerable. It can’t necessarily make the application safely consume a newer version. That’s why open-source security needs to go beyond discovery and address the practical realities of remediation.

What kind of governance do organisations need around open-source components and trusted software supply chains, and how is AI changing that challenge?

The fundamentals haven’t changed, but AI is making it harder to rely on manual processes. Organisations still need to know what software they’re consuming, where it originated, how it was built and who is accountable when something goes wrong.NIST’s cybersecurity supply-chain guidance provides a framework for identifying, assessing and managing those risks. That means trusted software sources, accurate dependency inventories, provenance, clear remediation policies and defined responsibilities for testing and deployment.AI can make those processes faster, but it shouldn’t bypass them. The goal isn’t to remove humans from software security. It’s to remove the repetitive work that prevents security and engineering teams from making timely, informed decisions.

Red Hat is also addressing this challenge through its approach to continuously updating and securing software environments. Can you explain how this works in practice and how it helps organisations stay ahead of emerging AI-related threats and vulnerabilities?

One of the problems we’re addressing at Red Hat is what happens after a vulnerability is discovered, particularly when the affected software is difficult to upgrade. That’s where Lightwell comes in. Lightwell helps enterprises remediate eligible vulnerable open-source dependencies at versions they already use, rather than making every fix depend on adopting a newer upstream release. In practice, Red Hat provides secured repositories with validated and remediated software content. Lightwell’s Remediated repository provides backported security fixes, while its Validated repository serves a different purpose: trusted builds and verification of upstream content. Customers integrate the appropriate content into their existing software workflows, with dependency configuration changes where required, and remain responsible for application testing and production deployment. We’re not replacing scanners or automating every part of software delivery. We’re addressing a critical gap between finding a vulnerability and having a practical way to fix it.

How does this approach differ from traditional upgrades, particularly when organisations need to balance security with compatibility, certification, release, audit and production requirements?

The traditional advice is straightforward: if a dependency has a vulnerability, upgrade to a version where it’s fixed. And when that’s practical, organisations should absolutely do it. But anyone who’s managed enterprise software knows it’s not always that simple. An upgrade might change APIs, trigger extensive regression testing, affect a certified environment or require an entirely new release cycle. Lightwell offers another option for eligible open-source dependencies. Current coverage includes Maven/Java and Python/PyPI libraries, with additional ecosystems such as .NET and JavaScript/npm planned. Instead of requiring a conventional upstream version upgrade, Red Hat can provide a backported security fix for the dependency version the organisation is using. The remediated artefact has a Lightwell-specific version identifier and must be incorporated into the customer’s build and testing processes. That doesn’t eliminate engineering work or guarantee compatibility. But it can reduce unnecessary dependency-version movement while giving teams a practical remediation path. For businesses running critical applications, the ability to address vulnerabilities without forcing every application through a major upgrade is an important distinction.

Looking ahead, how do you see the relationship between AI, software security and open source evolving, and what should technology leaders be preparing for now?

I believe we’re moving towards a world where finding vulnerabilities becomes progressively easier, but fixing them effectively becomes a more valuable capability. Google’s latest threat intelligence points to growing vulnerability discovery and exploitation activity. NIST is calling for more continuous and contextual vulnerability management. But here’s the important distinction: finding more vulnerabilities doesn’t automatically make software more secure. Technology leaders need to invest in knowing what software they run, understanding which exposures matter and building reliable ways to get fixes into production. Open source will remain fundamental to that future. Collaboration across software providers, security teams, and upstream communities will become increasingly important. The organisations best prepared for AI-driven cyber threats won’t necessarily be those that find the most vulnerabilities. They’ll be those that can consistently fix the ones that matter.

--