The Privatization of Vulnerability Management

Several market pressures are making more of the vulnerability management processes shift to private companies

The capabilities of frontier models to conduct code analysis for vulnerabilities (AI SAST) has the security industry searching for new solutions whether or not they’re actually needed. The reality of AI vulnerability discovery capabilities are simultaneously more and less severe than advertised: the scanners from the frontier model providers are overhyped, while AI SAST as a whole is underhyped. Daniel Stenberg (the primary maintainer of curl) has had an experience with these tools that mirrors my own: they’re extremely effective at uncovering vulnerabilities in open source software.

LinkedIn Post from Daniel Stenberg

Here are the core changes happening in vulnerability management due to AI:

1. Vulnerability scanning and penetration testing capabilities are already magnifying the capabilities of attackers - from script kiddies to professionals.

2. Improved capabilities are affecting all types of software - open source is the most vulnerable as the code is available for analysis; but runtime analysis makes everyone more vulnerable.

3. Several vulnerability detection and response resources are being limited to enterprise tools:

   1. Detection. Access to the latest models is currently being gatekept to large enterprises for cybersecurity research. This limits the most advanced analysis and response to the largest companies.

   2. Investigation. The NVD is at its lowest point in enriching vulnerability data, with vendors like Flashpoint and Vulncheck picking up the pieces, and GitHub Security Advisories quietly becoming the primary data point.

   3. Response. Another privatization trend is at work, the growth of “supply chain firewalls,” or vendor hosted private artifact registries. Vendors will host their own forks of open source repositories, promising varying degrees of increased security or patching speed from their versions.

These trends point to a new reality: many aspects of vulnerability management are going private, for better and for worse.

An overview of what some of the vendor initiatives are proposing

In response to these emerging challenges, several larger initiatives have been announced, mostly involving companies with access to Mythos, and each with their own grandiose ambitions. Confusingly, several of these initiatives include the same companies. This article is intended to help weigh the pros and cons of these initiatives, and suggest ways to make them genuinely helpful.

To start, here’s how the current vulnerability disclosure process works:

1. A researcher discovers a vulnerability and reports it to a CNA, who is usually a large software provider.

2. The CNA publishes the vulnerability to MITRE’s CVE.org. At this point the disclosure is public and can be patched by the maintainers if they have not already been made aware directly by the researcher.

3. The NVD, or a third party provider, scores and enriches the vulnerability information.

Vendor initiatives are instead suggesting this general process:

1. A large enterprise with frontier model access discovers a vulnerability in their software, or in an open source dependency.

2. They report this finding to their security provider, who patches it or mitigates it for them.

3. That security provider may or may not disclose the vulnerability after patching or mitigation.

The same core processes are being followed, but it’s no longer via a public forum - private security companies are moving to own even the disclosure process with their customers, who currently have exclusive access to the latest model capabilities. More importantly, these company’s customers have exclusive access to both the findings and mitigations for an undisclosed amount of time.

They introduce two assumptions that warrant more context. The first is security through obscurity - that delaying public disclosure will meaningfully limit attackers’ ability to exploit a vulnerability. The current initiatives do not define recommended disclosure windows, but instead leave disclosure timing as an optional practice. The second assumption is that introducing a new incident response coordination team will reduce the burden on maintainers.

Last year, the industry panicked as MITRE looked like it was losing funding, and the CVE database would be going offline. If these privatization pressures continue, the CVE ecosystem is going out with a whisper; private companies are scanning for vulnerabilities, hosting patches, and making their own decisions on whether or not to disclose them at all.

The Ecosystem Problem

The best case scenario to these initiatives is that open source maintainers get the help that’s desperately needed. The worst case scenario with these initiatives is that fixes get privatized, while attacker capabilities get democratized. There’s an assumption that the vulnerability discovery capabilities of frontier model companies are the only tools capable of impactful discoveries. Attempting to gatekeep these findings to the largest companies is misguided from the start: the tools are commonly available with or without mythos.

Having a shared standard for open source development is essential to make most software work. Creating a scenario where security vendors host branching versions of fixes for similar issues creates reliability issues with upstream consistency - potentially weakening your security as a private patch may introduce a new problem. It’s against what makes open source work in the first place.

Vendors taking steps to make their customers safer will always be a good thing; however, the private patch protects teams today at the cost of a permanent loss, since they can no longer reason about software security against a shared standard. If these practices become more widespread, the CVE ecosystem doesn’t get defunded; it just quietly stops mattering as the real work moves behind vendor walls.

How these initiatives can help

It’s hard to make a profitable company built around fixing open source. I’m hopeful that these companies genuinely want to do what’s best for the industry, and seem to be willing to back their commitments financially. Here are 5 ways these initiatives can be actually helpful:

1. Private companies should support the maintainers of their open source dependencies. At a minimum, this means opening a PR for a patch instead of a Github issue for a CVE. It means as much as sponsoring their dependency maintainers.

2. Mythos vulnerability findings should follow normal vulnerability disclosure processes, with a clear and public timeline for when they will be disclosed. Gatekeeping findings and attempting to de-duplicate them upstream in private will only create more divergence. Not committing to a timeline means being able to monetize fixes.

3. Being a maintainer of last resort must mean getting patches merged upstream, not hosting private patched versions of packages. Vendors can still add value by maintaining patched historical versions for companies, providing end-of-life support.

4. The value of these initiatives is in their ability to create a community of maintainers and actually help manage vulnerability submissions and GitHub issues. This is a long-term goal that requires more than vendor signoffs - it will be measured in maintainer-hours.

5. These initiatives must publish through CVE.org like everyone else, or through GitHub Security Advisories, rather than creating yet another identifier system. This keeps the shared standard intact.

At its core, if these announcements are vendors committing to patch their open source dependencies, this is great news. If companies want to help reduce maintainer vulnerability overload and the time to mitigate, opening patches to open source repos directly when they discover a vulnerability with an AI scanner is the best path forward. Security is about making doing the right thing as easy and accessible as possible.