I’d be happy to bet with you if I rolled my own log4j I would have never implemented jndi as a formatting argument.

Sure I shouldn’t roll my own crypto but I can write a logger…

And probably more importantly, AI can write a very simple logger with no extra features than you absolutely need in 5 minutes, if that.

Logging is a very complicated security area. You often get sensitive data in the logs and it gets sent across the network to monitoring servers.

Also any part of the program can send data to the logger. This means the logger can receive malicious payloads from anywhere. Maybe your logger handles ascii control characters badly?

Imagine that you don't need monitoring servers, like possibly the majority of actual log4j deployments?

For example Minecraft uses log4j to write messages to the console and a rotating file.

Technically you can configure it to send to other places - presumably. In practice you'd be better just redirecting stdout, tailing the file, or installing a mod?

Honestly unless you insist on allowing running your software on Windows you're much better off delegating the logging to syslog over a thin wrapper. This however goes against Java land portability promises and NIH attitude so we have what we have.

I dunno I pretty much always wrote my own logger. Not even a shared library or anything just copypaste into next project or often don't even bother with that, just knock something out on the spot. Even before AI.

The only even slightly tricky part is like "don't mess unicode up", rest is straightforward. Sure it can be complicated with logging sinks, configurability, when to flush, monitoring and so on but in many cases you just don't need all that. You just build it whenever you do need it.

Logging is complicated for the general purpose point of view. Most people never need all of those features - which is kind of the point here. Log4j had so many features that 90% of projects didn’t need. Sure, large projects with multiple servers pointing at log receivers is complicated. But how many people were affected by the needs of probably 2 companies?

Capture log messages and write them directly to stderr? That’s easy.

This is where the LLM coded library replacements make sense. When you have non-critical code that can be easily swapped, I’m happy to let an LLM generate a logging package. If I have a need to send log messages out to a separate server for archival? I’d be a little more critical.

Can, or should?

I can’t be bothered to check the exact assembly to see if timing attacks are possible.

But crypto really is just a small thing. I’m not going to design a nuclear reactor but I’ll definitely do stuff that depends on the electricity from one. Similarly one can still do their own authentication; its not like even Apple forgot to rate limit…

I understand, but I would argue its better to have an in-house 1K lines of code that only does what we need and nothing else, it well tested and under our control, than to depend on some 50K lines of code (of which we might only use 10% of functionality and the others just getting in the way) that random's on the internet can modify, sometimes pulling in transient dependencies that we would really not have in a server environment, telemetry and other gremlins. It goes without saying that opensource packages will become even more juicy targets for malware/hackers to get into your systems like we've seen in the past month (and it will only become worse - you will be forced to pay technical debt or die).

The only "third-party" packages that we want to ideally allow/support would be provided from LTS versions of our runtime (in this case, packages provided by the dotnet team and audited by microsoft). So we will always try to build around what the framework provides. Second choice is our own code, third choice is open-source packages, fouth choice is a separate application/appliance (lets say ZenDesk for ticketing). Over time, we will reduce this footprint to only have dotnet team code and our own.

Remember most CVE's can be hidden on servers that are not publicly routable and don't have a real exploitation paths. The bits that are public (lets say a linux edge server with a web server on it, some firewalls, a couple of open ports) - these should be hardened to the max and not allow full access to all the services running behind it. We don't even give our internal services public IP addresses to make near impossible to route traffic to them.

Our git repo's are also not on public infrastructure (serious, think carefully about hosting on public services and if you really need it), never mind making the repo public.

We also have a dedicated secrets/certs manager, so no credentials are in codebases or pipelines. Very strict in this regard.

> Remember most CVE's can be hidden on servers that are not publicly routable and don't have a real exploitation paths.

The thinking of "it's inside so we're safe(r) from attacks" is a false sense of security, as (e.g.) Maersk learned with NotPetya:

* https://www.wired.com/story/notpetya-cyberattack-ukraine-rus...

* https://archive.is/Amlij

From the year 2000:

   NAT (particularly NAPT) actually has the potential to lower overall
   security because it creates the illusion of a security barrier, but
   does so without the managed intent of a firewall.  Appropriate
   security mechanisms are implemented in the end host, without reliance
   on assumptions about routing hacks, firewall filters, or missing NAT
   translations, which may change over time to enable a service to a
   neighboring host.  In general, defined security barriers assume that
   any threats are external, leading to practices that make internal
   breaches much easier.

* https://datatracker.ietf.org/doc/html/rfc2993#section-9

> it's inside so we're safe(r) from attacks

Kind of works until the TV, the fridge, a user's BYOD or your printer has infiltrated your LAN.

So it kind of doesn't.

It's a defense-in-depth thing, not our only layer of security. So even if they somehow get in, they will find nothing again, every layer deeper becomes harder. Oh and don't count the decoys and honeypots we have floating around to keep the morons occupied.

> on some 50K lines of code

also some 3rd party libraries are overdesigned/overcomplicated because everybody wants the library to do everything for everybody.

This overcomplication can easily introduce security problems that is not present in the 1K solution.

Thinking about Log4J here. The vulnerability was with an obscure functionality that I’ve never seen used. Sometimes simpler is safer.

Of course, sometimes simpler is “I stored the passwords unhashed”, so you have to find the middle ground.

Log4J is a really good example. You have to rely on the taste of the maintainers to not just include endless additional features.

jackson-databind too

> overdesigned/overcomplicated because everybody wants the library to do everything for everybody.

Also a source of significant dependency churn even excluding security bugs.

Whereas with my own code I don't have to worry about scheduling work that's only arisen because somebody outside my organisation has decided to make a breaking change in a dependency. Paying that tax got old over a decade ago, and my patience with it now is close to zero.

100% our thinking too.

cough OpenSSL cough

As every cryptographer will surely agree, having every company vibecode their own bespoke in-house replacement to OpenSSL will be a great improvement to security across the industry.

No need, just use any of the other libraries

The purpose of the above comment is to highlight the flaw in the original premise. Surely we all agree that we would rather not be using a vibecoded cryptography library. But why is cryptography special? Why stop there? I would also rather not be using a vibecoded regex library, or a vibecoded codec parser, or a vibecoded web framework, etc.

The point being, if you weren't committed to maintaining your own implementation of a library before the advent of LLMs, having access to LLMs does not fundamentally change the calculus. The ability to generate code more quickly does not automatically grant an organization the capacity to maintain more code.

After Heartbleed the OpenSSL team upped their game so much, that LibreSSL guys said themselves that LibreSSL is obsolet now. So this no longer stands true. Just use OpenSSL.

I would rather let someone else pay the price of maintaining 50k lines of code than to pay the technical debt of 1k loc myself.

You might believe that your own 1 KLOC is well tested but you're probably wrong. As your business evolves and use cases expand, someone will feed it bizarre inputs that you never thought to test and then it will break. I've seen this happen over and over.

It has been proofed again and again that you cannot trust npm/cargo not even AUR, implement you own minimalist functionality without dependencies and just for you own needs seems to be a much better solution.

Agreed. It’s the modern security through obscurity.

Security through obscurity protects you from low effort vulnerability scanners.

It makes you more vulnerable to a sophisticated targeted attack. A competent hacker or AI will quickly find vulnerabilities in your custom libraries.

> A competent hacker or AI will quickly find vulnerabilities in your custom libraries.

So why wouldn’t a competent AI find those vulnerabilities during development? I don’t think the proposal is to have human devs hand write the custom libraries and yolo into prod.

Swords and shields. The advantage of the defender is that they have access to the code (usually not available to attackers). The advantage of the attacker is that they have skill and nowadays the most up-to-date models and SOPs for finding attack vectors.

Also the defender has to be right every time, the attacker just has to be right once.

(Defence in depth does mitigate this somewhat. The attacker has to be right two or three times)

You don’t think models have leveled the playing field? I do. They haven’t eliminated the attacker’s advantage, but they’ve armed non-security-experts with tools closer to what attacking security experts have.

> So why wouldn’t a competent AI find those vulnerabilities during development?

It probably would. Except it’s internal, and not a reportable CVE, so the fix will be deferred.

I would like to agree too but there's a genuine new debate here, with LLMs/agents, the storm of CVEs, supply chain attacks, AI assisted social engineering, etc, some custom code doing the minimal required task might be a better security posture than picking a popular library.

I don't know were it will leave us in the long term and I don't think I'll like the answer.

> ...some custom code doing the minimal required task might be a better security posture than picking a popular library.

Only where the AI solution is verifiable by the dev doing the promoting and review. Cryptography is probably better served by libraries vetted by experts.

Cryptography is certainly a valid exception. But for how long? Two years? Three? At some point even that will fall.

If a human cannot verify it then why should it get the highest possible level of trust?

That would be like investing in things one doesn't understand for themselves.

An ironic analogy, because most people do exactly that, most of the time. How many people with money directly or indirectly invested in Alphabet or Ford actually understand those companies' financial positions? And I don't mean "has read the filings". I mean understand them to the same depth that a professional security researcher understands a cryptographic implementation.

We routinely place trust in things we cannot personally verify.

Ultimately the guarantor of cryptography code won't be humans, it will be councils and red teams comprised of other LLMs.

And that's a problem when a 2007 situation happens.

Public software is going to be attacked by many more dollars of AI time than internal stuff. In a year the library code will definitely be more secure against the next X dollars spent on cracking it.

in theory, a company running custom software should be able to invest many more hours into running those same AI with "white-box" pen-testing (assuming hyperscalers actually start allowing this). An attacker would have to be willing to outspend the company (or get very lucky). If an attacker is resourced well enough to put that investment into owning a single company, you probably don't stand much chance reguardless.

Also, the attacker would have to run black box against the live environment which is much more difficult and likely to be noticed than offline white box.

I think avoiding all 3rd party libraries is excessive, but engineering is about tradeoffs. In the extreme case, do you pull in a LeftPad dependency or write it yourself?

It also depends on whether “avoid” means a strong preference against or a rigid doctrine to never use no matter what.

on the other hand you are not exposed to supply chain attacks

Well, the AI model is your supply chain in this case.

most model providers have a direct financial incentive to make sure that the code that is produced is not backdoored

I mean that is true for anyone that sells software. That doesn't mean it's not a hard problem.

That would be an indirect incentive (reputation). The direct incentive is to add a backdoor.

good point!

> Avoiding 3rd party libraries seems like a false sense of security

To be fair, there is more nuance to your statement.

A lot of it depends on your programming language.

For example with Go, with its extensive and excellent stdlib, you would be foolish to rely on large swathes of 3rd party libraries, because so much can and should be done using the Go stdlib.

On the opposite end of the spectrum, you have Rust with an effectively non-existent stdlib.

And the problem you see frequently with Rust is projects importing half the internet, with a Cargo.toml the length of your arm with hundreds of dependencies. Of course the project has never reviewed its dependencies source code, and the project probably barely keeps its dependencies up to date. Its a supply-chain attack waiting to happen, not if but when.

So with languages like Rust, you have to take an approach of "minimal reasonable dependencies", make an active effort to keep your dependency list short and in-control.[1][2]

> less well audited than public libraries

I also struggle with this particular argument because the reality in open source is "well, its open-source, it has many eyes" is in fact mostly a dream. Since we all know 99% of the time its a small group of maintainers (assuming there is are even multiple maintainers[3]) and not many (if any) external reviewers.

[1] https://tweedegolf.nl/en/blog/119/sudo-rs-depencencies-when-... [2] https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-... [3] https://xkcd.com/2347/

One problem I’ve seen with third-party libraries, especially in the JS ecosystem, is that to fix a CVE, you often need to jump a major version or three, and that entails quite a bit of work to adapt to breaking changes. Porting a fix back on your own and keeping your own fork is the same as supporting a first-party library, except it’s not really first party, and you’re not familiar with its innards.

I feel like security by obfuscation might actually be valuable in the age of llm attacks

Not having access to the source is certainly a disadvantage for LLMs, though I saw an article the other day about a model running a disassembler on the binary, from that reconstructing the roughly equivalent C, and finally analyzing that. So, even if the binary is available there are paths.

Yes but that's not entirely obfuscation, see ie what google does to their proprietary endpoints through protobuff. Something like that but on steroids could skip the majority of attackers using LLM scanners.

Similar to distroless containers & statically linking all dependencies

>Avoiding 3rd party libraries seems like a false sense of security.

What a bullshit.

It's different scenario, different trade offs.

You mitigate risk of library being sold to malicious 3rd party, you avoid risk of your supply chain being hacked, you avoid API/behaviour breaks, etc.

The trade off is that you have to maintain it.

That's why dotnet's ecosystem is so loved due to MS providing 90% of needed libraries, so you avoid some 3rd parties maintained by single person.

This is the way! What also affects the decision is what the code will be doing, and how much extra functionality that you will never use (extra attack surface) you will get by importing external library after library.

Often it can be a very good choice to write the functionality yourself and not rely on external libraries.

Same approach here.

And since we now have coding assistants, maintaining in-house costs near nothing now. Nobody else can break us, only ourselves.

Using 3rd party libraries is a false sense of security

> just in your own code that is less well audited than public libraries

why do you think public libraries, which change all the time, get deprecated, handed off and supply-chain attacked are well-audited in any way?

It really depends on what the product is, what the 3rd party library is used for, and what the alternative is. Unfortunately, some people are too biased towards using 3rd party libraries and don't understand the tradeoffs.

For example, a few years ago I removed a rather large 3rd party mathematics library because we were only using it for a single mathematical function that was very easy to replicate.

Remember, 3rd party libraries need to:

1: Be periodically audited to make sure you are in compliance with the license terms, and preferences of your company.

(1.5: This becomes important during an acquisition as someone will always come around doing due diligence.)

2: Be periodically updated (in case of security bugs)

2.5: Be updated on short notice when a security issue is revealed.

In the case of the mathematics library, replacing it with roughly 20 lines of code and 100 lines of tests is a significantly better tradeoff than constantly reviewing it every time one of the above things happens.

Now, at what point is it "worth it" to use the 3rd party library? In our case we'd need to make much heavier use of the library, probably at least 20 different mathematical functions from it.

3rd party libraries are attack vectors and if like many many people you’re only using one or two functions then it’s much better to get rid of them.

If you reduce the amount of code/code paths you reduce the surface area that vulnerabilities can appear on. A code base with 10 million lines can have a lot more bugs than one with 100k.

Two edged sword. That means the bots also have a library of exploits to try for the components used in your project.

You’re probably right about some third party libraries, but not about all or even most of them. Package repositories are full of half baked packages that are the result of a single person scratching their own itch once upon a time and thereafter forgetting about it. The more harmful part happens when those get imported into other third party libraries that give the image of being better supported. Supply chain attacks are the new null pointer.

I personally only rely on 3rd party libraries that are complete. I will never use a library that gets consistant feature updates. I do make an exception for openssl rusttls and whatnot since they have to update by design.

but public libraries can also be audited because they are public

For database programs, I would disagree, this should never become something like the nodejs ecosystem.

The one thing that cuts the other way is code churn. Third party libraries may keep adding features you don't use, and those may expose new bugs. You can pin an older version, but unless the library back ports security fixes, you are not going to benefit from the shared development wrt to security.

If you spend a ton of time hardening your own library code and don't have much feature sure, then that can be a win.