Finding potential vulnerabilities in open-source software has become easier with AI tools, but the ease of identifying a suspected problem does not mean it is a real, exploitable vulnerability. As a result, project maintainers face a stream of lengthy, inaccurate, or duplicate reports, consuming time that could otherwise be directed toward fixing defects and developing software.
The Akrites initiative, announced by the Linux Foundation in June, is attempting to address this gap through a joint security incident response team (SIRT). Its mission is to aggregate and validate vulnerability reports and coordinate fixes with the maintainers of the original projects. In an interview with The New Stack during Open Source Summit Europe in Prague, Christopher Robinson, Akrites’ technical director and chief security architect at the Open Source Security Foundation (OpenSSF), and Laura Guazzelli, Linux Foundation security architect for AI and agentic systems, explained the nature of the problem and how the initiative works.
From “Vibe Researching” to an Operational Burden
Robinson says that having a $20 paid account is now enough to start searching for vulnerabilities, pointing to the lower barrier to entry for non-specialists. Adrianne Marcum, OpenSSF’s chief of staff, jokingly described this pattern as “vibe researching,” referring to the use of AI tools to scan code and submit findings without possessing the security context or expertise needed to validate them.
Robinson estimates that reviewing a single security report can take an engineer up to eight hours. Automated reports, he says, are highly detailed but often inaccurate, overstate the severity of the problem, and do not always provide the data required to write a fix or understand how the vulnerability can be exploited.
Why Detecting Suspicious Code Is Not Enough
One of the main limitations is that a model may see a suspicious code segment without understanding the project’s full security architecture. Additional controls elsewhere may prevent the flaw from being exploited, making the report a false positive or reducing its actual severity. Similar models also tend to discover the same defects, so maintainers receive multiple reports about the same problem.
Nevertheless, Akrites does not consider ignoring AI-generated reports a practical option. Robinson says the quality of the results has improved over the past year, particularly with more expensive paid models. The tools can also sometimes connect low-severity issues and turn them into a larger exploit chain, a task that could take a human researcher months or a year.
Human Review Before a Report Reaches the Project
Akrites uses AI to evaluate incoming reports and detect duplicates. Seconded engineers then review them before they are referred to maintainers. Their role is not limited to determining whether a vulnerability exists; it also includes shortening the report and adding test cases, proofs of concept, and patches, so the project can make a faster, more evidence-based decision.
The initiative’s founding members include Anthropic, OpenAI, Google, Microsoft, AWS, NVIDIA, Cisco, IBM, Red Hat, Citi, and JPMorganChase. According to Robinson, members are asked to provide engineering resources in addition to funding, and the commitment can reach 10 full-time engineers per member. He says he has around 200 seconded engineers, many of whom are already contributors or maintainers of open-source projects.
What Is Changing in Practice?
Akrites places a triage and validation layer between vulnerability-discovery tools and project maintainers, rather than sending every automated result directly to the people responsible for the code. This may reduce noise and improve the actionability of reports, but it does not eliminate the need for human expertise or continued funding, as infrastructure and language-model usage consume significant resources.
Another initiative associated with the Linux Foundation, the open source Cyber Reasoning System (OSS-CRS), is developing tools to help projects themselves investigate vulnerabilities and propose fixes. While Akrites focuses on coordinating the reporting cycle between projects, OSS-CRS is concerned with enabling maintainers to carry out more of the work themselves. The effectiveness of proposed patches remains an open question, as they must be verified to ensure that they address the root cause without introducing new vulnerabilities or breaking existing functionality.