I've been playing around with LLM red teaming different server stacks with known or intentionally vulns in there and seeing how much damage they can do.

The one situation where they really can't get anywhere profitable is a unikernel webapp. With no source and no shell they find the vuln but the worst they can do with it is possibly poison or exfiltrate data as a one off, or crash the server. Often they can't even figure that out. Can't even leave themselves a reliable way back in.

Of course the traditional problem with unikernels is that you have to port EVERYTHING you need yourself. But the cheapness of this is exactly what we're talking about so.

Looks like security through obscurity's back on the menu.

I think a better comparison for the parent is probably left-pad.

Yeah I guess, if they liked PHP. Could make a new version of ColdFusion if that's your thing too.

Genetic monocultures like bananas are at risk from a single species of fungus.

Perhaps. I just never found it useful to spend a day learning the failure modes and edge cases of a general-purpose library I could hack into my use case with enough wrapper code handling the impedence mismatch when I could spend a day building exactly what we need, with the added benefit of owning the code when requirements inevitably change. Like, I'll use numpy at least half the time for numeric code; I'm not a masochist; but most libraries just don't pull their weight.

>Except when it's a license violation or in something that ends up having a security vulnerability.

What's more secure isn't so simple. If you vendor something with a vulnerability then it wont be patched. But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities. And it can cut the other way - you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks).

There is a balance that must be struck, and I think LLM's strike a better balance than people do. Dependencies are a convenience with a cost and LLM's can trivially copy or re-implement things that we cant.

Every time I try to get a npm based project running (or one of my forks of one), half the packages don't exist anymore or I need to spend hours fixing breaking changes.

It's usually more straightforward to just rebuild it from scratch — not to mention infinitely more satisfying — and that was true before AI!

Yes it does depend on the dependency, and a static asset is on one end of the extreme.

It depends on the "load bearing" code. Obviously something like crypto is not something we should implement ourselves but core business logic would be "load bearing" in another way and is probably not something you want to farm out to a dependency.