AI is changing how software vulnerabilities are discovered and how quickly they are reported. For community-led open source projects, this shift is both promising and deeply challenging.

At the OpenJS Foundation, we steward some of the most widely used JavaScript infrastructure in the world. Projects like Node.js power software used everywhere from NASA to Netflix, from core developer tooling to critical online services. Despite their scale and importance, these projects are largely built and maintained by volunteers.

AI has lowered the barrier to generating security reports, but not the cost of handling them.

If your company depends on OpenJS-hosted projects, this isn’t an abstract problem. AI-driven security noise is increasing risk across the software supply chain, and the only sustainable response is shared investment in the projects we all rely on.

More Reports, Same Maintainers

In recent months, security teams across the ecosystem have seen a surge in AI-assisted vulnerability submissions. Some surface real issues faster. Many do not.

The impact is already visible: Node.js typically receives six to seven vulnerability reports per month, but between December 15 and January 15 received over 30 – compared to just three during the same period the previous year – highlighting the rapid rise of AI-assisted submissions and the resulting strain on maintainer capacity.

Similar pressures have been reported by the cURL project, which has shared how AI-generated vulnerability reports are overwhelming maintainers and diverting time away from fixing real issues.

Every report, good or bad, still requires human judgment to assess real impact and coordinate a responsible response. For community-led projects, that work directly competes with other essential responsibilities like releases, testing, and keeping infrastructure running.

Volunteer availability does not scale with report volume. And when security triage overwhelms maintainers, the entire project slows down.

To protect both maintainers and users, projects are introducing clearer guardrails. For example, Node.js recently reaffirmed HackerOne as its primary vulnerability reporting channel and added a Signal score requirement to reduce low-quality, AI-assisted submissions, while still providing a supported path via the OpenJS Foundation Slack for early clarification, ensuring real vulnerabilities get real attention without overloading volunteer maintainers.

The Ripple Effect Across Enterprises

Security noise doesn’t stop at the project boundary.

When a vulnerability is reported in a widely used open source project that many companies build their software on, automated security tools can trigger alerts across large organizations. Even when the real risk is low, teams may feel forced into rushed fixes or upgrades because so much of their software depends on that project.

This creates a cascade:

• Maintainers absorb pressure to respond quickly
• Enterprise teams experience disruption and rework
• Security teams on both sides spend time resolving false urgency
• Long-term risk increases as fatigue sets in

Ironically, unchecked AI-driven reporting can make the supply chain less secure by draining the very capacity needed to respond well.

AI Changed the Threat Landscape. Responsibility Must Catch Up

AI has changed how vulnerabilities are discovered and reported, but it hasn’t changed who is responsible for sustaining open source projects. Community-led projects are not commercial support teams, and maintainers are not on-call for the world’s automated scanners.

Projects like Node.js are widely trusted precisely because they are open and community governed. But that also means they rely on shared investment, not service-level agreements. As reporting volume increases, especially through AI-assisted tools, the gap between expectations and available capacity becomes a real security risk.

Closing that gap requires participation from the companies that depend on this software—not more pressure on volunteers.

Key sustainability challenges remain constant:

• Security triage and incident response require sustained effort
• Testing infrastructure and CI stability are essential to preventing regressions and vulnerabilities
• Healthy contributor pipelines don’t maintain themselves
• Burnout and maintainer churn are real security risks

When projects can fund dedicated security roles – people focused on handling vulnerability reports, managing fixes, and keeping releases safe – the impact is immediate and measurable. At OpenJS, targeted investments from initiatives like Alpha-Omega and the German government’s Sovereign Tech Agency have allowed us to meaningfully strengthen security across our projects.

This is the difference between reactive survival and proactive stewardship.

What Developers Can Do to Reduce AI Slop

AI is here to stay. The question is how responsibly it is used.

Reducing “AI slop” in open source security means:

• Actively reviewing and validating AI output to confirm there is a real vulnerability, not just a plausible one
• Evaluating findings against the project’s threat model, not generic vulnerability patterns
• Submitting reports with clear reproduction steps and meaningful impact context
• Avoiding speculative or copy-paste findings without verification
• Respecting project processes and maintainer time

Maintainers are not an extension of automated scanners. They are caretakers of shared infrastructure and their time is finite.

A Call to Action

If your company depends on OpenJS-hosted projects, security is a shared responsibility.

AI-driven noise is increasing the burden on volunteer maintainers and raising risk across the supply chain. The most effective way to reduce that risk is to invest upstream.

Join the OpenJS Foundation. Fund the projects you rely on. Contribute engineer time where it matters. 

That’s how we reduce AI slop, improve security signal, and keep critical JavaScript infrastructure healthy for everyone.