When AI finds the bug, the handoff becomes the risk

A maintainer of a widely used open source library wakes up to eight private security reports. Same dependency in every one. No two agree.

A bank's security team filed first, critical, thirty-day clock. A cloud provider marked it high and wants a call this week. A vendor scanner dumped automated output rated "important," with no human on the thread. Two independent researchers ran AI-assisted analysis and attached pages of model reasoning, labeling the same code path two different ways. The last three are the first five again, forwarded by people who found the first five.

The bug might be real. That is not the maintainer's first problem. The first problem is that eight people are now waiting on one unpaid person, and every one of them is certain their clock is the clock that counts. The bug is a technical question with an answer. The eight inboxes are a coordination failure, and the coordination failure is what pushes a disclosure into the open before the fix is ready.

That morning is what Akrites was built to end.

What Akrites is, from the source

On June 25, 2026, the Linux Foundation and a long list of companies launched Akrites, a coordinated effort to remediate and disclose vulnerabilities in the open source software that critical infrastructure runs on. The founding organizations are not a fringe list: AWS, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft and GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, the Rust Foundation, Sonatype, Vodafone, and Zscaler. They committed engineering talent, security expertise, and funding. The stated scope is blunt about who depends on this code: banks, hospitals, power grids, telecoms, governments, and AI labs.

The premise is stated plainly on the Akrites site. Finding a serious vulnerability in a major open source project used to take an expert weeks. Now a machine can do it in minutes, and return several findings in a single pass. That shift does not just speed up attackers. It floods the front door. Duplicate reports pile up, maintainers get overloaded, and disclosure turns into a race where the slowest, most careful actor loses.

So Akrites builds a single place to absorb that. A shared Security Incident Response Team, a SIRT, acts as one front door for upstream maintainers. Reports flow through one path: intake, then deduplicate and validate, then remediate, then synchronized disclosure. Intelligence is shared under the Traffic Light Protocol, and every finding starts at TLP:RED, visible only to the case team handling it. DevOps.com framed it as replacing the ad hoc model with a predictable entry point and a standard coordinated disclosure process built on the established alphabet: CVE, CWE, CVSS, EPSS, SSVC, VEX. In that same piece, Linux Foundation CEO Jim Zemlin is quoted putting the stakes in a single line: the mean time to exploit a vulnerability is now negative seven days. Treat that as his framing rather than a measured constant, but the direction is the point. Exploitation is arriving before the fix.

The scale underneath all this is why nobody is treating it as optional. FOSS Force noted, citing a Linux Foundation and OpenSSF report, that 96 percent of codebases include open source. Vodafone, one of the founders, put the logic simply: AI can fast-track vulnerability discovery, and Akrites is meant to be a unified, industry-wide way to responsibly identify and fix what gets found.

That is the consortium's answer to the eight-inbox morning, and it is a good one. It is also built for organizations that can staff and fund a SIRT, which is the part that does not reach you.

The part that lands on everyone else

Akrites is built by and for organizations large enough to staff a SIRT and fund one. If you run a small product team, an agency, a managed service shop, or a lean SaaS, you are not joining the case team. You cannot operate it, and BaristaLabs cannot operate it for you. But you are still in the system, because you depend on the same open source, and your AI tools have gotten just as fast at finding things in it.

Here is the uncomfortable version. The same vulnerability scanners and AI-assisted code tools that make your small team punch above its weight will, sooner than you think, surface something real in a dependency. Maybe a coding agent flags it mid-task. Maybe a scanner in CI lights up. Maybe a developer asks a model to "check this library for issues" and it returns three. The instinct in that moment is to be a good citizen: report it upstream, fast, with everything the model wrote.

That instinct, executed badly, is exactly how your company becomes the ninth inbox.

If your AI scanning is faster than your disclosure process, the speed becomes a liability the moment it leaves your building. You forward raw model output before anyone reproduced it. You file against a project that already has an advisory open. You attach a severity the model guessed at, with a clock you invented. Multiply that by every team running the same tools against the same popular package, and you have rebuilt the eight-inbox morning by hand. The maintainer's incident now includes you.

So the lesson for everyone outside the consortium is not "scan less." It is "fix the handoff." Do not build a louder scanner. Build a quieter handoff.

The artifact: a shared vulnerability desk

Akrites is a coordination room for the giants. A shared vulnerability desk is the small, written version you can actually run: a single internal checkpoint that every AI-found dependency issue passes through before it becomes a message to anyone outside your team. Not a tool. A page. The job of the desk is to turn a raw finding into either a clean, deduplicated, reproducible report, or a decision not to send one yet.

It sits one step before the upstream world, which is what makes it different from an internal dependency exception lane. The exception lane decides how your shop reacts to a dependency problem: pin, patch, fork, wait. The vulnerability desk decides what, if anything, you say to the people upstream, and in what shape. One faces in. One faces out. You want both, and you want the outward-facing one to be deliberately slow.

Eight fields. Fits on one page. Fill it before anything leaves your team.

1. Dependency and business surface. Name the exact package and version, and then name where it actually touches your business. "It's in our build" and "it signs customer payloads in production" are different findings about the same library. The surface tells you how hard to push and how fast.

2. Finding origin and the tool or model that produced it. Write down what found it: which scanner, which agent, which model, which query or rule. A finding from a deterministic CVE scanner and a finding a language model inferred from reading source are not the same kind of claim, and the person you eventually report to will ask. Record it now, while you remember.

3. Reproducible evidence, not model text. This is the field that keeps you out of the flood. A paragraph of confident model reasoning is not a vulnerability report; it is a hypothesis. Before anything leaves, you need a reproduction a human ran: input, observed behavior, why it is a problem. If you cannot reproduce it, that is not a reason to send it faster with a disclaimer. It is a reason to keep working or to drop it.

4. Duplicate check against advisories, issues, and vendor notices. Before you write to anyone, look. Is there an open advisory? An existing issue? A vendor security note? A fix already in a newer version? Most "discoveries" against popular packages are rediscoveries, and the single most useful thing a small team can do for an overloaded maintainer is not be the ninth person to report a known bug. This is the manual version of the deduplicate step Akrites built into its pipeline. You do it with a search bar.

5. Severity hypothesis and its uncertainty. Write your best guess at severity, and then write what you are unsure about, in plain words. "We think high because it's remotely reachable, but we have not confirmed it triggers without authentication." Honest uncertainty is more useful to a maintainer than a confident CVSS score the model produced from thin air. The uncertainty is information. Send it.

6. Disclosure owner and the embargo clock. Name one human who owns this disclosure end to end. Not a team, a person. Then decide your clock deliberately instead of inheriting one: when, if ever, does this go public, and who decides. A finding without a named owner becomes everyone's and no one's, which is how the same bug gets reported by three of your own people on three different timelines.

7. Upstream contact path or coordination body. Find the right door before you knock. Does the project have a security policy, a private reporting channel, a SECURITY.md? Is the package one where a coordinating body or a CNA should be involved instead of a public issue? The wrong door is a public issue tracker for a live, unpatched, exploitable bug. Routing is a courtesy and a control at once, and for the critical-infrastructure tier, Akrites is now part of that routing map even if you are reporting from the outside.

8. Interim mitigation while upstream verifies. Decide what you do for your own customers in the gap between "we found it" and "upstream confirmed and fixed it." Pin a version, add a guard, restrict a path, monitor for the behavior. This is the field that protects the people who pay you, and it is the one most likely to be skipped in the rush to feel responsible toward the maintainer. Take care of your own surface first; it does not slow the disclosure, and it means you are not exposed while you wait.

This is "stop spraying," not "stop scanning"

It would be a misreading to take all this as a brake on finding things. Scan aggressively. Point your best AI tools at your dependencies, let them work at machine speed, find everything they can. Discovery is not the problem, and a small team that finds a real bug in something it depends on has done something genuinely valuable.

The problem is what happens in the ninety seconds after the finding appears, when the easy move is to forward it raw, fast, to whoever feels responsible. That is the spray. Eight findings, eight inboxes, eight clocks, no reproduction, half of them already known. The desk is the difference between spraying and aiming. It does not slow your scanners by a second. It slows the handoff by exactly as long as it takes to be sure you are sending something real, something new, and something useful, through the right door, with your own customers already covered.

That is also why this pairs naturally with scoping the tools themselves. Deciding what a scanner or agent is even allowed to reach, and what it must do with what it finds, is the same discipline pointed upstream of the desk; that is the work in our AI workflow security review. And once a finding does move, the desk's eight fields double as the receipt you keep: the record of what you saw, what you sent, to whom, and when, so a disclosure three weeks from now is reconstructable instead of a memory.

Map one workflow

You do not need a SIRT. You need to make sure that the first time one of your AI tools finds something real in a dependency, the path from "the model flagged it" to "a human upstream heard about it" runs through a desk and not through a panic.

Pick the workflow most likely to find something: the scanner in CI, the coding agent with repo access, the model your developers ask to "audit this." Trace what happens today when it returns a hit. If the honest answer is "someone would probably just email the maintainer," you have found the gap. Map one AI-assisted vulnerability workflow before it emails maintainers, and write the eight fields it has to clear first.

If you want help drawing that path, BaristaLabs can map a vulnerability handoff with you. Bring one dependency your business actually leans on, define its desk, and make the AI-found bug leave your team as a clean report instead of noise in someone else's incident. That is the shape of the process automation work we do, and where it meets data security: the handoff gets built before the scanner forces the question.

The industry built the coordination room. Yours is one page, and it is just as real. Do not build a louder scanner. Build a quieter handoff.