From fbc26883a77e90bb02a13c97ff881f92f77a8a8e Mon Sep 17 00:00:00 2001 From: Tyler <26290074+tylersayshi@users.noreply.github.com> Date: Sun, 7 Dec 2025 17:41:12 -0800 Subject: [PATCH] fix spacing --- posts/harmful-prs.mdx | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/posts/harmful-prs.mdx b/posts/harmful-prs.mdx index e55616b..eb5e399 100644 --- a/posts/harmful-prs.mdx +++ b/posts/harmful-prs.mdx @@ -67,33 +67,54 @@ Something that added to my confidence that this is the current conventional wisd >[^3]: [Something about AI-generated pull requests ยท Issue #62666 - GitHub](https://github.com/freecodecamp/freecodecamp/issues/62666) (23%) ## The work needed to create a PR has lowered + This means that anyone working for any mix of the motivations stated at the top of the post is able to post more PRs if their bottleneck was typing. This of course, is not always the case: + -I've personally been able to see more of my ideas come to life, but I'll leave the productivity discussions for another day. For this post, it's undeniable that it is **significantly** easier to make a PR without any time spent thinking or reading about an issue. We now have [full-blown developer guides for how to make Github PR bots in "15 minutes"](https://www.educative.io/blog/how-to-build-a-github-pr-agent-with-n8n-in-15-minutes). + +I've personally been able to see more of my ideas come to life, but I'll leave the productivity discussions for another day. For this post, it's undeniable that it is **significantly** easier to make a PR without any time spent thinking or reading about an issue. We now have [full-blown developer guides for how to make Github PR bots in "15 minutes"](https://www.educative.io/blog/how-to-build-a-github-pr-agent-with-n8n-in-15-minutes). + ## Barrier to entry is lowered to the floor + With the cost of PR creation drastically lowered, people with new motivations and skillsets are welcomed into the space. These barriers of entry that used to exist are all gone + - knowing how to use git - knowing how to read & write code - having the time to spend reading through an issue and running the codebase locally + This creates a world where non-developers can make PRs in an automated way. With the lowered barrier to entry, we get a whole new category of users on Github. For better and worse. + ## New people means new motivations + Over the past few years we've seen an increase in supply chain attacks - [Shai-Hulud](https://snyk.io/blog/sha1-hulud-npm-supply-chain-incident/) - [eslint prettier plugin attack](https://snyk.io/blog/maintainers-of-eslint-prettier-plugin-attacked-via-npm-supply-chain-malware/) - [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell) - plenty of others -There's been some reporting on how [phishing emails](https://snyk.io/blog/phishing-campaign-leveraging-the-npm-ecosystem/) have been used as a way to get maintainer's publishing tokens. And thankfully some moves towards [more security in publishing](https://docs.npmjs.com/trusted-publishers). + +There's been some reporting on how [phishing emails](https://snyk.io/blog/phishing-campaign-leveraging-the-npm-ecosystem/) have been used as a way to get maintainer's publishing tokens. And thankfully some moves towards [more security in publishing](https://docs.npmjs.com/trusted-publishers). + There's a concept in phishing called "chumming" or a "double-barreled attack." Attackers send an initial low-effort email not expecting it to succeed, but to see who bites. A reply marks you as someone who engages with strangers. Then comes the real attack. + AI slop PRs map onto this uncomfortably well. Generate PRs in mass across repositories. Cost is near zero. No expectation that most will be merged. + A maintainer who merges the PR reveals they don't review carefully. A maintainer who engages extensively, explains problems, requests changes, goes back and forth, reveals they're stretched thin and responsive. A maintainer who closes immediately with visible frustration reveals burnout. Each of these are useful signals. + The follow-up could be phishing for publishing credentials. It could be a second, cleaner PR with something malicious buried in legitimate-looking changes. It could be social engineering to become a maintainer on an understaffed project. Or like the Log4Shell attack, simply getting added as a new maintainer. Or it could just be waiting. Burned out maintainers eventually hand off keys or stop reviewing carefully. + Even without a follow-up, the attacker wins something. Every minute spent triaging slop is a minute not spent on real contributions or security reviews. It's a denial of service that doesn't look like one. + ## What to do about it + Policing this stuff is messy and hard. I don't pretend to have a good grasp on how it can all happen. That said, I'd like to call Github to action on this. There is an opportunity to be pioneers in the Trust and Safety space and show it off in a very public way. I'd like the story of Github Trust and Safety to mirror the way they leaned into Dependabot years ago. These are very visible and helpful toolsets that can bring happiness, trust, and productivity to the platform. + In the meantime, there have been good attempts from community members to work towards some levels of defense for projects: + - automated PR bots: https://octo.guide - there might be space for [prompt injections in PRs](https://bsky.app/profile/francoisbest.com/post/3m7g2ebi2zc2l) - AI disclosures, but these can erode trust with good faith actors as well + ## Author's note -This post exists to collect my thoughts and share how I find this to be very similar to traditional phishing. If platforms want to defend against supply chain attacks, slop PRs should be treated as malicious attacks and not just endless clutter for maintainers to clean up for free. \ No newline at end of file + +This post exists to collect my thoughts and share how I find this to be very similar to traditional phishing. If platforms want to defend against supply chain attacks, slop PRs should be treated as malicious attacks and not just endless clutter for maintainers to clean up for free. -- 2.51.2