AI Slop Is Drowning the Maintainers You Depend On

Q: How are AI-generated contributions hurting open-source maintainers?

By collapsing the cost of producing a submission while leaving the cost of evaluating one unchanged — and in fact raising it. Open-source inboxes have always contained noise, but low-effort noise was cheap to dismiss: a poorly written, obviously wrong bug report costs a maintainer about ten seconds. What AI assistants changed is that noise is now fluent. A fabricated vulnerability report can arrive well-structured, confidently argued, technically plausible, and completely wrong, and disproving it takes a maintainer twenty minutes of careful reading and testing. Crucially they must do that work, because the report they dismiss carelessly might be the real one. So the asymmetry is severe: generation is nearly free and effectively unlimited, refutation is expensive and bounded by unpaid volunteer hours. The clearest public marker came in January 2026 when curl shut down its bug bounty programme, with the maintainer reporting that AI-generated submissions had driven the genuine vulnerability rate from above 15% down below 5% — for a library that runs in effectively every connected device. That is not a project with weak processes; it is one of the best-run projects in the ecosystem, and the economics of triage still stopped working. The knock-on effects are what should concern the organisations consuming these packages: maintainers facing unreviewable volume close reporting channels, slow their response times, merge with less scrutiny under backlog pressure, or burn out and hand the project to whoever volunteers. Every one of those outcomes degrades the upstream review capacity that enterprise dependency-risk models quietly assume is reliable and free.

Q: Why is this a business risk and not just an open-source community problem?

Because your security posture contains an unwritten assumption that a competent human upstream is reading the pull requests for the libraries you ship, and that assumption is a control you never paid for, never documented, and cannot audit. Trace it through. Your application depends on direct packages, which depend on transitive packages, several layers deep — and the deeper layers are disproportionately small projects maintained by one or two volunteers. When you decide a dependency is acceptable, you are implicitly relying on those maintainers to review contributions, catch malicious pull requests, respond to vulnerability reports, and not hand the project to a stranger. None of that appears in your risk register, and none of it is something you have contracted for. As upstream review capacity thins, several concrete risks rise. Malicious contributions are more likely to be merged by a maintainer working through a large backlog. Genuine vulnerabilities take longer to be triaged and fixed, extending your window of exposure. Projects go dormant or change hands, and unvetted maintainer handover is a documented supply-chain attack pattern — several notable compromises began exactly that way, with a burned-out maintainer accepting help from an attacker who had spent months building credibility. And the timing is unfortunate: this degradation is happening while attackers are industrialising supply-chain campaigns, so defensive capacity is falling as offensive volume rises. The practical implication is that "no known CVEs" is a much weaker assurance than it used to be, because vulnerability scanners report disclosed problems in current versions and cannot see a project whose review quality quietly degraded six months ago.

Q: How do I assess the maintenance health of my dependencies?

Inventory it explicitly, because almost no organisation can currently answer the basic question of which dependencies are maintained by one person and which of those sit in a critical path. The signals worth collecting per package: number of active maintainers (one is a bus-factor risk regardless of how good they are), release cadence and whether it has changed, time-to-response on issues and security reports, whether the project uses code review and branch protection on its own repository, how recently the last meaningful commit landed, and whether ownership has changed hands. OpenSSF Scorecard automates a large portion of this — it evaluates projects against a set of security-practice checks and produces a comparable score, which is far more useful than reading GitHub pages manually across hundreds of dependencies. Run it across your full tree rather than only direct dependencies, because the thin projects are usually transitive and the famous packages are usually fine. Then weight by criticality: a single-maintainer library in your authentication path is a materially different risk from the same library in a build-time formatting tool, and treating them identically wastes attention. The output is a risk register grounded in the actual state of your supply chain rather than in the assumption that upstream is handling it. Two additions make it operational rather than a one-time exercise. Monitor for maintainer-transition and dormancy-burst events on your critical dependencies — ownership changes and sudden release activity after long quiet periods are the highest-value signals in this space, and they are precisely what CVE scanners cannot surface because nothing is vulnerable yet. And re-run the inventory on a schedule, since maintenance health is a moving property and the whole point is that it is currently moving in one direction.

Q: What practical controls reduce dependency risk from thinning upstream review?

Four, and they move assurance you were implicitly outsourcing back inside your own boundary. Control the upgrade path: enforce lockfiles with hashes and reproducible installs so builds cannot silently resolve to something new, and adopt a deliberate soak period on non-security releases — waiting several days before taking a new version lets ecosystem-wide problems surface before they reach you, at almost no cost. Split that from security patches, which you want to take quickly; conflating the two is why teams either take everything instantly or fall dangerously behind. Monitor transitions: watch for ownership changes, package transfers, and bursts of releases after dormancy on your critical dependencies, because those correlate with both burnout outcomes and deliberate takeovers, and virtually nobody monitors them. Reduce the surface: the cheapest available risk reduction is depending on fewer things, and a dependency that saves twenty lines of code is not worth a permanent third-party trust relationship plus its entire transitive tree — audit which dependencies actually earn their cost, and prefer well-maintained widely-used libraries over the perfect-fit package with one contributor. Invest in what is load-bearing: for the handful of projects your revenue genuinely depends on, funding maintenance or assigning an engineer to do triage and write tests is risk management with a clear return, not philanthropy, and unglamorous contributed labour is often more valuable to a project than money. Underpinning all four: stop treating upstream review as a free control. Once it is written down as an assumption, it becomes something you can measure, monitor, and decide how much to rely on — which is the actual shift.

Q: Should companies fund the open-source projects they depend on?

For the small number that are genuinely load-bearing, yes — and the framing that makes it happen is risk management rather than charity, because framed as charity it loses every budget argument and framed as risk it wins most of them. The argument is straightforward. You already depend on the project; its failure or compromise is your incident. The cost of a modest maintenance contribution is small and predictable, while the cost of a compromised or abandoned critical dependency is large and unpredictable. That is an ordinary risk-transfer calculation, and it compares favourably against most security spend. What matters is being selective and specific. Do not spread small amounts across every dependency — identify the handful where a failure would genuinely hurt, which for most organisations is a surprisingly short list, and support those meaningfully. And consider what the project actually needs, because money is not always the binding constraint. For many maintainers the scarce resource is trusted review capacity, so assigning an engineer for a few hours a week to triage issues, reproduce reported bugs, and write regression tests can be worth more than a sponsorship, while also giving your team genuine visibility into a dependency you rely on. There is a directly related obligation worth adopting alongside it: do not send AI-generated pull requests or vulnerability reports upstream without a human who has verified them and will stand behind them. Contributing to the flood that is drowning the maintainers you depend on, while complaining about the consequences, is the least defensible posture available — and it accelerates precisely the failure mode that will eventually cost you.

Q: What can maintainers do about the flood of AI-generated submissions?

Adopt automated gates that submitters must pass before a human ever looks — the same verification-pyramid logic that teams use for AI-generated code, applied to inbound contributions. The core insight is that the problem is not volume as such, it is that plausible noise now requires human attention to identify. So the goal is to make claims machine-checkable and let machines check them. The single highest-leverage filter is requiring a working reproduction: a bug report must include steps that actually execute, and ideally a failing test that demonstrates the claim, with CI green on the submission. Fabricated reports rarely survive contact with a real test harness, and the requirement costs a genuine reporter little while costing a fabricator everything. Related gates: require that pull requests pass the full test suite and linting before review, require contributors to state whether AI assistance was used and to confirm they have verified the change themselves, and for security reports require a proof of concept rather than a description of a theoretical vulnerability. Beyond gating, structural options that projects are adopting: staged trust, where first-time contributors face stricter requirements than known ones; scoping reporting channels so the low-signal ones can be closed without closing everything (as curl did by ending its bounty while keeping its disclosure process); and being explicit in contribution guidelines that unverified AI-generated submissions will be closed without detailed response, which both sets expectations and removes the obligation to write a careful refutation of every fabrication. The OpenSSF ecosystem is building tooling in this direction. The projects that adopt gates early tend to keep their channels open; the ones that rely on human triage alone eventually find the economics force them closed, which is worse for everyone downstream.

Q: Do vulnerability scanners catch this category of risk?

No, and the gap is structural rather than a matter of scanner quality. Vulnerability scanners work by comparing the packages and versions in your dependency tree against databases of disclosed vulnerabilities. That is genuinely valuable and you should absolutely run them — but notice what it requires: a problem must already have been found by someone, reported, triaged, confirmed, and published as an advisory before a scanner can tell you about it. Every step in that chain depends on upstream human capacity, which is precisely the thing that is degrading. So the scanner is reporting on the output of a process whose throughput is falling, and a clean scan increasingly means "nothing has been disclosed" rather than "nothing is wrong." Several concrete risks are invisible to this model. A project whose maintainer stopped reviewing pull requests carefully six months ago has no CVE, and will not until something is found. A package that changed ownership last month to an unvetted new maintainer scans perfectly clean. A library that is functionally abandoned — still resolving, still installing, no longer maintained — looks identical to a healthy one. A malicious contribution merged into a low-traffic dependency may sit undisclosed for a long time precisely because nobody is looking. What fills the gap is maintenance-health signals rather than vulnerability signals: maintainer count, review practices, release cadence, response times, ownership-transition events, and dormancy patterns — the things OpenSSF Scorecard and transition monitoring surface. The right mental model is two complementary programmes: vulnerability scanning tells you about known problems in what you have, and maintenance-health monitoring tells you about the probability of future problems and the speed at which they will be caught. Most organisations run the first and would describe themselves as having a mature dependency-security programme, which is exactly the gap.

Q: Is open source becoming too risky to depend on?

No — and the conclusion to avoid is the reactive one where an organisation decides to reduce open-source usage, because that trade is almost always worse. The alternative to depending on well-maintained open source is depending on closed-source vendors, whose review practices you cannot inspect at all, or building it yourself, which means maintaining it forever with a team that has less domain expertise than the project you rejected. Open source remains the best-audited software most organisations run, precisely because the code is public and many eyes can look. What is changing is narrower and worth stating precisely: one specific control — upstream volunteer review capacity — is under pressure, and organisations that treated it as free and unlimited need to stop. That is an adjustment to a risk model, not an indictment of the model. The right response is proportionate: know which of your dependencies rest on thin maintenance and which of those are critical, control your upgrade path so you are not taking every release the instant it lands, monitor for the ownership-transition events that scanners cannot see, keep the dependency surface smaller than it has drifted to, and support the handful of projects your business genuinely rests on. That is a modest programme, most of it automatable, and it puts your assurance on a footing you control rather than on an assumption about volunteers you have never met. There is also a constructive angle worth taking seriously: the organisations that fund and staff maintenance for their critical dependencies are both reducing their own risk and addressing the underlying capacity problem, which is one of the rare cases where self-interest and ecosystem health point in exactly the same direction.

Satyam Kumar

Back to Blog

ai-architecture

The Libraries You Depend On Are Drowning in AI Slop — and Your Risk Model Assumes They Aren't

By Satyam KumarJuly 28, 202610 min read

open source maintainer burnout dependency risk supply chain security software supply chain openssf scorecard curl vulnerability triage ai generated contributions oss sustainability third party risk dependency management devsecops engineering leadership risk architecture 2026

The Libraries You Depend On Are Drowning in AI Slop — and Your Risk Model Assumes They Aren't

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

The Libraries You Depend On Are Drowning in AI Slop — and Your Risk Model Assumes They Aren't

Frequently Asked Questions

Share this article

Comments

Leave a comment