AI didn’t break software security. The volume of vulnerability reports did

Recently, I joined a panel discussion at the Amsterdam Java User Group meetup hosted by Backbase.

The theme was deliberately provocative:

Did AI just break software security forever?

My view is slightly different.

AI didn’t break software security. The volume of vulnerability reports did.

At Axual, we see this problem from two sides.

As a software company, we depend on base images and open source components that bring in many smaller dependencies we did not explicitly choose.

As a vendor, we deliver our platform to enterprises that run it on their own infrastructure and upgrade on their own schedules.

That means vulnerability management runs on three different timelines:

1. A vulnerability is discovered.
2. A vendor assesses it and releases a fix.
3. The customer tests and installs that fix in production.

These timelines do not move at the same speed.

A vulnerability can be discovered in minutes. A vendor may be able to release a fix quickly. But for an enterprise customer, testing and deploying that fix can take much longer.

So even if you fix fast, your customers may still install slowly.

At the same time, the number of vulnerability reports keeps growing.

Across our own platform, we see new findings every day, even in software that has not changed.

That volume is now too large for people to review manually.

And this is where AI becomes useful: not because AI created the problem, but because we increasingly need machines to help us sort through the volume and identify what actually matters.
‍

“AI didn’t break software security. The volume of vulnerability reports did.”
‍

Why vulnerability management no longer scales manually

At Axual, we track 15 platform components across nine quarterly releases, covering 116 image tags.

Every weekday, we scan all of them. A complete scan takes around eight minutes.

On July 8, we had 63,679 findings.

By August 24, that number had increased to 70,308.

That is 6,629 additional findings in 47 days, even though the scope of what we were scanning had not changed.

On average, that is around 140 new findings every day.

And the increase is not gradual. On July 24 alone, we saw 2,341 additional findings.

We are a 15-component software product. We are not a bank or a hyperscaler.

Yet our scanner can find hundreds, and occasionally thousands, of new issues on software nobody is actively changing.

No person can realistically read and assess every one of those findings.

The question is no longer whether we should look at everything.

The question is how.

How AI is changing vulnerability detection and triage

This is where AI can help.

AI makes one part of vulnerability management much cheaper: looking at everything, all the time, without getting bored.

But finding a vulnerability is only the beginning.

The harder questions are:

• Can it actually be exploited in our environment?
• Is the affected code being used?
• Is there a fix available?
• Could the fix break something else?
• How urgently does it need to be deployed?

In one recent set of almost 5,000 findings, only three were Critical.

That is why simply producing more findings does not necessarily make you more secure.

You need to identify the few that deserve immediate attention.

“Identifying which findings deserve attention is increasingly a machine’s job. Deciding what to do about them is still ours.”

AI can help us reduce thousands of findings to a manageable set.

But the decision about what risk to accept, what to fix and what to deploy still belongs to people.

And sometimes there is another problem: there is no fix yet.

Why the newest vulnerabilities can be the hardest to fix

You might expect the newest software release to be the easiest one to secure.

Our data shows that this is not always true.

For one recent release, 78% of Critical and High findings had a fix available.

For a release from roughly one year earlier, that number was 92%.

The reason is simple.

The newest serious vulnerabilities are often so new that upstream maintainers have not published a fix yet.

This creates a difficult situation for vendors.

Customers understandably expect newly discovered vulnerabilities to be resolved quickly. Security SLAs often reinforce that expectation.

But you cannot deploy a patch that does not exist.

So vulnerability management cannot just be measured by how quickly somebody patches.

We also need to understand whether a vulnerability is actually exploitable, what temporary controls are available and whether an upstream fix exists.

Why a clean security report is only a snapshot

Continuous vulnerability research also changes the value of point-in-time security assessments.

A penetration test is useful.

A compliance sign-off is useful.

A clean vulnerability scan when a release ships is useful.

But they all describe one moment in time.

A piece of software can remain completely unchanged while its vulnerability count increases.

Nothing was added to the product.

Nobody changed the code.

Someone simply discovered a vulnerability in a dependency that had already been there.

That means a report saying a release was clean three months ago tells you very little about its exposure today.

“Security is becoming much closer to incident management than to passing an audit.”

Incident management already treats problems as continuous work.

There is an owner.

There is a queue of issues.

You know how large that queue is.

There are agreed response times.

There is an escalation process.

Most organisations already work this way when dealing with production incidents.

I think vulnerability management increasingly needs the same model.

Security is not something you finish once a year.

It is an ongoing operational process.

Most vulnerabilities are not in code we wrote

One of the most striking things in our data is where the findings come from.

Around 90% originate from the operating system, base image or deeper dependencies.

That means the vast majority were not introduced directly by an Axual engineer.

This is simply how modern software works.

Applications are built on top of operating systems, libraries, frameworks and other open source projects.

And AI-generated code is unlikely to reduce this dependence.

If a well-established library already solves a problem, it makes sense for an AI coding tool to use it instead of recreating that functionality from scratch.

But this makes dependency visibility even more important.

Your security exposure increasingly comes from code you did not write and may not even have selected directly.

There is another possible risk here too.

If everyone responds by moving towards the same few well-maintained open source projects, we reduce the risk of depending on abandoned software.

But we may also create a new concentration risk where large parts of the industry depend on the same handful of projects.

Sometimes the best fix is to have less software to defend

Our data has also changed how we think about remediation.

In one component, we reduced the number of findings from 386 to seven.

We did not fix 379 individual vulnerabilities.

We changed the base image.

That one decision reduced the number of findings by 98%.

In another case, we had an image used for platform initialisation that contained 5,972 findings on its own.

That represented 44% of all findings in the entire release.

Maintaining it as a separate component no longer made sense, so we merged its functionality into another component and removed much of that exposure.

“Some of the most effective security work we did was not fixing bugs. It was staying current and having less to defend.”

We see a similar pattern when looking at older releases.

One end-of-life 2024 release has 2.7 times as many findings as a current release and contains 94% of the known exploited CVEs in the dataset we analysed.

That does not mean upgrading is always simple.

But it shows why staying current is such an important security control.

Sometimes the most effective fix is not fixing hundreds of individual CVEs.

It is removing the outdated component that contains them.

What the Trivy compromise taught us about supply chain security

The harder lesson came from something we were not looking at.

In March this year, Trivy was compromised.

Trivy is a container security scanner. Its job is literally to find vulnerabilities.

Compromised GitHub Actions and binaries were distributed containing credential-stealing functionality.

The incident was public within a day.

We still missed its relevance to us for about a week.

Not because nobody was paying attention to security.

We missed it because Trivy was not part of the Axual platform.

It was a tool used in the build pipeline of the platform.

Our security monitoring was focused on what we shipped to customers.

We were watching the product.

We were not watching everything that builds the product.

When we realised that credentials from our build environments could have been exposed, our first response was to rotate those credentials.

To our Ops people, that seemed the best fix for the problem.

But days later, somebody asked a much more important question:

If a compromised tool had been running inside our build pipeline, could the software we shipped to customers have been affected?

That changed the incident completely.

It was no longer only a leaked-credentials problem.

It became a question about the integrity of our product.

Could our customers still trust what we had shipped?

Once somebody asked that question, it took us about three hours to answer it.

Our platform images were clean.

But the timeline is what stayed with me.

“Time to answer: three hours. Time to ask the right question: two weeks.”

The problem was not that we lacked the tools to investigate.

The problem was that nothing in our process had pointed us towards the right question.

Security tools are also part of the software supply chain

There was another uncomfortable detail.

Every vulnerability number I have mentioned in this article comes from Harbor.

Harbor uses Trivy for vulnerability scanning.

So Trivy existed in another part of our environment too.

We had never thought about those two uses together as one dependency that we needed to monitor.

We do now.

“The tool that reads your supply chain is part of your supply chain.”

Security tooling does not sit outside the supply chain just because its job is to protect it.

And a compromised security tool can be particularly difficult to detect.

The compromised Trivy binary could first perform its malicious activity and then run the legitimate vulnerability scan.

The scan still completed.

The build still succeeded.

The dashboard stayed green.

From the outside, everything looked normal.

That is why build tools, CI/CD systems and security tools need the same dependency visibility we already expect for production software.

Automated attacks are getting faster. The response is not.

A lot of the conversation about AI and cybersecurity focuses on autonomous attacks.

How quickly can AI find a vulnerability?

How quickly can it exploit one?

How many systems can it target?

Those are important questions.

But I think there is another gap that deserves just as much attention.

The attack is becoming automated.

The response often is not.

“Fully automated attack meets Change Advisory Board.”

An automated attack can happen in seconds.

Responding to a vulnerability may require analysis, engineering work, testing, approval and a new software release.

And then the customer still has to test and deploy that release.

That takes us back to the three timelines.

Discovery can happen almost instantly.

A vendor fix takes longer.

Deployment into an enterprise production environment can take longer again.

So even if vulnerability discovery becomes completely automated, the security problem is not solved.

We also have to improve the speed of the response.

Two vulnerability management metrics I would watch for

Everyone is watching whether AI gets better at finding vulnerabilities.

I think that question is largely settled.

It will.

I would pay more attention to two other measurements.

1. How many critical vulnerabilities can actually be fixed?

More than one fifth of our most serious findings currently have no fix available.

Nobody upstream has published one yet.

Until that happens, there is nothing to deploy.

2. How quickly does an available fix reach production?

Once a fix exists, it still has to move through several steps.

An upstream maintainer creates it.

A software vendor assesses and tests it.

The vendor releases it.

The customer assesses the new release.

And finally, the customer deploys it into production.

The speed of that process will increasingly depend on trust and auditability.

If we want to automate more of the response, organisations need to know exactly what changed, who made the change and whether that change can be trusted.

AI did not break software security

AI is changing software security.

But the bigger problem is not simply that AI can find or create vulnerabilities faster.

The bigger problem is scale.

We can already discover more security findings, across more software, more frequently than humans can process manually.

AI can help us handle that volume.

It can analyse findings, identify patterns and help us decide which issues deserve attention first.

But it does not remove human responsibility.

We still need to decide what constitutes an acceptable risk.

We still need to decide what gets fixed.

We still need to decide what gets released.

And customers still need to decide when they trust a change enough to put it into production.

“The real security bottleneck is increasingly not finding the vulnerability. It is deciding what matters, knowing what can be fixed, and getting a trustworthy change into production.”

AI did not break software security.

The volume of vulnerability reports exposed how poorly our existing processes scale.

And fixing that may be the more important challenge.j

Want to discuss how your organisation can manage vulnerability risk at scale? You can book a call or shoot me an email.

‍