"Yeah but it wasn't in the docker tutorial I skimmed so I have no idea what it means."
They are likely a bit of both, increasingly more so going forward.
- some checks are straightforward and it would be dumb to use AI for them
- some checks require AI
Lots of things are really simple. But you have to know about them first.
Never heard of the wrench technique? It's always gonna work out great. Way cheaper and easier than "wizardy" too.
but after having seen IRL people accidentally overlooking very basic things I now (since a few years) think using them is essential, even through they often suck(1).
(1): Like due to false positives, wrong severity classifications, wrong reasoning for why something is a problem and in generally not doing anything application specific, etc.
I mean who would be so dump to accidentally expose some RCE prone internal testing helper only used for local integration tests on their local network (turns out anyone who uses docker/docker-compose with a port mapping which doesn't explicitly define the interface, i.e. anyone following 99% of docker tutorials...). Or there is no way you forget to set content security policies I mean it's a ticket on the initial project setup or already done in the project template (but then a careless git conflict resolution removed them). etc.
Ultimately, you're just buying time, generating tamper evidence in the moment, and putting a price-tag on what it takes to break in. There's no "perfectly secure", only "good enough" to the tune of "too much trouble to bother for X payout."