Key facts at a glance

• AI coding tools are making open source software harder to maintain and secure because they generate code and identify flaws faster than volunteer or thinly funded maintainers can review them.
• Open source code is embedded in phones, cars, cloud systems and AI platforms. One cited estimate suggests firms would spend 3.5 times more on software without it.
• Most projects accept outside contributions, but a vetted group of trusted contributors decides what is committed. AI makes submitting code easy, and some of it is poor quality.
• Attackers are planting malicious packages and code in popular repositories. A flaw in widely shared code can have outsized impact.
• An automated security agent contributed 72 security fixes to open source projects between April and October 2025, including some affecting as many as 4.5 million lines of code.
• Funding is highly uneven. One major foundation reported $292,217,236 in 2024, while another major foundation reported $2,379,402, less than 1 percent of that amount.
• Most open source applications do not generate or ship a software bill of materials, or SBOM, despite US and EU mandates.

The hidden dependency layer

Open source software is no longer a niche concern for developers who prefer permissive licenses. It is the quiet infrastructure beneath modern life. The same libraries and components appear inside phones, cars, cloud systems and artificial intelligence platforms. A single flaw in a widely used package can ripple through products that never advertise their open source roots. That reach explains why the review burden on maintainers is not merely an internal engineering problem. It is a software supply chain problem that touches every organization running digital services.

The economics of that supply chain are unusual. A cited estimate in a business school paper found that firms would spend 3.5 times more on software without open source. The savings are real, but they are often invisible because no invoice is attached. The benefit flows to a vast range of users, while the cost of maintenance falls on a much smaller group. That mismatch is at the center of the new warning from authors writing for a computing policy council. They argue that AI coding tools are adding to the review load on open source projects, many of which are thinly funded and already stretched.

More code for humans to check

Most open source projects accept outside contributions, and they typically keep a vetted group of trusted contributors who decide what gets committed. That gatekeeping function is what turns a public repository into a reliable dependency. AI has made writing and submitting code easy. A contributor can now generate a patch, a feature or a security fix in minutes, then send it upstream. Some of what arrives is useful. Some of it is poor. Some of it may be generated with little understanding of the project's design, compatibility promises or long-term maintenance needs.

The authors allow that quality may improve as models do. But even if every AI-generated contribution were technically sound, a human still has to assess the added volume. Reviewing code is not a passive act. It requires understanding intent, checking edge cases, testing interactions and deciding whether a change fits the project's roadmap. AI can produce more output than a maintainer can absorb. The bottleneck is not the ability to write code but the ability to trust it.

That bottleneck has a security dimension. A rushed review can miss a subtle backdoor, a dependency confusion trick or a logic flaw. A delayed review can leave a known bug unfixed. Maintainers face pressure from both directions. They are asked to move faster on fixes while being handed more submissions to inspect. The result is a growing queue that no amount of automated linting fully resolves.

Faster fixes, faster attacks

So much of the world runs the same code that a flaw found in it can have outsized impact. A vulnerability in a popular library can affect thousands of applications at once. Attackers understand this. A growing number plant malicious packages and code in popular repositories, hoping that trust in the ecosystem will carry their payload into production systems.

AI cuts both ways. Models that find and patch flaws can also be used to build attacks. An automated agent can scan code, identify weaknesses and propose fixes at a speed that human teams cannot match. The same capability can help an attacker locate exploitable patterns, generate obfuscated payloads or sort through open source dependencies for weak points. The authors doubt that restricting top security models to trusted users will help, because general-purpose models keep getting stronger. The defensive advantage of any single restricted tool is likely to erode.

There is also a patching problem. AI-found flaws push organizations to patch sooner. That is hard for applications built from many open source components, because every one of those components needs its own patch and re-release, in sequence. A fix in one library may require updates in three others before the application can be rebuilt and redeployed. The coordination cost can be enormous, especially for organizations that do not maintain a clear inventory of what they run.

The money is lopsided

Funding across open source is not distributed according to dependency. Some projects sit at the center of global infrastructure and receive substantial support. Others are equally critical but survive on volunteer labor and small sponsorships. The disparity is stark. One major foundation brought in $292,217,236 in 2024. Another major foundation, often cited as an example of projects that run on volunteer labor and sponsorships, brought in $2,379,402. That is less than 1 percent of the larger figure.

Across open source, most users never pay. This is the free-rider problem in its purest form. Companies build commercial products on top of code they did not write, do not fund and often do not audit. When maintenance is deferred, the consequences may not appear until years later. A project can be abandoned quietly, its issue tracker filling with unanswered questions, while downstream products continue to ship. The security holes created by that neglect are then inherited by everyone who depends on the project, often without their knowledge.

AI may make the imbalance worse. If models lower the cost of producing code, they also lower the cost of producing low-quality contributions. Maintainers then spend more time triaging and rejecting work. That time is unpaid or underpaid. The projects with the least funding may face the greatest increase in review load, because they are popular enough to attract submissions but not wealthy enough to hire reviewers.

You may not know what you run

A software bill of materials, or SBOM, is a machine-readable list of the components inside an application. It is meant to give organizations visibility into their dependencies so they can respond quickly when a vulnerability is announced. Despite US and EU mandates, the vast majority of open source applications do not generate or ship one. That gap leaves many users blind to the exact versions and packages running in their systems.

Even a complete SBOM has limits. It would show what is present, not whether each piece is maintained, funded, secure or abandoned. A component can appear in the list with a clean version number and still be a liability if no one is reviewing its code. An SBOM is a map, not a guarantee. It tells an organization where to look, but it does not tell the organization whether anyone is home.

The governance challenge is therefore deeper than inventory. Organizations need to understand the health of their dependencies. They need to know which projects have active maintainers, which have secure release processes, which have funding and which are one resignation away from stalling. That kind of assessment is difficult to automate because it depends on social and organizational facts as much as technical ones.

Governance project by project

Open source is governed project by project, so ecosystem-wide numbers on AI's effects are hard to collect. There is no central authority that can measure how many maintainers are overwhelmed, how many contributions are AI-generated or how many critical projects lack a second reviewer. The data is fragmented because the governance is fragmented. Each project has its own norms, tools, contributor agreements and release cadence.

The authors want projects to put more resources into documentation, packaging, fundraising and gathering requirements. These are not glamorous tasks, but they determine whether a project can absorb new contributors and new code without losing coherence. Deciding what a project needs and getting its community to agree still falls to people. AI can draft documentation or suggest packaging improvements, but it cannot build consensus or take responsibility for a release.

For institutions, the challenge is even broader. Most face perhaps their largest task in learning the governance, maintenance and security state of their software. They need to spot critical dependencies before something fails, not after an incident. That means asking uncomfortable questions about projects they did not create and may not fund. It means treating open source as infrastructure rather than a free resource.

The review load created by AI is therefore not just a maintainer problem. It is a risk management problem for every organization that depends on open source. The tools that generate code and find flaws are becoming more capable. The human systems that validate, fund and govern that code are not keeping pace. The largest challenge for many institutions is learning the governance, maintenance and security state of their software so they can spot critical dependencies before something fails.

Source:Help Net Security News