Linux Foundation Launches Akrites to Secure Critical Open Source Software

The Linux Foundation launched Akrites on June 25, 2026, establishing a unified industry coalition to protect critical open source software. The initiative creates a shared Security Incident Response Team and standardizes vulnerability disclosures to counter the rapid rise of artificial intelligence-assisted exploit discovery. Backed by founding partners including Amazon Web Services, Anthropic, Google, Microsoft, OpenAI, and Red Hat, the project aims to coordinate defense before security flaws can be actively weaponized.

Coordinating Disclosures Amid Faster AI Exploitation

Historically, security researchers and attackers alike relied on manual code reviews and basic scanning scripts to locate software vulnerabilities. The emergence of specialized AI tools has compressed this security testing timeline. Modern AI systems can scan massive repositories, evaluate software structures, and isolate complex security flaws in a fraction of the time required by human engineers.

This automation has fundamentally changed the speed of software exploitation. Once a security flaw is identified, automated tools can generate functional exploit code almost immediately. This capability significantly reduces the window of safety that software developers historically relied on to design and test security fixes.

Critical open source components serve as the foundation for modern global infrastructure. Flaws in widely used code libraries can directly compromise banking systems, telecommunications networks, electrical grids, and cloud database environments. Akrites targets this risk by standardizing defense mechanisms to match the speed of automated scanning tools.

Streamlining the Reporting Pipeline for Open Source Maintainers

Open source software is often maintained by small groups of independent developers or unpaid volunteers. In the current security landscape, these maintainers are frequently overwhelmed when multiple corporate security teams independently find the same bug.

Before the launch of Akrites, the developer experience during a security incident was highly fragmented. The following sequence serves as a hypothetical example of how this process typically unfolded:

1. A security researcher discovers a zero-day vulnerability in a widely used library and reports it to a single cloud provider.
2. A separate security firm finds the same flaw and submits a conflicting report directly to the repository maintainer.
3. One reporter demands a public advisory within 48 hours, while another offers an incomplete patch that introduces new bugs.
4. The maintainer is forced to triage multiple overlapping alerts, write a fix under public pressure, and coordinate separate notifications.

This decentralized reporting often results in duplicated engineering effort and conflicting software patches.

Akrites modifies this workflow by establishing a unified central intake. Under the new model, security reports are channeled through a single shared system, presenting the repository maintainer with a consolidated, pre-validated patch.

[Security Researchers / Automated AI Scanners]
                     │
                     ▼
       ┌───────────────────────────┐
       │   Akrites Central SIRT    │ <--- Validates and coordinates
       └─────────────┬─────────────┘
                     │
                     ▼
       ┌───────────────────────────┐
       │    Upstream Maintainer    │ <--- Approves unified patch
       └─────────────┬─────────────┘
                     │
                     ▼
       ┌───────────────────────────┐
       │  Downstream Infrastructure│ <--- Deploys fix confidentially
       └───────────────────────────┘

Architecture and Standards of the Shared SIRT

The core operational unit of the project is a shared Security Incident Response Team (SIRT). This specialized team of engineers is responsible for receiving vulnerability submissions, confirming the technical details, and managing the security response.

The SIRT operates under strict confidentiality protocols to prevent early exposure of software bugs before patches are ready. It relies on a suite of industry-standard security frameworks and tools to classify and evaluate threats, including:

• Common Vulnerabilities and Exposures (CVE): A registry that assigns unique identification numbers to publicly known security vulnerabilities.
• Common Weakness Enumeration (CWE): A community-developed list of common software and hardware security weaknesses.
• Common Vulnerability Scoring System (CVSS): A framework for rating the severity of software vulnerabilities on a numerical scale.
• Traffic Light Protocol (TLP): A set of designations used to ensure that sensitive security information is shared only with appropriate audiences.
• Vulnerability Exploitability eXchange (VEX): A product security data format that allows organizations to state whether a specific product is affected by a known vulnerability.
• Exploit Prediction Scoring System (EPSS): A data-driven framework used to estimate the probability that a software vulnerability will be exploited in the wild.
• Stakeholder-Specific Vulnerability Categorization (SSVC): A decision-making framework designed to help prioritize vulnerability remediation based on organizational impact.

Using these standardized systems allows the team to convert complex threat data into structured, actionable remediation plans for upstream developers.

Serving as a Maintainer of Last Resort

A significant structural risk in the software supply chain involves abandoned or underfunded open source components. Many critical libraries utilized by major enterprise systems are no longer actively updated by their original creators.

When a security vulnerability is discovered in one of these orphaned packages, there is often no active development team to apply a patch. To address this exposure, Akrites will act as a “maintainer of last resort” to ensure security fixes reach the latest version of critical packages that lack active maintainers, rather than writing and distributing updates for legacy packages or older code structures.

Funding and Coalition Commitments

Initial funding for the project is provided by Alpha-Omega, a directed security fund managed by the Linux Foundation.

The coalition’s founding corporate participants are committing both financial backing and direct engineering talent to run the day-to-day operations of the shared security team. To mark the launch, the participants published a joint open letter titled “We All Depend on Open Source. We Will Defend It Together”.

The founding members committing these resources include Amazon Web Services, Anthropic, Google, Microsoft, OpenAI, and Red Hat. The Linux Foundation has opened the initiative to additional organizations that are willing to contribute engineering resources, technical security expertise, or capital to secure the shared software supply chain.