Cloudflare Links Vulnerability Discovery to Defense With OpenAI's Daybreak and Codex

TL;DR

Cloudflare is combining OpenAI models accessed through Daybreak with its global network and threat context to power Vulnerability Discovery and Remediation, an early-access service offered through Cloudflare Managed Defense. The service investigates customer-authorized code, proposes patches and web application firewall rules, and leaves the final decision to the customer — while Codex is used by 100% of Cloudflare's software developers, according to the OpenAI post.

What was announced

OpenAI published a customer story describing how Cloudflare uses OpenAI models in two distinct areas: security analysis and software engineering.

• Security: Cloudflare's Vulnerability Discovery and Remediation service uses OpenAI models accessed through Daybreak to investigate code and assess potential vulnerabilities. Cloudflare then adds live traffic data, security signals, and validation to prioritize findings and prepare proposed mitigations and patches for customers to review.
• Engineering: Codex extends OpenAI's role across Cloudflare's engineering organization, where developers use it to increase output and improve code quality.

The service is described as an early-access offering delivered through Cloudflare Managed Defense. Cloudflare operates one of the world's largest networks and proxies roughly 20% of the web's traffic, which is the context the company brings to the security workflow.

How the vulnerability workflow connects discovery to defense

Cloudflare's stated goal is to connect a vulnerability in source code to what is actually happening in production. The service answers questions such as whether the affected route is active, whether it is receiving suspicious traffic, and whether existing security controls already protect it.

According to the post, the pipeline works as follows:

1. OpenAI models accessed through Daybreak investigate customer-authorized code, identify potential vulnerabilities, and check the evidence supporting each finding.
2. Cloudflare adds live traffic data and security signals to prioritize findings.
3. The service prepares proposed code patches and, where appropriate, custom web application firewall rules to reduce exposure while developers review a fix.
4. Cloudflare runs automated checks on these proposals, and its own team reviews them before sharing them with customers.
5. Customers retain control over which changes to implement.

The stated customer benefit is a clear path from identifying a vulnerability to protecting the affected application: evidence to prioritize vulnerabilities, proposed edge protections to reduce exposure, and code fixes to review.

Mark Anderson, President of Revenue at Cloudflare, frames the problem in terms of analyst capacity rather than data scarcity:

"Traditional security teams have a ton of useful data. They just don't have the people and time to deal with it."

Codex usage across Cloudflare's engineering organization

OpenAI's post states that Codex is used broadly inside Cloudflare's engineering organization. Anderson ties that usage to greater developer productivity, better code quality, and fewer bugs introduced during development.

"At Cloudflare, a third of our company are software developers building services and features for our platform, and 100% of them use Codex to boost their output and deliver better code." —Mark Anderson, President of Revenue, Cloudflare

The post cites one concrete example of that productivity shift. Anderson describes a rebuild the team had postponed, saying, "We were putting off building it because we didn't have the manpower to do it." With Codex scaling developer productivity, he says the question shifts from "Can we take this on?" to "Why not?"

Anderson estimates the work would have required months of sequencing and "maybe 10x more developers." Instead, a Cloudflare team of four developers took on the build:

"We built it in three days, rolled it out and tested it, and spent $1,100 on tokens." —Mark Anderson, President of Revenue, Cloudflare

The human-judgment framing

Both parts of the story are presented as an argument about where automation belongs in engineering and security work. Anderson describes the division of labor this way:

"The beauty of the automation that Daybreak and Codex provide is that you can assign machines to do the grunt work so humans can exercise their judgment on the most important engineering and security decisions."

He extends that idea to process design, saying that making AI part of everyday engineering means "rebuilding the internal process to build technology with machines in mind, not as a separate element, but as something that's integrated into the build process."

What the post does and does not specify

Specified in the source: the service name (Vulnerability Discovery and Remediation), its delivery channel (early access through Cloudflare Managed Defense), the role of Daybreak as the access path for OpenAI models, the role of Codex in Cloudflare's engineering organization, the 100% developer adoption figure, the three-day rebuild by four developers, and the $1,100 token spend.

Not specified in the source: the specific OpenAI model names or versions behind Daybreak, pricing or general availability dates for the service, the number of customers in the early-access program, and any measured detection or remediation benchmarks. The post does not state how many vulnerabilities the service has found or fixed.

Why this matters

The post describes a pattern in which the same model access layer serves two sides of a security problem: finding vulnerabilities in code and defending the running application. Cloudflare's contribution is the production context — live traffic, security signals, and validation — layered on top of model-driven code investigation, with automated checks and human review before anything reaches a customer.

The second pattern is organizational rather than technical. Cloudflare's account of a four-developer, three-day rebuild that it had previously postponed for lack of manpower is presented as evidence that reduced engineering cost changes which projects get attempted at all, not just how quickly existing work gets done.