· 9 min
Scaling cyber defenders with Daybreak
Loading article…
Pull for previous story
If you work through a security backlog, finding another possible issue is only the start. You still need to work out whether it affects your software, gather evidence, and land a safe fix. That gets harder as the code, alerts, and vulnerability reports keep coming in.
We’ve recently added more ways to work through that process with ChatGPT, Codex Security, and the open-source Codex Security CLI. You can review a pull request before it merges, investigate a repository or an existing vulnerability backlog, and add recurring checks to CI. These capabilities are part of OpenAI Daybreak, which brings together models, security tools, responsible access, and the security ecosystem for approved defenders.
In previously reported results, Codex Security cloud had analyzed more than 30 million commits across more than 30,000 codebases. Here, I want to walk through where the available workflows fit and how I’d choose a starting point. The aim is the same throughout: turn findings into evidence and reviewed fixes, while keeping access scoped and people responsible for consequential decisions.
These workflows are suggested starting points, not a one-size-fits-all deployment pattern. Developers should tailor them to their organization, use case, risk profile, and data-handling practices, and determine the appropriate configuration, safeguards, and deployment for their environment.
If you already have a log excerpt, an advisory, or an incident timeline, ChatGPT is a useful place to start reasoning through it. A few things to try:
You’ll still need to check the underlying evidence, follow your organization’s data-handling policies, and decide what actions to take. When the next question requires examining a repository, a pull request, a security backlog, or a proposed patch, that’s a good point to move to a Codex Security workflow.
Codex Security Review brings focused security analysis into GitHub pull requests, so it’s a natural starting point when you’re already reviewing a change there. Once your workspace has research preview access and a connected repository, you can request a review by commenting:
@codex security reviewIf that fits your team’s workflow, configure automatic reviews when a pull request opens, after every push, or whenever an existing Codex code review runs. A repository threat model or other security guidance is useful context here: it helps the review account for your application’s assets, trust boundaries, and assumptions.
Codex considers the pull-request diff alongside relevant repository context. The findings on the pull request are a starting point; the associated Codex task’s Security Report has severity, supporting evidence, attack paths, validation details, and remediation guidance. One detail to pay attention to is the reporting threshold: findings posted to GitHub inherit the pull request’s visibility.
Codex Security Review is available in research preview to eligible ChatGPT Enterprise, Business, Edu, and Pro workspaces with a connected GitHub repository.
When the question is broader than one pull request, the Codex Security plugin can assess an entire repository, a component, a branch, a commit, or local changes. For a first assessment or routine review, I’d start with a standard scan. A deep scan makes more sense for a critical system or scoped directory where broader, repeated analysis justifies more time and compute.
The Security workbench brings scans, findings, and repositories together in the Codex desktop experience. Before accepting a finding, look at its source evidence, severity, confidence, attack paths, and coverage. You can also compare findings across runs and move an accepted finding toward a proposed patch.
Recent workbench updates help with the less exciting part of a long investigation: keeping track of what’s happening. You can see live scan phases, reviewed files, active workers, elapsed time, and measured token usage. Interrupted deep scans can resume without repeating completed work, and reusable summaries reduce unnecessary overhead.
If a repository needs ongoing attention, you can set up Codex Security cloud for continuous analysis of a connected GitHub repository. You choose the repository, branch, environment, and history window. Codex then builds a repository-specific threat model, reviews relevant commits, and presents ranked findings for investigation.
Where practical, likely issues are validated in an isolated environment. The supporting code excerpts, call paths, reproduction output, and remediation guidance give you something concrete to review. It’s worth keeping the threat model up to date as your architecture and priorities change. Inspect a suggested patch before opening a pull request, too.
Codex Security cloud is available in research preview. An initial scan may take several hours for a larger repository; subsequent analysis focuses on newly relevant commits and changes.
You may already have plenty of findings to investigate. If your team has static-analysis results, dependency alerts, bug-bounty reports, advisories, or tickets, you can triage that backlog against the current repository without starting another scan.
Codex Security can work with SARIF reports, GitHub code-scanning and Dependabot findings, security advisories, Jira or Linear tickets, and other vulnerability reports. It examines each claim, traces relevant inputs and code paths, checks existing controls, and explains whether the evidence supports action, suggests the issue is not applicable, or requires further review.
That evidence helps you focus on issues that affect the software you actually run. I’d keep the established scanners in the picture: Codex Security complements deterministic scanning with repository-specific investigation and additional validation where appropriate.
Once a finding looks credible, the next question is whether you can fix it safely. For an accepted finding, ask Codex Security to prepare a fix. Where safe and practical, it can reproduce the issue, generate a focused patch, and provide evidence that the change addresses the original problem.
When feasible, the workflow adds a regression test that fails before the fix and passes afterward. That’s useful evidence to have alongside the patch. If a reliable test can’t be created safely, the workflow records the remaining proof gap instead of overstating what was verified.
The decision to apply the change still belongs to an engineer. Inspect the finding and proposed diff, decide whether to apply it, and verify the result. You can also export findings and reports or route them into existing issue-management workflows with explicit approval.
If you’d rather work from a terminal, a CI pipeline, or an internal tool, the open-source Codex Security CLI and TypeScript SDK support those workflows. The @openai/codex-security package is public, but running scans requires Codex Security access.
For a first run, follow the CLI prerequisites and sign-in steps, then start a scan from a repository you own or have permission to assess:
npx @openai/codex-security login
npx @openai/codex-security scan .Before scanning, review the local scan permissions. Local scans use your operating-system permissions and don’t pause for approval. Remove unrelated credentials from the environment, and keep results in a private location: reports can contain source excerpts and vulnerability details.
Once the local workflow is useful, you can make it repeatable with GitHub Actions or GitLab CI/CD checks. You can review pull requests or merge requests, export SARIF, retain security evidence, and optionally fail a check when findings meet a selected severity threshold. If you’re building your own application, the TypeScript SDK exposes scanning, progress reporting, cancellation, and cost controls.
When the same review needs to cover a repository portfolio, the CLI’s bulk-scanning workflow is a useful next step. You can discover repositories from an authorized GitHub account or organization, or prepare a CSV inventory with repository URLs or local paths, pinned revisions, optional scopes, and a standard or deep scan mode for each target.
After preparing the inventory, run a campaign with a private output directory outside the repositories:
npx @openai/codex-security bulk-scan repositories.csv \
--output-dir /path/outside/repositories/security-portfolio \
--workers 4 --max-attempts 3Campaigns preserve progress and results separately for each repository. You can resume interrupted work, tune concurrency and retries, provide shared architecture documents or security policies, and retain findings, coverage, and portable SARIF results. Supported models, reasoning effort, scan depth, and estimated cost limits let you choose how much analysis each target warrants. Treat estimated cost limits as estimates, not hard spending caps.
For a large monorepo, I’d scope the first scan to an owned service, package, or another meaningful security boundary. Start with a standard scan, then apply deep scans selectively to sensitive services or complex components. For connected GitHub repositories, Codex Security cloud can review a selected commit-history window and continue reviewing new commits.
The initial campaign gives you a baseline to work from. Updating threat models, tracking findings in your existing systems, and verifying reviewed fixes is how you turn that first pass into a repeatable security program.
There’s no need to start by replacing the systems your team already uses. Codex Security is designed to work alongside existing scanners, vulnerability-management systems, issue trackers, service providers, and open-source projects. You can bring in existing findings, export portable results, and route reviewed issues back into those workflows.
Through OpenAI Daybreak, we also work with security organizations, researchers, open-source maintainers, and partners to make model-assisted defense available in more tools and services. Access to advanced cyber capabilities is limited to approved users conducting authorized work, with safeguards matched to the activity.
Most defensive work can begin with general-purpose models and Codex Security. For approved defenders, Daybreak Blue supports authorized work such as vulnerability triage, malware analysis, detection engineering, security investigations, and patch validation. Daybreak Red is intended for a narrower set of specialized, authorized activities, including advanced vulnerability research, controlled exploit validation, and red teaming. It requires separate approval and safeguards.
Use the current model and Trusted Access guidance to choose the right offering and confirm that your identity, workspace or API organization, model, and product surface are approved. Access approval doesn’t configure your environment for you. Define the systems and actions in scope, use least-privilege permissions and isolated execution where appropriate, and keep human review in place for consequential decisions.
If you’re deciding what to try first, I’d start wherever your team already has work to do:
You don’t have to adopt every workflow at once. Whichever one you try, the useful loop is the same: establish whether the risk is real, inspect the evidence, review the proposed change, and verify the fix.