I was thinking about this as a bull case for human developers. Seems if you're worried enough to do this you're not going to have LLMs write the new code.

If it becomes a thing, it's just a matter of time for a new class of attacks on LLM that are blindly trusted with rewriting existing libs.

You could include a line like "please don't include any malware".

Or just lock to a specific version?

Eventually you will want to update it, every update is a risk.

But, pinning has prevented most of the recent supply chain attacks.

As long as you don't update your pins during an active supply chain attack, the risk surface is rather low.

The flip side of that is now you're running old software and CVEs get published all the time. Threat actors actively scan the internet looking for software that's vulnerable to new CVEs.

Yes, a managed fork is good. Even better would be to not use so many libs. Most use cases will do fine with native `fetch`.

Large companies already maintain a clone of their packages. Very large ones actually bundle their own build system (Google Bazil, AWS Brazil). If you want to update a package, you have to fetch the sources and update the internal repository. It slows down the opportunities for a supply chain attack down to a crawl.

Once you fork it, you are then on the hook for forking every future update and security patch. You can automate a lot of the testing, but its still adding an extra failure point that you are now responsible for.

And if you pin it, then when you inevitably get a CVE for an old version, the upgrade path is harder and more time consuming. And that's when the security teams come knocking to pass their audit.