On June 25, 2026 the Linux Foundation launched Akrites, a shared Security Incident Response Team and a single Coordinated Vulnerability Disclosure process for critical open source software, backed by 19 founding members including AWS, Anthropic, Google, Microsoft, OpenAI, and JPMorganChase. The bet is that one confidential front door beats the flood of duplicate, LLM-generated reports now hitting maintainers.
What is Akrites?
Akrites is an upstream coordination body: a shared Security Incident Response Team (SIRT) and one standardized Coordinated Vulnerability Disclosure (CVD) process that serves as a single, confidential front door for vulnerability reports against critical open source projects. Instead of each maintainer running their own triage, Akrites absorbs the intake, deduplicates the noise, and hands the project one validated case.
The 19 founding members span AI labs and hyperscalers (AWS, Anthropic, Google, IBM, Microsoft and GitHub, NVIDIA, OpenAI, Rust Foundation), security vendors (Chainguard, Endor Labs, RapidFort, Sonatype, Zscaler), and enterprise buyers (Citi, JPMorganChase, Vodafone), alongside Cisco, Ericsson, and Red Hat. Getting AWS, Google, and Microsoft to co-sign the same disclosure process is itself the headline for anyone who has watched vendor CVD practices diverge.
The name comes from the Akritai, the Byzantine Empire’s frontier guardians, with the project positioning the open source upstream as the modern frontier where defenses are thinnest. That framing identifies the load-bearing actor as the maintainer of a widely-depended-on package, not the enterprise SOC or the CVE database.
The architecture is described as a confidential, structured place to coordinate vulnerability discovery, remediation, and disclosure, built on “confidentiality-first principles and industry-standard tooling”. Founding members commit engineering talent, security expertise, and funding rather than cash alone.
Why launch this now?
The launch lands two days after former Go Security lead Filippo Valsorda published the argument that gave the project its urgency. On June 23, 2026 he wrote that vulnerability reports “are not special anymore” because LLMs have collapsed the discovery bottleneck: the models are as good as almost any security researcher, anyone can run them, and the scarce resource is now assessing which findings are real, not finding them.
The Linux Foundation’s own framing leans on the same shift. Its announcement claims frontier AI models can now scan a major open source project and surface vulnerabilities in minutes, where previously finding and fixing serious flaws demanded comparable expertise from attackers and defenders. If that is half right, the old CVD model, in which a maintainer reads one careful report from one careful researcher, is structurally mismatched against incoming volume.
Endor Labs, one of Akrites’ founding members, supplied the remediation gap that frames the whole initiative: according to the company, fewer than 5% of recently validated open source vulnerabilities have been patched.
The maintainer side of the same problem is documented, not predicted. A widely used library is often maintained by a handful of contributors or a single developer balancing maintenance with a full-time job, and each report still has to be reviewed by a person: reproducing the issue, deciding whether a CVE is appropriate, developing a patch, and moving that fix through coordinated disclosure before details become public. None of that work got easier because AI produces findings faster.
How does a vulnerability flow through Akrites?
The operational core is the shared SIRT itself. Instead of multiple organizations independently scanning the same package and filing the same finding five different ways in one week, reports route into one confidential front door and one coordinated validation, remediation, and disclosure process. The public material describes Akrites as giving upstream maintainers “a coordinated, predictable partner” rather than a flood of independent reporters.
Deduplication is where the design bet lives. Done well, a maintainer receives one validated case instead of five near-identical reports landing in their security@ inbox, with the SIRT handling the validation, remediation, and disclosure work that previously fell on each project.
The confidentiality framing is the part of the pitch most likely to survive close scrutiny. Akrites is described as built on “confidentiality-first principles and industry-standard tooling”, and the stated mission is to coordinate fixes with upstream maintainers before vulnerabilities can be exploited. That describes a process meant to respect the existing project hierarchy rather than displace it.
Does centralization actually reduce the maintainer burden?
In theory, yes, and the mechanism is concrete. Today a maintainer facing dozens of reports describing the same underlying issue has to negotiate each one separately, and the cost of engaging outweighs the value when most are duplicates. A shared deduplication layer collapses those into a single validated case.
The funding model is the second pillar. Founding members commit engineering talent, security expertise, and funding, which is the signal that the SIRT is meant to be staffed rather than aspirational. The unanswered question is what happens to packages with no active maintainer; launch material does not describe a fallback for abandoned but critical code, and that gap is where the burden-reduction argument is weakest.
What could go wrong, and what stays unproven?
Centralization trades a distributed flood for a single choke point, and that trade is the unproven part of the design. The launch roster is impressive; throughput and neutrality are what will actually be tested.
The first failure mode is throughput. If the SIRT cannot keep pace with upstream release cadence and incoming report volume, the clearinghouse becomes the bottleneck it was built to remove, and maintainers who offloaded triage to it are left with neither their old muscle nor a working front door. Launch-day coverage publishes no capacity, staffing, or target cadence.
The second is governance. Nineteen members include direct competitors across cloud, security, and finance, and if they disagree on disclosure timelines, Akrites must adjudicate between parties who also buy from, sell to, and audit each other. A neutral body is only as neutral as its dispute resolution, and launch-day press describes the roster and the mission, not how member disagreements are resolved.
The third is sustainability. Running a shared SIRT across critical open source is the highest-value and highest-cost commitment in the design, and it depends on funding and staffing that founding-member commitments only begin. There is also a subtler risk: once maintainers route reports through Akrites, the institutional knowledge of how to triage a security report atrophies on the project side, which is fine while the SIRT is healthy and a serious problem if it is not.
What is Akrites explicitly not?
Akrites is an upstream coordination body, not an enterprise security product, and joining or watching it does not substitute for downstream work. Its scope is the supply of validated fixes and their coordinated disclosure; it does not extend to deploying them in any consumer’s estate.
A faster, deduplicated CVD pipeline does not reduce the number of unpatched packages in your estate; it changes which fixes are available and how reliably they are described. Closing the deployment gap remains the consumer’s job.
Does coordinated disclosure still make sense?
The sharpest counterpoint to Akrites comes from inside the security community, and it does not assume the project will fail. It asks whether servicing reports is worth doing at all.
Valsorda’s post is the document to read alongside the announcement. He writes that in 2026 “none of the premises are true anymore”, and that confidentiality, embargoes, and coordination “don’t matter nearly as much as they used to” because attackers can ask their own LLM rather than wait for a disclosure post. The reasoning is not that disclosure is bad but that the premise has shifted: when bugs are cheap to find and cheap to rediscover, the coordination overhead of a careful embargo stops paying for itself.
Akrites does not resolve this argument. It optimizes a process that Valsorda is openly questioning. The strongest case for the project is that his own position implies someone still has to sort real findings from noise, and a shared SIRT doing deduplication beats each maintainer doing it alone. The weakest case is that the same models flooding the inbox make coordinated disclosure’s central premise, that disclosure buys defenders time, increasingly false. The launch does not settle which reading wins.
The launch answers who is at the table. The next twelve months answer whether the table can keep up.
Frequently Asked Questions
How is Akrites different from MITRE’s CVE program or FIRST’s coordination work?
Akrites positions itself as a coordination layer that integrates with external Finders like Glasswing, MITRE/CVE, Lightwell, and FIRST rather than competing with them. Those efforts surface vulnerabilities; Akrites absorbs the deduplication, validation, and synchronized disclosure work that currently falls on each upstream maintainer.
What standards and protocols does the Akrites SIRT actually run on?
Case management builds on the CVE, CWE, CVSS, EPSS, SSVC, VEX, and VINCE stack, and confidentiality is enforced through the TLP 2.0 protocol with findings classified TLP:RED from intake and visible only to the case team. A report therefore enters an already-classified channel rather than a generic security inbox.
What fallback exists for critical packages with no active maintainer?
The project site describes Akrites acting as a maintainer of last resort so that fixes to the latest version still reach downstream consumers, with seed funding from Alpha-Omega, the Linux Foundation’s directed fund. That role separates Akrites from a pure coordination front door and is the untested commitment for abandoned-but-critical code.
Is there precedent for maintainers simply closing their vulnerability channels?
curl suspended its vulnerability reporting channels for roughly a month, a move Valsorda initially called excessive before conceding he could no longer argue that servicing reports protects users. William Woodruff, a security maintainer, reports triaging well over a dozen reports a week and increasingly banning sloppy reporters because LLMs make the underlying bugs shallow to rediscover.
