Finding and Fixing Vulnerabilities Using AI

5.9 Release and deploy

Software that is only fixed on a developer’s workstation helps no one else. Fixed software must be released and deployed. This was always true, but now that AI is accelerating the vulnerability-finding process, it’s even more important.

Anthropic notes that “software developers should… make security fixes available as quickly as possible… Developers should also help their users stay up-to-date with their software by making it as easy as possible to install updates; to the extent feasible, they should be more persistent with users who are still running software with known vulnerabilities” [Anthropic2026-05]. Work to streamline your release process. Ensure that updates are automatically checked for a valid digital signature and that the update process is not itself a vulnerability.

A released fix is also a map to the vulnerability. Attackers can “patch diff”, that is, compare the fixed source or binary code with the previous version, find what changed, and work out the vulnerability the change fixes. While this was always true, AI has made this fast and cheap. In a June 2026 study, Claude Mythos Preview built 8 working code-execution exploits from 18 recent Firefox security patches, writing “its first working exploit in just under one hour”. From 21 Windows kernel vulnerabilities it produced 8 full privilege-escalation exploit chains. The authors warned that “A lone operator can now turn a month’s worth of patches into working exploits in a single afternoon—for a few thousand dollars and with no specialized expertise”. The authors concluded that “the typical patching playbook that software developers use today—with monthly release cadences, multi-week staged rollouts, and a lag between pre-release and stable channels—no longer holds”. [Xiao2026].

In practice, this means you should:

1. Minimize the time between a fix becoming public and its release. A security fix that sits in a public repository for weeks before release gives attackers a head start. Where practical, develop security fixes privately (e.g., in a private fork or a private security advisory). Publish the fix, the release, and the advisory together.
2. Release fixes for all supported versions at the same time. If you fix the main branch today and a long-term-support branch next month, the first fix shows attackers how to attack the second.
3. Shorten your release cycle for security fixes. For example, Mozilla “recently moved its ‘dot’ releases (the small point updates between major versions) from a monthly to a roughly weekly cadence” [Xiao2026].
4. Make updating easy and fast for your users, as discussed above.

Faster patching alone does not solve this problem. As the Xiao study notes, “A more durable fix would attack the supply of bugs, rather than the speed of patching them. This can start with migrating critical components to memory-safe languages like Rust, or hardening them with mitigations that retire whole exploit classes at once” [Xiao2026]. See our section “Harden” about this.

When you release a fix, tell your users, so they know to update. Publish a security advisory that says what the vulnerability is, which versions are affected, which version fixes it, and what users should do. Where appropriate, get a CVE identifier for it, so tools that check for known vulnerabilities can alert your users.

Writing the advisories can become a bottleneck when many fixes arrive quickly. Consider using AI to draft release notes, advisories, and CVE descriptions from the fixes, with human review and repair before publication. The Chrome team is “working on automating the generation of release notes and CVE descriptions from security bug fixes to eliminate manual bottlenecks and shorten the window between vulnerability discovery and public disclosure” [Chrome2026].

People, projects, and organizations should ensure that they can rapidly accept updates, too. Establish processes to automatically test updates, and then propose or implement them. Organizations that try to do this solely with manual processes will often be unable to keep up. Humans still need to be in control, but the humans need to be supported by automated processes that help them become aware of problems and provide analyses so they can make good decisions.