upvote
And then your language has a gaping hole (PHP or NodeJS), or the box you're running on has a gaping hole (Linux), or the PaaS you use has a gaping hole (Railway). There are just too many layers underneath the good ol' web application to claim that AI won't succeed.

Honestly, at this point the best we have is to hope the whitehat AI scanning for issues is stronger than the blackhat AI.

reply
> There are just too many layers underneath the good ol' web application to claim that AI won't succeed.

I think you got it backwards. For your AI to succeed, it needs to poke a hole on all layers, not one in many layers. If an attacker pokes a hole in n-1 layers but the 1 layer remains untouched, the system's integrity is preserved.

Why do you think defense in depth is a basic concept?

reply
Not really, no. If you're running an application server, then your entire app can get compromised if there's a security exploit in any of your app code, your web server, your kernel, your hypervisor.

Defense in depth says that simply compromising your application code shouldn't provide access to the physical hardware you're running on, and that's hopefully the case, but it doesn't mean your app is not hacked. It just hopefully means that a hack on your app code doesn't automatically give the attacker access to your entire company.

reply
As the TCP bug that surfaced a couple of weeks ago, that is not true, you depend on the kernel, your application runtime, and many layers of dependencies.

Many bugs live in all those layers that may undermine your ability to lock down inputs and outputs.

reply
And then PHP (name your lang/OS/platform of choice) comes along and pulls your sufficiently locked down app into the gutter.

This is more fundamental than better input checking. Your compute substrate itself is flawed. Intelligence and speed is indeed the only thing between “safe” and “completely open”.

I fully agree it’s a good idea to be minimal etc but I don’t see it being sufficient in the long run.

reply