Open source maintainers are increasingly frustrated by a surge of low-quality, AI-generated security reports, which are often described as 'slop'. Seth Larson, a security report triage worker, recently shed light on this troubling trend, emphasizing that these reports not only waste valuable time but also contribute to the burnout of maintainers striving to keep their projects secure.

In a revealing blog post, Larson stated, “I’ve noticed an uptick in extremely low-quality, spammy, and LLM-hallucinated security reports. In the era of Large Language Models (LLMs), these reports can easily be mistaken for legitimate concerns, requiring maintainers to expend effort in refuting them.”

The challenge is compounded by the decentralized nature of open source projects, which are scattered across numerous platforms. Larson pointed out that due to the sensitive nature of security reports, maintainers often feel discouraged from discussing their struggles publicly or seeking assistance.

To tackle this growing problem, Larson advocates for changes that would empower platforms to mitigate the automated or abusive generation of security reports. He suggests systems that would allow reports to be made public without attaching a specific vulnerability record, giving maintainers the facility to 'name and shame' offenders without compromising their own security protocols. This initiative would enhance accountability and discourage the creation of misleading reports.

Moreover, he calls for platforms to anonymize reports from abusive users and eliminate any positive incentives for submitting such security issues. He also emphasizes limiting the ability of newly registered users to submit reports until they have demonstrated good practices.

In a strong message to security reporters, Larson implores them to refrain from using LLM systems for vulnerability assessments, advising instead that all reports should be vetted by a human before being submitted. “Don’t spam projects with unfounded claims,” he adds, “come prepared with patches instead of just complaints.”

Larson also proposes a strategy for maintainers dealing with these low-quality reports. He encourages them to treat such reports as though they are malicious, advising, “Put the same amount of effort into responding as the reporter did in submitting a sloppy report: essentially, near zero.” When encountering suspicious reports, he recommends a simple response: “I suspect this report is AI-generated/incorrect/spam. Please respond with more justification for this report.”

This sentiment is echoed by other open source maintainers facing similar hurdles. Daniel Stenberg, who oversees the Curl project, voiced his concerns that while poor-quality reports have always existed, advancements in AI technology have made these reports appear more credible. “When reports are made to look better, it requires more time to investigate and eventually discard them,” Stenberg remarked. “Every security report demands that a human dedicates time to assess its validity, which detracts from valuable development time.”

The call for change is clear: as AI continues to permeate the development landscape, the necessity for responsible reporting practices has never been more critical. The struggle against these so-called 'slop security reports' is not just an inconvenience—it's a fight for the future sustainability and integrity of open source projects. Will platforms rise to the challenge and implement measures to safeguard developers’ time and efforts? Only time will tell, but the pressure is mounting.