Software security

A coalition of technology companies, including Anthropic, AWS, IBM and Microsoft, announced a joint effort to find, disclose and remediate security flaws in open-source software. 

The group, called Akrites, will establish a shared security incident response team as well as a coordinated vulnerability disclosure process. 

The founding members, led by the Linux Foundation, will commit extensive resources to the effort, including funding, engineers and cybersecurity expertise. 

Officials said the plan was mainly driven by the emergence of frontier AI models that radically accelerated the ability to discover vulnerabilities in critical software applications. And malicious actors have demonstrated the ability to weaponize AI for use in sophisticated attacks. 

The existing open-source ecosystem does not have the ability to discover and remediate vulnerabilities fast enough to protect millions of users from potential attacks. The group outlined some of these concerns in an open letter to the industry. 

“Artificial intelligence has collapsed the previous equilibrium between attackers and defenders, changing the equation of ease and reuse of software,” the coalition wrote in the letter. 

Disclosure backlog

Akrites is designed to address some of the systemic challenges facing the open-source community in terms of developing a coordinated vulnerability disclosure process, according to Christopher Robinson, CTO of Open Source Security Foundation and chief security architect of the Linux Foundation. 

The emergence of large language models and sophisticated scanning tools in recent years has made all of those historic challenges even more serious.

“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,” Robinson told Cybersecurity Dive.

Seed funding for Akrites will be provided by Alpha Omega, which is a directed fund under the Linux Foundation. Other organizations are being asked to provide additional resources or engineering talent. 

The open-source community has faced mounting concerns in recent years about the inability of traditional maintainers to quickly discover and disclose vulnerabilities in order to prevent widespread supply chain attacks. 

Varun Badhwar, co-founder and CEO of Endor Labs, said more than 23,000 vulnerabilities were discovered just one month after the announcement of Project Glasswing, impacting about 1,000 open-source projects. These include about 6,000 vulnerabilities that were considered high severity or critical. 

In addition, Glasswing’s partners found another 10,000 high-severity or critical flaws. Only 5% of these vulnerabilities have been fixed. 

“No volunteer ecosystem was built to absorb that,” Badhwar told Cybersecurity Dive. 

Other founding companies in Akrites include Cisco, Citi, JPMorgan Chase, NVIDIA, OpenAI, Ericsson and others. 

In November 2021, a zero-day vulnerability in a ubiquitous piece of open-source code stunned the technology industry and set off an urgent effort to help secure the largely volunteer open-source ecosystem. Nearly four years later, that effort has made important progress but has also been hobbled by multiple setbacks.

The Log4Shell vulnerability in a popular Java logging tool convinced the Biden administration to focus on open-source security and prompted major tech companies including Amazon, Google and Microsoft to pledge tens of millions of dollars to security improvements. Much of that work occurred through the Linux Foundation’s Open Source Security Foundation (OpenSSF), which created numerous tools to help developers analyze and address their code’s risks.

But what began with a White House summit and an ambitious industry-wide “mobilization plan” soon encountered challenges. A tantalizing new technology known as generative AI distracted the tech giants funding the work, and a political transition in the U.S. extinguished government efforts to keep the industry on track.

Overcoming those obstacles and doubling down on open-source security is essential, experts told Cybersecurity Dive, given how pervasive the code is in everything from critical infrastructure to everyday home computing.

“We need to make sure that the momentum that we built doesn’t get lost,” said Jack Cable, a former senior technical adviser at the Cybersecurity and Infrastructure Security Agency (CISA) who worked on open-source security.

Open-source security progress

Since early 2022, an infusion of funding and attention has led to important open-source security improvements.

One of the most significant developments was the campaign to improve the security of open-source package repositories. The repository “is the modern distribution point for the majority of software that’s consumed,” said David Nalley, director of developer experience at Amazon Web Services, which has helped fund improvements in these vital platforms. Christopher Robinson, OpenSSF’s chief security architect, said the goal of this work was to ensure that “all projects within those ecosystems will inherit” strong security practices.

Amazon also helped the developers behind a TLS encryption library for the memory-safe programming language Rust adopt a cryptographic algorithm that met federal standards, making it easier for organizations that need to meet those standards — including companies in regulated industries — to use memory-safe code.

Robinson highlighted OpenSSF’s Sigstore project, which lets developers digitally sign their code to prevent tampering. He also praised tech companies for embedding security experts in communities built around certain programming languages to serve as those groups’ “ambassadors” to the broader ecosystem.

The Cybersecurity and Infrastructure Security Agency (CISA) used its authority and its experts’ reputations to build bridges between agencies using open-source code and the developers producing it. 

“[We] really did a lot to make sure that … when incidents occurred, folks would be able to connect with each other,” said Cable, now the CEO and co-founder of the AI coding security firm Corridor. He said those efforts paid off during the 2024 XZ Utils crisis, in which a malicious actor used social engineering to fool an overwhelmed developer and plant a backdoor in their widely used package.

Perhaps most significantly, companies that depend on open-source packages are increasingly taking responsibility for ensuring that they are secure, instead of treating open-source developers like their unpaid labor force.

Open-source developers have complained for years that they feel exploited by the companies using their code for profit, according to Arnaud Le Hors, senior technical staff member of open technologies at IBM. Now, more businesses “realize that you can’t just depend on the community at large to fix vulnerabilities in open-source packages that you decide to use in your products.”

“A lot of good work did happen” over the past few years, Cable said, “and still a lot is ongoing.”

Declining investment

After Log4Shell exposed the precarious state of the open-source ecosystem, leading tech companies met with Biden administration officials and pledged more than $30 million in services, infrastructure and personnel to help. 

But while the companies’ efforts have yielded some results, experts said they haven’t lived up to expectations.

Tech firms’ commitments have “not materialized at the amount promised,” leading to “a lot of disappointment,” said Aeva Black, who led CISA’s open-source security program for two years. In addition, many other companies haven’t even committed anything, Cable said, because they “still don’t recognize … the value that they’re getting out of open-source software” and “aren’t thinking about how they interact with maintainers, let alone start[ing] to contribute back.”

Amazon, one of the biggest early funders of OpenSSF’s work, is “investing more today than we were post-Log4Shell,” Nalley said, but its “investments have evolved as we’ve learned what works and what doesn’t. … Some [investments] have paid off well. Others, maybe not as we had hoped.”

As companies have scaled back their ambitions, the U.S. government has gone from prodding them forward to abandoning the field under President Donald Trump. Open-source work “has slowed down under the new administration,” Le Hors said.

The Biden administration pledged $11 million toward open-source security, but Black said “those promises are not being followed through.”

The Trump administration’s cuts to CISA and the departures of Black, Cable and other widely respected subject-matter experts have essentially eliminated the agency’s work on open-source security.

CISA’s advocacy helped open-source experts at tech companies convince their employers to “follow through on their commitments” and become more active participants in the community, Black said.

Going forward, Cable said, “it is unclear what CISA and, generally, the federal government’s level of involvement will be” in open source.

CISA “remains laser-focused” on open-source security, Marci McCarthy, the agency’s director of public affairs, said in a statement. “Open-source software is a critical building block in our software supply chain for both the federal government and U.S. critical infrastructure,” McCarthy said. “We are privileged to have a talented team at CISA dedicated to understanding and mitigating risks in open-source software.”

OpenAI accidentally upends everything

On Nov. 30, 2022, only a few months into OpenSSF’s security initiative, OpenAI released ChatGPT. As generative AI chatbots captivated the public, tech companies rushed to embrace the technology. And right around that time, Black said, “several of the big companies that made [open-source security] promises started to reassign their developers away from open-source security and onto AI tools.” 

In the ensuing years, Black said, open-source security fell by the wayside as companies made “big pivots to double down on AI.”

Most of the Microsoft experts that Black worked with on open-source security when they were at the company and at CISA “have been moved over to AI teams now,” they said. As CISA was recruiting them away from Microsoft, they recalled, their team at the company was “being picked apart and reassigned onto AI work.” 

Legal and policy staffers at Microsoft who had been supporting open-source work were also reassigned to AI, Black said, and Microsoft subsidiary GitHub “did a huge shift.”

Both Microsoft and Google “seem to be reallocating their human resources away from this effort,” Black said.

Microsoft did not dispute Black’s account, but Ryan Waite, its director of open source ecosystems and open source incubations, said the company remained deeply involved in the ecosystem. A Google spokesperson said it “continues to invest a substantial amount of resources and expertise” into open-source security.

Some experts believe AI will improve open-source security by dramatically speeding up the process of finding and fixing vulnerabilities. The Defense Advanced Research Projects Agency (DARPA) recently concluded a prize competition, held in partnership with OpenSSF, to develop AI-powered vulnerability detection software. 

But others aren’t as optimistic. Black pointed to a frustrated conference talk by the developer of the widely used curl package. “He is underwater,” Black said, “overwhelmed by AI-based developer slop — people proposing patches that are clearly written by generative AI tools that are garbage, and he has to just keep sifting through them and rejecting them.”

Unsolved problems

A wide range of pressing open-source security issues remain unresolved, according to experts who see varying degrees of commitment to them.

One of the most serious problems is that software developers — including those supplying the U.S. military — often don’t know where the code they use comes from. “People don’t have great insight into what they’re consuming,” Nalley said. This problem is particularly serious because of how many packages are in one piece of software — an average of 180, according to Sonatype — and because of how insecure many of those packages are. Nearly four years after the widely publicized vulnerability in Log4j, the flawed version still accounts for 13% of all downloads of the package, Robinson said.

OpenSSF’s Scorecard project will help developers address these “dependency” risks, Nalley said. Software bills of materials (SBOMs) could also help illuminate packages’ dependencies, although Black said open source’s complexity rendered them less than ideal.

Identifying and aiding the most sparsely maintained but vital projects remains another significant challenge. Some projects that underpin the entire internet may be the work of one or two volunteers. “We need to be making investments in there,” Nalley said. Harvard Business School has been addressing this problem through a periodic census.

The XZ Utils crisis highlighted the importance of reducing projects’ trust gaps and understanding the provenance of every line of code, and Le Hors said OpenSSF’s Supply-chain Levels for Software Artifacts (SLSA) project would help with that.

Tech companies rewriting packages in memory-safe programming languages face adoption challenges. “A lot of the [packages] we tried to rewrite did not see [significant] adoption,” Nalley said. His team helped rewrite the all-important sudo package and encouraged Linux distributions to incorporate it, but they said it had too many dependencies, so the team had to redo it.

More work also remains to secure package repositories. “Investing in the plumbing is really important,” Nalley said.

Even as work in the U.S. slows down, other governments aren’t standing still. New European Union legislation will hold businesses responsible for securing the open-source code they list, which will likely have global ripple effects.

“We’ve made lot of progress since the Log4Shell issue,” Le Hors said. “We’re still making some progress, thankfully, because the U.S. is not the whole world.”

Sponsored content

By Akamai Technologies

Executive summary

• API security incidents are rising: 87% of organizations suffered an API security incident in the past year, up from 76% in 2022.

• AI is connected: 42% of incidents involve APIs linked to AI technologies, such as large language models (LLMs) and autonomous agents.

• Visibility is crashing: Only 23% of enterprises with “full” inventories actually know which APIs return sensitive data.

• There is a confidence gap: C-suite leaders are significantly more optimistic about the maturity of their API testing than the DevSecOps teams doing the work.

• The financial fallout is significant: API-related breaches now cost top-quartile organizations upward of US$1.8 million annually.

A troubling reality for security professionals

The results of Akamai’s latest API Security Impact Study reveal a troubling reality for security professionals. While warnings about rogue APIs, shadow APIs, zombie APIs, and other API security vulnerabilities have convinced organizations to invest in API security in recent years, companies are still having difficulty maintaining pace with threats. In the rush to take advantage of new AI advancements, businesses are inadvertently creating a sprawling, unmapped attack surface that traditional defenses cannot see, let alone secure.

Results from the 2026 Akamai API Security Impact Study — a survey of 1,840 security leaders and practitioners across 10 countries — demonstrate how API growth is outpacing resilience efforts. While global enterprises now manage a median of 5,900 APIs, their ability to defend them is cratering.

This isn't just a technical glitch; it’s a systemic governance failure that costs the average organization US$700,000 per year. What’s more, costs are only going up. The 2024 API Security Impact Study placed the average cost at US$590,000.

Fortunately, organizations are beginning to understand the risks to their APIs. For example, for nearly 80% of enterprises, API security is among their top three cybersecurity priorities. Two-thirds of respondents report increased focus on API security over the past 12 months. And more than half (52%) cited API security incidents as among the top five cyberthreats that are most important to their organization for achieving cyber resilience.

Security teams just can’t keep up with the sprawl.

The great disconnect: Why WAFs are not enough

For years, organizations treated API security as a perfunctory compliance requirement on a web application firewall (WAF) requirement list. WAFs were designed to block “bad” signatures like SQL injection. But modern API attacks are “low and slow.” They use legitimate credentials and legal protocol structures to perform illegal acts.

Traditional web security treats APIs as secondary to the UI. In an AI-driven world, the API is the business.

Our research shows that while 80% of firms use a WAF, only 35% use dedicated API security tools. This reliance on legacy perimeters leaves a massive gap in Broken Object Level Authorization (BOLA) and business logic abuse. Attackers aren't breaking your code anymore; they are simply asking your APIs to do things they weren't intended to do — and your WAF permits the unauthorized traffic.

Indeed, BOLA attacks are often the result of misconfiguration issues like insecure direct object references or an over-reliance on client-side checks. This becomes particularly concerning given that half of the surveyed enterprises reported being only slightly-to-moderately prepared to address misconfigurations.

The shadow API epidemic and the AI multiplier

You cannot protect what you cannot see. The shadow API problem has reached a breaking point. This year’s data shows that while 77% of respondents claim to have a “full inventory of their APIs, visibility into the intent of those APIs has declined for four consecutive years.

In 2022, 40% of organizations knew which APIs returned sensitive data. Today, that number has plummeted to 23%. Attackers are exploiting this visibility gap using AI.

As enterprises invested US$37 billion in GenAI in 2025, they built thousands of new connections to LLMs. These AI-linked APIs determine what data a model can access and what actions it can trigger. If an attacker tricks an AI via prompt injection, it is the API that fetches the sensitive data.

Organizations are beginning to understand the risks. According to the 2026 API Security Impact Study, 42% of security professionals who reported API-linked security incidents over the past year said their incidents were attacks that involved APIs linked to AI technologies, such as apps, agents, and LLMs.

The confidence gap: A leadership crisis

One of the most startling findings in the 2026 API Security Impact Study is the difference between leadership perception and operational reality. Respondents were asked to evaluate the maturity of API testing within their organization on a three-level scale:

1. Functional testing that verifies whether APIs work as intended
2. Testing with some security focus that includes limited security checks
3. Advanced testing that systematically evaluates APIs for vulnerabilities and real-world attack methods

Additionally, organizations have understood for years that testing during the software development lifecycle (SDLC) is one of the most important steps in closing API security gaps. And although the perception gap is not quite as stark as the security gap, it also presents a problem.

Metric	C-suite confidence	DevSecOps reality
Advanced testing maturity	40%	28%
Full SDLC integration	19%	13%

[The C-suite confidence gap; Source: 2026 API Security Impact Study]

The gaps shown in the table suggest that senior leaders may be underinvesting in API security because they believe the problem is already solved. When the need for speed in AI deployment overshadows security, DevSecOps teams see the cracks first.

Overconfidence in the C-suite leads to a lack of dedicated resources: only 1 in 6 enterprises have fully embedded security testing for APIs into their CI/CD pipelines, which limits a key step in preventing abuse and attacks.

The true cost of the status quo

API security is no longer just an IT concern; it is a material business risk. The financial impact is escalating as attackers move from stealing simple data to disrupting core business logic.

The latest API Security Impact Study reveals how significant API incidents can be, including:

• Average annual cost: US$700,000 per organization
• Average annual cost to the top quartile: More than US$1.8 million
• Primary drivers of cost: System repairs, downtime, and legal fees

In industries like energy and utilities, the average cost jumps to US$860,000. The loss isn't purely financial — it impacts productivity. When APIs are compromised, the applications they power grind to a halt, leading to massive internal friction and loss of customer goodwill.

This realization is becoming increasingly clear to security leaders and practitioners. For nearly 80% of enterprises, API security is among their top three cybersecurity priorities.

A new path forward: Shifting from perimeter thinking

To survive the AI era, security professionals must not only continue to account for API vulnerabilities, but also shift their thinking. We can no longer rely on static defenses and hope all APIs are accounted for. Organizations must evolve their strategies to prioritize the API layer by:

• Closing foundational visibility gaps
• Moving beyond functional testing
• Formalizing API governance

Closing foundational visibility gaps

Stop relying on static spreadsheets. You need continuous, automated discovery that identifies AI-linked, shadow, and zombie APIs in real time. If you don't know which APIs touch personally identifiable information (PII) or HIPAA-regulated data, you risk losing the trust of customers and regulators.

Moving beyond functional testing

Functional testing only proves that an API works. It doesn't prove that it is secure. Enterprises must shift to advanced security testing that simulates real-world attack methods, such as credential stuffing and BOLA attacks, during the development phase.

Formalizing API governance

API security must be integrated into formal compliance reporting and risk assessments. While 95% of organizations say that they already factor APIs into regulatory requirements, only 38% include APIs in their mandatory reporting. The execution must match the intention.

Only Akamai protects the AI-driven enterprise

The AI race is underway, but it is not too late to strengthen your foundation. Akamai provides the global visibility and behavioral intelligence required to see and stop API abuse before it hits your origin. By combining dedicated API security with our global web application and API protection, we ensure that your AI innovations are built on a resilient, secure architecture.

Read the full report to get benchmark data on how your peers are approaching API security amid AI advances.

Barney Beal is a writer for Akamai’s cybersecurity group, bringing decades of experience making complex technology easier to understand and providing technology buyers with the information that they need to make informed decisions.

Microsoft and its partners are quietly grinding away on a massive project to completely redesign how cybersecurity software runs in Windows, with the hope of making it more resilient. But it could be years before customers see the results of one of the most ambitious software engineering transformations in decades.

The project, known as the Windows Resiliency Initiative, is intended to protect Windows computers from the disruptive effects of defective third-party software running inside the kernel, the operating system’s most powerful environment. Microsoft announced the effort after a faulty CrowdStrike software update in 2024 paralyzed millions of computers and caused billions of dollars in damages. The outage affected governments, critical infrastructure organizations and Fortune 500 companies and prompted widespread discussions about the risks of third-party code in the kernel.

The result is an unprecedented collaboration between Microsoft and third-party security vendors to redesign Windows, as well as products like endpoint detection and response (EDR) software and antivirus applications, in ways that improve resilience without sacrificing security or speed.

Microsoft and its partners have said little publicly about the major initiative, but everyone involved appears to recognize how hard it will be to rewrite the pathways between Windows and some of its most important tools.

“Every day’s a learning curve,” said Tony Anscombe, the chief security evangelist at ESET, one of the handful of companies working closely with Microsoft on the project. “We learn something every day.”

Lessons from the CrowdStrike incident

The Windows kernel is the core of the operating system, the connective tissue between a computer’s hardware and software components. It oversees how much memory applications are using, verifies the configuration of device drivers and deconflicts the work of the computer’s various processes. It can do all of this work because it has total control over everything happening inside the computer.

Because of the powers granted to programs running inside the kernel, security application developers have found it to be a useful environment for their products, which need total visibility and control in order to block cyberattacks.

“As a security vendor, you want to see everything that’s happening on the device,” Anscombe said.

The kernel’s ability to essentially freeze and reset the computer’s regular operating environment becomes a major asset when the computer encounters a problem, whether accidental or malicious. “Your machine doesn’t need to be rebooted,” Anscombe said, “and that’s because the application was running in that other mode, where Windows as the OS, the kernel mode, can shut down the user mode and restart [it] without doing a reboot.”

In addition to visibility and control, the kernel also offers speed and flexibility that greatly benefit security applications.

But the kernel’s immense power also comes with significant responsibility, as a defective kernel process could bring down an entire computer — or, if deployed widely, an entire network.

That’s exactly what happened on July 19, 2024, when CrowdStrike deployed a faulty software update to its endpoint detection and response (EDR) product, Falcon. The flawed code forced Windows computers running Falcon to restart endlessly or boot into recovery mode. More than 8 million machines around the world crashed and failed to restart, paralyzing airlines, banks, hospitals, stock markets, government agencies and emergency services. A tiny update to third-party software running in the Windows kernel had caused the largest IT outage in history, leading to billions of dollars in losses, including more than $5 billion for Fortune 500 companies alone.

“Had that [Falcon] process been running in user mode, the severity would have probably been very different,” Anscombe said.

The incident highlighted the dangers of running — and frequently updating — third-party code in the Windows kernel. Four months after the digital chaos subsided, Microsoft launched the Windows Resiliency Initiative and pledged to work more closely with third-party security vendors on responsible software development and deployment practices. The company said it would require all software updates for security programs to deploy gradually throughout customer organizations “to ensure any negative impact from updates is kept to a minimum.”

Microsoft also said it was “developing new Windows capabilities that will allow security product developers to build their products outside of kernel mode.”

“This change will help security developers provide a high level of security [and] easier recovery,” the company added, “and there will be less impact to Windows in the event of a crash or mistake.”

The CrowdStrike incident validated Microsoft’s longstanding unease about letting third-party developers run code in the Windows kernel, said Pavel Yosifovich, an expert on Windows architecture who trains and consults on the subject. Microsoft built in safeguards against kernel-level software crashes by requiring companies to sign their drivers and meet testing requirements, Yosifovich said, “but it’s not bulletproof.”

Windows API revamp

To coordinate the kernel migration project, Microsoft is using its existing Microsoft Virus Initiative (MVI), a program meant to help security vendors smoothly integrate their products into Windows. As part of the Windows Resiliency Initiative, Microsoft refreshed the MVI, dubbing it “MVI 3.0” and requiring participants to meet new reliability requirements.

Roughly 100 security companies are members of the MVI, Anscombe said, but only a dozen or so — representing “a significant majority of the market share” — are working hand-in-hand with Microsoft on the kernel changes. Microsoft has publicly identified Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro and WithSecure as part of that group, but otherwise it is keeping the kernel project shrouded in secrecy. Participating companies’ employees must sign nondisclosure agreements, and most of the companies that Cybersecurity Dive contacted declined interview requests for this story. 

Microsoft itself declined to answer even basic questions about the project, referring Cybersecurity Dive to its executives’ blog posts, which offer few details.

The kernel project is still in its early stages. Microsoft asked vendors to inventory all of their products’ features so the company knows what functionality they need preserved during the transition from kernel mode to user mode. The work has been incredibly complicated, both because vendors have had to review decades’ worth of code and because every vendor’s code works slightly differently.

“It really is an unpicking of how all these products work and then unpicking the OS to see if you can provide that functionality in different ways,” Anscombe said. “It’s a huge, huge task.”

The result is a highly unusual arrangement in the Windows development ecosystem, with Microsoft soliciting feedback from vendors and incorporating it in real time into the application programming interfaces (APIs) that let security products safely hook into Windows’ core components.

It’s “an unusual scenario you don’t often get,” Anscombe said. “This is not somebody developing an API and landing the API on your desk and saying, ‘Here’s our new API. You need to work with this.’ This is somebody developing an API while you're developing the things that will work with the API.”

Having seen how challenging the work has been for ESET, Anscombe said, “I wouldn’t want to be on the Microsoft end of this, of getting responses from 50 vendors and suddenly hav[ing] to try and map everybody’s [feedback] to give them all the functionality they need.”

Difficult balancing act

Microsoft and its partners will have to overcome serious challenges to make security software work just as well outside the kernel as it does inside it.

For one thing, the kernel affords greater control to software running there. This is particularly important for software designed to protect a system from malicious processes.

“When a process is created, a kernel driver can be notified, do some analysis, and decide to terminate the process before it does anything,” Yosifovich said. In user mode, software can only receive notifications about a process after the fact. “If the process is short-lived, and does something malicious,” Yosifovich said, “user mode may be too slow to do anything about that.”

Jeff Tang, a Windows security expert and independent consultant, said that in user mode, “your capabilities are much more limited to monitor the entire system.”

Yosifovich argued that “it’s almost impossible to run completely outside the kernel without significant reengineering or diminishing the powers for security products.”

Security programs running in user mode would also be much more vulnerable to tampering. “Your capabilities are on the same level as the thing you’re trying to monitor and/or stop,” Tang said, “so malware has the same opportunity to stop you from protecting the system” as the security program does to stop the malware.

The problem is far from theoretical. “We’re already hearing of ransomware EDR killers and all sorts of other things that try and do that,” Anscombe said. “You need to be able to give security vendors the [reassurance] that their application can’t be manipulated.”

In addition to the risk of tampering, user mode’s distance from the kernel introduces a processing delay. “Running in user mode is slower when accessing system APIs,” Yosifovich said.

That delay could make or break the customer experience, with potentially serious consequences. “What you don’t want to see is a customer turning around and saying, ‘Well, everything’s a bit slower now. I’m going to start turning things off,’” Anscombe said. “That’s a degradation of security.”

New API timeline TBD

Microsoft and its vendor partners are taking their time to analyze the challenges they face.

“At the moment, it’s more about how you’d move some of the features and functionality across, using an API in that way,” Anscombe said. “Testing, efficacy, et cetera, is further down the line.”

It remains unclear when Microsoft will publish APIs that vendors can use to build user-mode software, or when that software is ready for testing and deployment. Anscombe declined to discuss the project’s internal timelines, although he said the early work has validated vendors’ skepticism about a fast turnaround.

“This will be ongoing for a long period of time,” Anscombe said. “There’ll always be some feature that, somewhere, somebody’s got that will be complicated to transition.”

Meanwhile, market pressure could drive the migration of security products out of the kernel. If user-mode software proves to be more resilient, widely used publications like the National Institute of Standards and Technology’s Cybersecurity Framework could begin recommending that organizations use such software. Insurers might even offer lower premiums to customers that use those products, especially if they determine that user-mode software lowers the risk of business interruptions that could generate claims.

The most likely outcome, Anscombe said, is a hybrid world, in which some software continues to run in the kernel while other programs run in user mode.

Some products might even run in both modes simultaneously, with developers testing and implementing simpler user-mode migrations before tackling the harder components of their code.

“They can coexist in the same technology,” Anscombe said. “In fact, in theory, they already do.”

IBM will spend $5 billion to help find and fix vulnerabilities in open-source software packages used throughout the business world, the company announced earlier this year.

Through Project Lightwell, IBM will create “a trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale,” using AI to validate and test the patches before deployment, the company said. Businesses will be able to subscribe to the patching program for automated deployment of fixes that integrates with their existing life cycle management processes.

“Open source is the backbone of today’s digital economy and the foundation of modern AI, and we are at an inflection point in how it is built, secured, and scaled,” IBM CEO Arvind Krishna said in a statement. “This is about strengthening trust in the systems that power business, government, and society.”

IBM has already been testing the program with major financial institutions including Bank of America, Goldman Sachs, JPMorgan Chase, Mastercard and Visa. The software giant said the lessons it learned from the test phase will inform “how vulnerabilities are identified, validated, and remediated at scale across complex software supply chains.”

Project Lightwell’s clearinghouse will provide a secure environment for businesses to discuss security issues with open-source code, increasing the speed with which open-source maintainers learn about problems while preventing threat actors from exploiting them.

Hackers have increasingly targeted open-source software as its importance to the global technology stack has become more apparent. That exploitation activity has highlighted the weaknesses of the open-source ecosystem, in which mostly volunteer developers struggle to keep up with vulnerability reports — a problem that AI-powered vulnerability discovery has dramatically exacerbated.

The new project from IBM, one of the world’s largest users of open-source code, comes four years after technology giants agreed on a multi-year plan to increase their investments in open-source security. In March 2026, the leading AI companies announced $12.5 million in funding to help offset the challenges that their products have created for open-source maintainers.

The Trump administration on July 14, 2026 announced the launch of a program that will coordinate the security community’s use of frontier AI models to rapidly identify and fix vulnerabilities.

The vulnerability management clearinghouse, which the administration is calling Gold Eagle, is a response to the skyrocketing number of vulnerabilities that AI models are finding and the strain that that surge is placing on the security community. Through the clearinghouse, the government will coordinate efforts by private companies and independent researchers to scan critical software packages for flaws, fix any flaws that surface and deploy those fixes to end users.

With so many security experts looking for software vulnerabilities, the government is trying to marshal their expertise — and the capabilities of the frontier AI models that many of them are using — in a harmonized way. The goal is to deploy the nation’s vulnerability hunters and their AI tools across the widest possible range of software, rather than see some of them duplicate their efforts by focusing on the same software, squandering precious time and resources in the arms race against cybercriminals and nation-state adversaries.

Gold Eagle “has already begun to intake and prioritize identified cybersecurity vulnerabilities from across industries and sectors, coordinate scanning verifications, and ultimately ensure the security of our nation’s software and networks,” the White House said in a statement.

The core of the Gold Eagle program is the Vulnerability Information and Coordination Environment (VINCE), which the government is operating in partnership with Carnegie Mellon University’s Software Engineering Institute. The VINCE platform will allow anyone to report vulnerabilities to the Gold Eagle program for triage and mitigation.

VINCE will enable “vulnerability and patching coordination at a speed and scale never seen before,” National Cyber Director Sean Cairncross told reporters during a briefing.

Gold Eagle will focus heavily on open-source software, whose code underpins a wide range of critical infrastructure but is often poorly scrutinized. Open-source developers, many of whom volunteer their time to maintain their projects, say they have been overwhelmed by a tidal wave of AI-generated bug reports, some of which are startlingly accurate.

Open-source developers “are important partners” in the Gold Eagle program, Cairncross said, describing their code as essential to American life.

Redundancy, liability concerns

The White House described Gold Eagle — the creation of which President Donald Trump mandated in his June 2026 executive order on AI security — as “a coordinated system to receive and patch cyber vulnerabilities at a speed and scale never seen before,” one that “represents a new operational model for cyber defense.”

Even so, Gold Eagle arrives at a time when the private sector has already created several similar programs. The Linux Foundation, with support from Anthropic, Microsoft and other leading tech companies, has created a program called Akrites to boost the open-source community’s identification and handling of vulnerabilities. And the open-source security vendor Chainguard has partnered with Cisco, Cloudflare, JPMorgan Chase and other major businesses to launch Athena, another vulnerability coordination system focused on open-source software.

Those two industry-led programs involve frontier AI firms and participants in Anthropic’s Project Glasswing and OpenAI’s Daybreak coalitions. The Trump administration has not identified the companies participating in the Gold Eagle program, including which AI firms are contributing their resources to the effort. (Anthropic has said that it would participate in the government-led clearinghouse.)

One potential obstacle already looms large over Gold Eagle: Its system of exchanging vulnerability information relies on the liability protections of the Cybersecurity Information Sharing Act, which Congress in February temporarily reauthorized through the end of September. The Trump administration has called on lawmakers to reauthorize the program for 10 years, saying its protections are essential to a robust cybersecurity collaboration ecosystem.

While the world alternates between panicking and fawning over Anthropic’s powerful new AI model Claude Mythos and its ability to discover serious software vulnerabilities, open-source AI systems are already revolutionizing the vulnerability-hunting landscape — at a far lower cost.

These increasingly sophisticated open-source tools are the product of the Defense Advanced Research Projects Agency’s (DARPA) Artificial Intelligence Cyber Challenge, a multiyear effort to spur the development of AI systems that can quickly find and fix bugs in America’s sprawling web of critical infrastructure. The vulnerability-hunting systems that emerged from DARPA’s contest didn’t get splashy launches like Claude Mythos or OpenAI’s similar new tool, but because they’re open source and much cheaper to run, they could help far more infrastructure providers, businesses and independent software developers.

With the DARPA competition in the rear-view mirror, the winning teams and other finalists are putting what they learned into practice to help secure open-source packages that quietly undergird the entire internet. While efforts to connect with critical infrastructure operators and their vendors remain nascent, DARPA and several competition winners told Cybersecurity Dive they’re thrilled with how effective the new AI tools have proven.

At a time when the U.S. cybersecurity workforce is stretched thin and adversaries are using AI to speed up their attacks, the nation’s best hope could be automated tools that find and help fix vulnerabilities before they lead to chaos.

Finding bugs everywhere

After DARPA announced its challenge’s three winners in August 2025, it created a $1.4 million bonus prize pot for competition finalists who used their AI systems to find and fix vulnerabilities in critically important software. The agency reviewed teams’ proposals to scrutinize important open-source packages and tracked how they engaged with the projects’ maintainers. Each of the seven competition finalists could earn up to $200,000, with a maximum of $10,000 per project.

By the time the paid vulnerability-hunting spree ended, the teams had found 83 vulnerabilities in more than 30 commercial and open-source projects, including Android, Linux, the popular database engine SQLite and the widely used data-storage tool Redis. Of the $1.4 million in prize money the government set aside, it awarded $830,000.

Since then, “the teams have continued to find and produce patches for additional vulnerabilities across other projects,” said Andrew Carney, the DARPA program manager who oversaw the competition and now liaises with teams in the new phase of their work.

Team Atlanta, the DARPA contest’s winner, found flaws in the U-Boot boot loader and several core Apache libraries, he said, while another finalist, 42-b3yond-6ug, identified vulnerabilities in the Linux kernel that could have let hackers cripple devices widely embedded in critical infrastructure.

Theori, the third-place team, has deployed its system, Xint, to find flaws in “all sorts of really widely used open-source projects that everyone on the internet relies on,” said Tyler Nighswander, a researcher at the company. Xint has identified vulnerabilities in the popular database tools Redis, Postgres and MariaDB, as well as Python, Linux and Apple’s XNU kernel, which powers MacOS and the iPhone.

AI has been particularly useful for finding “logic bugs” — flawed code that traditional vulnerability-assessment software wouldn’t flag as defective. As AI gets better at understanding context, “automated tools are able to push their boundaries more,” said Michael Brown, principal security engineer, at second-place team Trail of Bits.

And while finding flaws gets most of the attention, the AI systems’ ability to validate their findings and their automatically generated fixes might be their real superpower.

Critical infrastructure organizations typically run highly customized hardware and software and often struggle to test patches on their bespoke devices, if they can patch them at all. Because the vulnerability hunters had to develop patch-validation capabilities for DARPA’s competition, their latest systems contain those features.

“There’s so much power there, and there’s so much value for safety-critical, high-assurance-required systems,” Carney said. “When we do have these conversations [with infrastructure organizations], that’s where we end up spending a lot of our time.”

Critical infrastructure roadblocks

While the teams have been busy fixing core internet architecture, DARPA has also tried to connect them with the operators of critical infrastructure and the vendors who supply their equipment. Much of America’s computerized industrial machinery is old, insecure and poorly maintained, and DARPA hopes volunteer vulnerability hunters can root out major flaws before hackers exploit them.

DARPA has briefed several sector coordinating councils (SCCs) on the AI tools’ potential. Carney recently spoke at a meeting of the Health Sector Coordinating Council to share the competition teams’ progress. “Forums like that are what we're really focused on,” he said, “because they’re very efficient at getting the message out.”

The introductions that DARPA has facilitated between vulnerability hunters and critical infrastructure operators have had “varying degrees of success,” according to Nighswander, who said many organizations aren’t eager to embrace new technologies. “It's been really slow. Different sectors have different adoption cycles and uptake willingness.”

Some infrastructure firms don’t understand how the AI systems would work in their environments. Others decline AI help because they think their human security teams are sufficient. Still others are interested in AI vulnerability detection but can’t get the necessary permissions. “Trying to figure out how to cut some of that red tape would be nice,” Nighswander said, “because so far that's been the biggest limitation.”

Theori has signed vulnerability hunting agreements with “fewer than five” critical infrastructure entities, Nighswander said. “It’s been a bit difficult to convince those slower companies [and] industries to adopt this tech.”

The biggest success story so far has been Trail of Bits’ partnership with the Department of Health and Human Services to hunt for flaws in medical devices, a project that Brown said has fixed many vulnerabilities through strong partnerships with healthcare providers and their suppliers.

Because infrastructure vendors routinely use lightweight open-source packages — especially in embedded devices — the vulnerability hunters’ existing work will have significant downstream effects, even for vendors that don’t want to engage directly.

“That’s been a way of providing value and then jump-starting those conversations with the industry-specific or sector-specific companies and entities,” Carney said.

Busting Mythos

When Anthropic announced Claude Mythos Preview and said it was too dangerous to release publicly, prompting shock and alarm across the business community, the former DARPA competitors mostly just shrugged.

“It’s very cool,” Nighswander said, but “this is the world that we’ve been living in for a while now.”

Still, the new publicity surrounding AI vulnerability detection could benefit the teams behind the open-source systems. “It leads people to find out that, ‘Oh, this is a thing that my company should be worried about,’” Nighswander said.

The DARPA contest finalists even have an advantage over OpenAI and Anthropic, because their open-source tools are far cheaper than the big AI companies’ products, which can cost tens of thousands of dollars in access tokens.

Using Claude for vulnerability hunting is “kind of like showing up to a fancy restaurant with no prices on the menu,” said Trent Brunson, Trail of Bits’ director of research and development. “You know you have a large code base. You don’t know what bugs you have. … Companies might spend $50,000, $75,000 on tokens and not even realize it, and then they might come up with very low-information bugs.”

Cash-strapped critical infrastructure firms might pass over OpenAI and Anthropic’s tools in favor of the DARPA finalists’ much cheaper but similarly effective services. “More companies are going to look at the bottom line,” Brunson said, “rather than just throw AI tokens at it.”

Beyond the competition

As they’ve left the DARPA competition behind, Theori, Trail of Bits and their peers have taken different approaches to implementing their own AI systems.

Theori is working with open-source package maintainers, but it has also commercialized Xint and is contracting with businesses to evaluate their products. “We’ve been running that quite successfully so far,” Nighswander said. Trail of Bits, by contrast, is focusing mostly on open-source packages. Commercializing its tool, Buttercup, would “fundamentally” change the company, Brunson said.

The vulnerability hunters have had to modify their AI systems as they’ve moved out of the competition environment. The tools need to be able to find real vulnerabilities, not the “synthetic” flaws that DARPA created for the challenge. They need to produce reports that humans can easily read, not just data to feed into a scoring algorithm. And they need to be able to evaluate a wider range of inputs than what the heavily structured competition required.

Trail of Bits built an entirely new system for its work analyzing medical devices’ firmware, which is typically written in binary, unlike software, which involves source code. Binary code is the main way embedded devices communicate, but AI has a hard time processing it because it doesn’t look like natural language the way source code does. Once that problem is solved, Brunson said, “the world’s our oyster.”

AI’s true sea change

DARPA, the competition finalists and cybersecurity experts said it’s almost impossible to overstate how much AI will change the process of finding vulnerabilities.

Software security assessments that used to take multiple people six months can now be done by AI in a matter of hours, often with better results, Nighswander said. “That scale and efficiency is incredible.”

The technology is obviously a double-edged sword. Nick Reese, the former director of emerging technology policy at the Department of Homeland Security, said the same tools that “present a significant opportunity for security professionals” also create “a potential advantage for attackers if they get access to the same data.”

But DARPA views things optimistically. It took years for the self-driving cars that emerged from DARPA’s first challenge in 2004 to hit the market; with the AI bug-fixing competition, Carney said, the agency never thought it’d see “a technical miracle” that was “economically feasible at the same time.”

“I’m extraordinarily excited,” Carney said, “at the performance and impact that the technology continues to have.”