LLM-wielding students seem to be a new "attack vector" in this and many other repos

[nickchomey]

It is abundantly clear to me that this repo (and seemingly many others) are being spammed by LLM-wielding students who are eager to put something on their CV.

There's been some seemingly helpful PR that make small (eg http->https) changes, but there's a lot of very concerning stuff going on that I dont think the maintainers are at all aware of yet.

#1927 is the most egregious example of this, but #1937 is completely of this nature, I opened #1936 but the only two responses I got were clearly like this as well. Even after I rejected the terrible proposal there, they went ahead and submitted a PR (#1949) anyway, which @jmanico started treating seriously. I've noticed other maintainers (eg @szh in #1937) doing the same.

You created an AI-disclosure policy and PR template (which only seems to be sporadically used), but there's clearly nothing stopping these people from flouting it all. Moreover, even if they say they "manually reviewed" the AI output, what value does that have when they are self-interested ESL students with limited knowledge/experience?

Given that this is a premier source of security guidance, it seems like it would be prudent for your team to give serious thought towards how to be significantly more vigilant going-forward with guarding against this issue.

edit: To be clear. I say this all with significant gratitude for the work you have done. It is an alert and call to action, rather than any sort of castigation. I dont really know what can be done about it, but I am sure that all of open source is suffering from the same problem.

Ghostty terminal seems to have a comprehensive approach to all of this: https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md

They dont even allow anyone to open issues (and presumably PRs must stem from an approaved issue) - you have to start a discussion first.

I hope this helps

[szh]

Agreed. I for one have been trying not to be too heavy handed or confrontational in order not to turn away potential new open source contributors but I acknowledge that this tendency has serious downsides.
Do you have ideas for how we can improve processes to handle this new onslaught - without throwing out any and all AI usage?

[nickchomey]

I just ninja-edited the OP at the same time you posted - i added a link to Ghostty terminal's contribution guidelines. It talks a lot about AI, but also they dont even let people open Issues. You have to start a discussion first, and then issues graduate from there (and presumably PRs must have a pre-approved tracking issue).

A lot of overhead, but it might be less work overall - especially since running the guantlet would probably largely deter these people altogether. People who genuinely care (eg how I and others did about the Sec-Fetch CSRF guidance) would be happy to go through the motions.

[szh]

Thank you. We'll have to take a look. It's a hard balance, trying to be open to contributors (which is our lifeblood), while not allowing the flood of low quality slop.

[mackowski]

Thanks @nickchomey for referencing Ghostty terminal's contribution guidelines they looks solid.

Also I think we can stop PR without assigned issue — it is much simpler to review issue than PR.

[nickchomey]

Yeah that seems like an easy first step to improve things. The common pattern I've seen from these student spammers across repos is look at issues, post some Ai slop about "this is a crucial issue that I see come up all the time, please assign this to me and I will do 5 vague bullet points" and then often submit a PR regardless of response.

If PRs are explicitly prevented/closed without some initial meaningful discussion and explicit approval for PR (eg what happened with the sec fetch csrf guidance, and surely lots of other places), it'll surely cut back the noise.

Though, I still think that there will be a ton of slop in issues, as evidenced by the few that I linked above (and were thankfully closed).

The discussion-> issue->PR gauntlet might be sufficiently onerous to discourage low effort sloppers, while not being a problem for people who care.

[jmanico]

What I suggest is that we do not force a formal process or template on contributors. We should accept contributions in whatever form folks can provide, and then politely work with them to get it into shape. When someone is far off-base, we can point them to our contribution guidelines. More than once if needed.

Recently we’ve also seen a rash of low-effort AI-generated submissions. In the last few days we’ve been more aggressive about closing issues that are in the "AI Slop" category. I think we should keep this up, to protect the time of leadership.

Here’s the behavior I’m proposing (and I am open to other suggestions):

1. Be kind and respectful to all contributors. Avoid inflammatory or accusatory language. This is open source, and we should model that. ABN: Always Be Nice.
2. When a contribution is off-base, guide folks to our contribution guidelines and help them course-correct kindly.
3. Be quicker to close unactionable / low-effort submissions so they don’t consume maintainer time. Close them promptly, and do it politely. Or give folks a deadline when the content is on the border like "fix this in 2 weeks or we politely close it out".

This is just my 2 cents. I know your time is valuable as leads for contributions and I want to respect it. I’m hoping that being quicker to close non-actionable items addresses some of your concerns.

[kwwall]

One thing that I don't think that has been discussed sufficiently is, when creating an PR, you have a template for that that asks if AI was used and if they answer "yes", you ask form some important meta-data such as AI model & version, and the prompt(s) they use that is mentioned at https://github.com/OWASP/CheatSheetSeries/blob/master/.github/pull_request_template.md?plain=1#L22-L29. But my concern is, if over the longer term where it may result in a history for where multiple contributors have made updates using AI as an assistant, we could easily lose track of what AI prompts lead to which specific AI-generated text in the cheat sheet. For simple stuff, you can track it via 'git blame' along with the commit history, but that is somewhat of a PITA (been there, done that during code reviews). If a given Cheat Sheet gets large and it gets split into multiple cheat sheets, then tracking all this becomes even harder. So, I'm thinking that perhaps if someone admits they've used an AI tool in the PR submission, maybe we should instead strive to store the this AI meta-data, including the AI prompt itself, closer to the actually MarkDown itself. For examine, we could do have the PR submitter store those as an HTML comment within the MarkDown. That way, I think it will be easier to track, especially as the cheat sheet grows and needs to be split into multiple cheat sheets.

One reason that I've been thinking about this is because I've been thinking about the advent of "vibe coding" (which I don't think at the moment is necessarily a good discipline, but we're past the point of stuffing that Genie back into that bottle), how we can preserve the AI meta-data and prompt(s) so it's closer to the code and for ESAPI, what I was mulling over was using some sort of structured comments close to the code that it generates. But I wasn't sure how to best handle it in MarkDown until I realized that we could ask they that information be dumped into HTML comments because that type of comment is not rendered.

[nickchomey]

I appreciate the desire to be kind and diplomatic (I was actually quite positively struck by it when I and others started asking questions about Fetch Metadata for CSRF), but I suspect it won't work in this situation because these are not good-faith efforts and they're not potential contributors who you should want to cultivate.

There's a significant difference between someone genuinely trying to help and needing some guidance, and lazily, selfishly and disrespectfully submitting AI slop issues and PRs to get something on your CV.

Consider following curl's lead https://curl.se/.well-known/security.txt

The curl open source project accepts security reports for problems found in products made by the curl project. We offer NO (zero) rewards or other kinds of compensation for reported problems, but we offer gratitude and acknowledgments clearly stated in documentation around confirmed issues. We will ban you and ridicule you in public if you waste our time on crap reports.

[nickchomey]

Ps I made a comment about this in hackernews and people are very much relating to it. Some have even described the pattern verbatim.

Someone creates a garbage issue. Someone else asks to be assigned. Someone from the project may say "we don't assign issues" (this step has zero effect over later steps). Someone else submits a PR. Maybe someone else will submit another PR. Maintainers then agonise how they can close issues and PR(s) without being rude or discouraging to genuine efforts.

https://news.ycombinator.com/item?id=46717706

[jmanico]

Hey @nickchomey we can always be diplomatic and there is no excuse to not be as leaders.

Please do not let this stress you out. If anyone is getting upset at suspected AI content, assign it to me and I'll take care of if.

Leaders. Put your swords down. We must always be kind and diplomatic, even when closing out AI slop issues. Even when blocking repeat offenders. Even when we get upset.

[jmanico]

> We will ban you and ridicule you in public if you waste our time on crap reports.

This is horrific and I do not at all support it. Banning is ok. Ridicule is not. Please always be kind and assign to me if you have an issue with it if you can no longer be kind.

I realize this topic is stressing you all out. Please don't let it. Just pass the junk to me and I'll sort through it.

I submit this to you all with respect. I do not want any of you to suffer or have your time wasted.

[szh]

Thanks @jmanico for the moral clarity and leadership ❤️

[jmanico]

I hope you feel like your concerns are being addressed. I'm with you folks. I don't want your time wasted.

I welcome all of you to be more aggressive in politely closing out issues that look like AI slop. It's gettin' insane. :)

[WilliamMace]

This touches on a broader AI governance challenge. From a GRC perspective, the issue of LLM-generated contributions to security-critical resources like OWASP cheat sheets is essentially a supply chain integrity problem.

Organizations that reference OWASP guidance in their security policies and control frameworks are trusting the quality and accuracy of that content. If AI-generated changes introduce subtle inaccuracies into security guidance, the downstream impact on compliance programs and risk assessments could be significant.

The approach @jmanico described — clear contribution policies, maintainer gatekeeping, and not hesitating to close low-quality submissions — aligns well with how organizations handle change management controls (e.g., NIST 800-53 CM-3). Having a defined, enforceable process for vetting contributions is really the same principle as configuration change control applied to documentation.

Appreciate the transparency in how the maintainers are addressing this.