But the header is just "90% of Claude-linked output going to GitHub repos w <2 stars". No conclusion, just some random fact.
The problem is that this title is editorialized, and the fact is cherry-picked. Why not =0? Why not >1000? This is just a dashboard, it highlights "Interesting Observations", but stars statistics is not there.
The pattern you found between reversible and irreversible decisions is interesting. Did writing them down change how you made decisions going forward or did you just keep making the same mistakes with better documentation? Asking because I have tried something similar and found that knowing my pattern did not actually fix it. I still agonize over the wrong things.
It's called "tacit knowledge" and I think we generally overindex on explicit, formal knowledge and ignore tacit knowledge. You can see that with language learning, we treat languages like something you "learn", but in my experience it's closer to a motor skill like playing tennis.
The most recent phone numbers I actually remember are those I learned and used just before getting a smartphone. I guess tapping on a screen doesn't quite give you that same effect!
the requests.post advice is right but its also kind of depressing that the state of the art recommendation for using llm apis safely in 2026 is to just write the http call yourself. we went from dont reinvent the wheel to actually maybe reinvent it because the wheel might steal your ssh keys. the abstraction layer that was supposed to save you time just cost an unknown number of people every credential on their machine
whats new isnt the shortcuts, its the cascading. one compromised trivy instance led to kics led to litellm led to dspy and crewai and mlflow and hundreds of mcp servers downstream. the attacker didnt need to find five separate vulnerabilities, they found one and rode the dependency graph. thats a fundamentally different threat model than what most security tooling is built around
the chain here is wild. trivy gets compromised, that gives access to your ci, ci has the pypi publish token, now 97 million monthly downloads are poisoned. was the pypi token scoped to publishing only or did it have broader access? because the github account takeover suggests something wider leaked than just the publish credential
Yes and the scary part is you might never know the full extent. A credential stealer grabs whatever is in memory or env during the build, ships it out, and the attacker uses those creds weeks later from a completely different IP. The compromised package gets caught and reverted, everyone thinks the incident is over, meanwhile the stolen tokens are still valid. I wonder how many teams who installed 1.82.7 actually rotated all their CI secrets after this, not just uninstalled the bad version.
It’s not wild. Anyone with brains would think it is irresponsible to keep your secret token for publishing public release binaries accessible in your automation.
It would be great if Linux was able to do simple chroot jails and run tests inside of them before releasing software. In this case, it looks like the whole build process would need to be done in the jail. Tools like lxroot might do enough of what chroot on BSD does.
It seems like software tests need to have a class of test that checks whether any of the components of an application have been compromised in some way. This in itself may be somewhat complex...
We are in a world where we can't assume secure operation of components anymore. This is kinda sad, but here we are....
The sad part is you're right that we can't assume secure operation of components anymore, but the tooling hasn't caught up to that reality. Chroot jails help with runtime isolation but the attack here happened at build time, the malicious code was already in the package before any test could run. And the supply chain is deep. Trivy gets compromised, which gives CI access, which gives PyPI access. Even if you jail your own builds you're trusting that every tool in your pipeline wasn't the entry point. 97 million monthly downloads means a lot of people's "secure" pipelines just ran attacker code with full access.
oauth is the one area where I genuinely trust the LLM more than myself. not because it gets it right but because at least it reads all the docs instead of rage-quitting after the third wrong scope
reply