How To Handle Bug Bounty Reports With ZERO

Bug bounty triage requires reading each report, reproducing or ruling out the described vulnerability, checking the program's history for duplicates, assigning severity, and writing a response to the researcher. A single report can take thirty minutes to two hours of senior engineering time. Volume into bounty inboxes has been rising for years, and the people qualified to do the work are not easy to add.

The last eighteen months have changed the inbound mix. AI-assisted development is producing more code per engineer per quarter, which expands the surface that programs are responsible for. The same models are now used by researchers to draft the reports they submit, and a meaningful share of those submissions describe vulnerabilities that are not present in the code. Curl, the Python Software Foundation, and other open source projects have written publicly about the change. The reports often look correct on first read. They cite real function names, real CVEs, and real CWE numbers, but the chain they describe does not exist.

Exploitation timelines have shifted at the same time. The Zero Day Clock reports the median time from CVE disclosure to first observed exploitation:

• 2018: 771 days
• 2023: 6 days
• 2024: 4 hours

By 2025, the majority of exploited vulnerabilities had been weaponized before public disclosure. For the categories of issue that do not reach a CVE number, bug bounty programs are often the primary external channel for receiving them, and the time available to triage and remediate has compressed accordingly.

Increasing triage headcount addresses part of the problem. The submissions where senior judgment matters most are a minority of the inbound, often involving chained issues across components or architectural insights that require time and the right reviewer. Routing those reports through a queue that has been growing with low-signal submissions delays the response on the ones that matter and occupies the engineers best suited to handle them.

Failure modes

Three outcomes occur when triage decisions are wrong:

• A real bug closed as duplicate stays in production until it is rediscovered, often by an attacker.
• A real bug closed as out of scope produces a frustrated researcher and reputational damage to the program.
• A low-signal report investigated as if it were valid consumes engineering hours on a vulnerability that does not exist.

Programs facing the highest inbound volume sometimes respond by auto-rejecting categories of submissions. This reduces load and closes real reports along with the noise.

What ZERO does

ZERO is the assistant in ZeroPath. It operates with the access a senior security engineer at the organization would have: the source repositories, scan history, existing findings, and the communication and ticketing channels the program runs on. It also carries the codebase context ZeroPath has already built: which repositories are externally reachable, which are internal, how they depend on each other, and where data flows across those boundaries.

When a webhook fires from the bug bounty platform, ZERO reads the report, searches memory for prior decisions on the same code path and from the same researcher, checks the findings store for duplicates, and traces the described vulnerability against the dataflow ZeroPath has computed. If the report holds up, ZERO drafts a Linear or Jira ticket with the relevant context attached. If it does not, it drafts a response to the researcher. The result is posted to Slack for a human to approve or override before anything leaves the program.

Every override is written back to memory. Subsequent reports that resemble the corrected case inherit the updated decision.

With ZERO on inbound, valid reports reach the triager in minutes with the relevant context attached, and clearly invalid reports close with a drafted response. The senior triager reviews a smaller queue with higher signal.

Untrusted by design

External input triggers run in an untrusted execution profile: no shell access, a restricted filesystem, and a prompt that marks the input as hostile to the assistant. A malicious submission cannot reach the systems it might attempt to attack from inside the trigger.

The context layer

Bug bounty triage is one of several discrete loops a security program runs. SAST output, DAST output, internal pentests, third-party reports, customer reports, bug bounty. Each has its own routing and reviewers. The context that crosses them is typically held by individuals rather than in a shared system, which is part of why senior engineers are the bottleneck on every loop.

ZeroPath builds that shared context as a system: dataflows across repositories, taint graphs across services, the history of every finding the program has decided on, and integrations with the systems the program already runs on. When a frontier model is given a triage decision, the answer is bounded by the context available at decision time. A model reading a SQL injection report without knowing which routes are reachable from production, which inputs are sanitized at an upstream middleware, or that the same path was reviewed and closed six weeks ago is making the call from a partial picture.

Frontier models will keep improving. The model on top of the context layer can be replaced when better ones arrive. The repository graph, the dataflow index, the memory of prior decisions, and the integrations with the rest of the program are what stays in place underneath. ZERO is one assistant on that layer. The same context feeds the rest of the program's workflows.

See ZERO in your codebase: zeropath.com/demo.