Not a scanner, not a bounty program
Akrites, announced by the Linux Foundation with founding commitments from companies including Amazon Web Services, Anthropic, Cisco, Google, IBM, JPMorganChase, Microsoft, NVIDIA and OpenAI, is not a tool you install and not a marketplace where researchers get paid for individual bugs. It is closer to a piece of coordination infrastructure: a shared Security Incident Response Team (SIRT) paired with a single, standardized Coordinated Vulnerability Disclosure (CVD) process.
That distinction matters because it separates three things that often get conflated. Finding a flaw is the technical act of noticing that a piece of code behaves unsafely. Coordinating disclosure is the social and procedural act of getting that finding to the right people, confirming it is real, and agreeing on when the public gets to know. Shipping a fix upstream is the engineering act of actually changing the code in the project’s original repository so every downstream user benefits from one patch rather than a dozen forks. Historically, open-source security work conflated these stages inside individual, under-resourced projects. Akrites is built around the idea that they should be handled by a shared team that many organizations feed into and draw from.
Open-source software — code whose source is publicly available for anyone to read, use, and modify — has always relied on a mix of paid maintainers, corporate sponsors, and volunteers to keep it secure. A coordinated vulnerability disclosure process is the industry’s long-standing answer to a basic risk: publishing a flaw before a fix exists just hands attackers a map. The idea is to report privately, verify and patch, then disclose once protection is in place or an agreed window closes. Akrites doesn’t invent this concept — it tries to give it a single, well-funded home instead of leaving it to whichever maintainer happens to answer email that week.
Why the bottleneck moved
The immediate trigger for Akrites is the claim, repeated by its founding members, that frontier AI models have "collapsed the previous equilibrium between attackers and defenders". Automated tools can now scan a large codebase and surface candidate vulnerabilities in minutes, a task that used to take skilled human researchers weeks. That cuts both ways: defenders can find flaws faster too, but the volume of findings — many of them low-quality or duplicated — has overwhelmed the humans who have to judge which ones are real and fix them.
Christopher Robinson, chief security architect at the Linux Foundation, described the practical symptom bluntly: upstream projects are being "inundated with vulnerability reports of varying degrees of quality which far exceeds these volunteer developers’ ability to evaluate and keep up". As evidence of scale, Endor Labs co-founder Varun Badhwar said more than 23,000 vulnerabilities were surfaced within a month of a related initiative called Project Glasswing, touching around 1,000 open-source projects, including roughly 6,000 rated high severity or critical — with partner organizations finding another 10,000 severe flaws on top of that. According to Badhwar, fewer than 5% of these validated vulnerabilities had been patched. Those figures come from the companies involved in the effort rather than from independent auditors, so they are best read as the coalition’s own account of the scale of the problem it is trying to solve, not as externally verified statistics.
Following a flaw through the pipeline
What Akrites proposes is to route that flood through a single confidential channel rather than many parallel ones. In practice, a report — whether from a member company’s tooling, a researcher, or an AI-assisted scan — enters the shared SIRT, gets checked against existing reports to eliminate duplicates, is validated and prioritized, and then a fix is developed and returned to the project’s own maintainers before anything becomes public.
flowchart TD A[Member finds or reports flaw] --> B[Shared SIRT intake] B --> C[Deduplication and validation] C --> D[Fix developed with maintainer] D --> E[Embargo period, TLP-controlled] E --> F[Coordinated public disclosure]
The embargo stage is where a labeling system called TLP, or Traffic Light Protocol, typically governs who is allowed to see sensitive details before release — a common convention in security work that Akrites says it will use alongside standards like CVE, CVSS, and CWE for classifying and scoring flaws. Where a critical package has no active maintainer at all, Akrites says it will act as a "maintainer of last resort" so a fix still reaches users rather than sitting orphaned.
What actually changes
The operational shift is easier to see side by side with the pattern it replaces.
| Aspect | Old, fragmented pattern | Akrites model |
|---|---|---|
| Reporting | Many separate researchers, scanners, and vendors report independently | One shared intake point across member organizations |
| Duplication | Same flaw reported multiple times to the same maintainer | Reports deduplicated centrally before reaching maintainers |
| Confidentiality | Inconsistent handling; risk of premature leaks | TLP-based, confidentiality-first process across the pipeline |
| Maintainer workload | Volunteers triage an unpredictable, high-volume inbox | A shared SIRT filters and validates before contacting maintainers |
| Disclosure timing | Ad hoc, sometimes conflicting patches and timelines | Single coordinated disclosure once a fix is ready |
For maintainers, the promise is fewer, better-vetted reports and, per JPMorganChase’s chief information security officer Pat Opet, "a single, reliable signal" instead of duplicative and conflicting ones. For large vendors and financial or infrastructure operators, the appeal is a predictable channel for getting fixes deployed before public disclosure, since — as Opet put it — the group intends to "measure success in patch deployment, not patch publication". For everyday downstream users, the practical effect, if it works as described, is that a shared open-source component gets one authoritative fix rather than a scattering of forks and partial patches.
What remains open
Akrites is a launch, not a track record. It is seeded by Alpha-Omega, a Linux Foundation fund, and depends on member companies sustaining engineering time and funding beyond the initial announcement. Several practical questions are unresolved: how conflicts between a member company’s priorities and a maintainer’s own preferences get settled, which projects or vulnerability classes are handled first given finite capacity, and how the new pipeline avoids becoming another queue that upstream developers have to negotiate alongside existing disclosure channels. The initiative also does not replace ordinary practices like code review, dependency management, or patch testing inside individual organizations — it is a coordination layer sitting on top of that work, not a substitute for it.
The underlying shift is nonetheless a real one worth tracking: for years, the open-source security conversation centered on finding flaws before attackers did. Akrites is a bet that the harder, more expensive problem now is what happens after discovery — sorting signal from noise, agreeing on one fix, and getting it upstream before the gap between finding and exploiting closes any further.
