The new OSS threat map: how Frontier LLMs are changing the rules of the game

Advanced language models have created a new threat map, and now the question is no longer how many vulnerabilities will be found (probably many), but what is your organization's MTTR.

Author: Kobi Shamama, Account Director at VMware Tanzu

More than half of the Fortune 500 companies, and quite a few enterprise organizations in Israel, base their production and application core on open-source projects like Spring, RabbitMQ, and Bitnami. As those who contribute to, develop, and maintain these projects at VMware Tanzu, we see up close how the focus of open-source security has changed completely in recent months. The reason is simple: large language models have entered the field, and they read code better than all of us.

Advanced language models (or Frontier LLMs) have proven to be excellent code readers. AI scans today detect vulnerable patterns that humans have missed for decades: in FreeBSD, an operating system considered one of the most secure in the world, a CVE that had been hidden in the code for 20 years was discovered this way. Mozilla released 150 fixes for more than 270 vulnerabilities detected in an AI scan. And the Spring world is feeling it too: in March 2026, the community sent 55 security reports, eight times the historical average, and in April, 482 reports arrived, leading to 26 new CVEs.

The only metric that really interests the CISO

There is good news here too: most of these vulnerabilities were always in the code, and now they are finally being found and fixed. On the other hand, the same tools that help us find vulnerabilities in code are also available to attackers. A model that finds a vulnerability also knows how to write an exploit for it and map a path that will lead to it through the chain of dependencies. An average Spring Boot project, for example, pulls with it hundreds of dependencies — each of them is a potential entry door.

In 2020, on average, more than 700 days passed from the publication of a vulnerability to its actual exploitation. In 2025, this number was reduced to 44 days, and today, in 2026, almost 30% of vulnerabilities are exploited within just 24 hours. The meaning is simple: the question is no longer how many vulnerabilities will be found, but what is your organization's Mean Time To Remediate (MTTR). How fast the fix reaches you, and how fast you are able to implement it in production without breaking the system. At this exact point, the clear line is drawn between using community open source and open source backed by the responsibility and SLAs of an enterprise vendor.

3 Remediation strategies that really work

So how do you beat the attackers in the AI arms race? It depends on the open-source project you are working with. Here are our 3 strategies that we already know work and keep your code safe:

Spring — fix at the source. In response to the wave of reports, the Spring team released the largest round of security updates in the project's 23 years, and it runs scans based on frontier models itself to find and verify vulnerabilities before the attackers do. Tanzu Spring customers get Day Zero access to CVE-only — including security fixes only, without surprises, even before public disclosure. So that a CVE doesn't get stuck in your pipeline, Spring Application Advisor scans your applications, maps where they stand against the latest versions, and generates automatic Pull Requests directly in the CI. Thus, an upgrade that would have taken weeks becomes an ongoing process.
Bitnami — know what enters production. Bitnami is a project that is fully developed and maintained by us. The principle has remained the same for years: every component is built from the source, in a closed environment. Our customers can consume Helm charts, Images, and OVA with minimum vulnerabilities.
RabbitMQ — whoever wrote the code releases the fix. The Message Broker is a favorite target for attackers. The RabbitMQ code is written by us, and our customers continue to receive CVEs Patches even for versions that are no longer supported in OSS (for example, 3.13 is covered until the end of 2029). This is alongside continuous code scanning at every commit, and a global security team available 24/7.

And what is happening with you?

The numbers tell the whole story: more reports, more CVEs, and an exploitation window that has shortened from two years to a few days. Here are three questions you should check this week:

Do you have an accurate picture of the dependencies running in production (an updated SBOM, not a requirements file from a year ago)?
How much time passes for you from the publication of a CVE until the fix is running in production?
Is there a party behind every open-source component you run that releases fixes, including for the specific version you are on?

Advanced language models have turned vulnerability detection and exploitation into an automatic and fast process, and organizations can no longer afford to rely on manual remediation processes. The only way to reduce MTTR and remain stable in the face of new threats is to fight automation with automation. The VMware Tanzu team in Israel accompanies leading organizations in protecting their production and application core, providing a full technological envelope, rigid SLAs, and Day Zero access to critical security fixes for Spring, Bitnami, and RabbitMQ.

Want to protect your OSS environment in the AI era? Contact us: [email protected]

Activity in cooperation with C Data, the official distributor of VMware by Broadcom in Israel.