Perhaps. But someone thought it was a good idea to put up a telnet port 23 default-admin-password interface. The point is, if you give that person two weeks to focus on securing the product, I'm not sure they would realize it's a bad idea to do that. People who are bad at security don't realize they're bad at security. Which is why it's probably important to bring in an outside team to break the product.

Or to put it another way, if we're not proposing to bring in an outside team to conduct a pentest, what's the alternative?

I've done intentionally insecure things because I simply straight-up did not have time to do them correctly. Shared keys, shared password across an entire infra--lots of stupid things because my deadline wasn't moving and hours counted. The difference, of course, is that I retain control of my stuff and I'm not pushing things out to other people.

Pentests are, to be clear, great, and there are plenty of people who Dunning-Kruger their way through security decisions. But time is definitely a factor in this stuff.

I agree, but think of it this way: imagine a doctor arguing against washing their hands. The analogy is pretty apt. Washing your hands is as effective in reducing disease as pentests are at improving security. So why are we still seeking ways to justify to ourselves that we can do without pentests?

It just seems like pentests need to move from "nice" to "necessary." (Part of that is reducing their cost from $60k to $6k.)

The bigger problem with pentests is not the current cost but, as I see it, is that security is inherently and inescapably expensive somewhere in the chain, and that vendors have been getting a free lunch for too long. The viability of security analyses/pentests will go down if your goal is to reduce the cost by an order of magnitude because the people who are any good will find something better to do--and the consumer will still pay through all the bullshit externalities.

Security needs to cost to demand talent. The real solution to this problem, I think is that failure to secure needs to cost (whether in monetary or criminal terms) or it isn't relevant to business concerns.

I think the parent was arguing that this:

> security is inherently and inescapably expensive somewhere in the chain

...is the thing that needs to change. Presumably using more automation (e.g. employing more software like http://lcamtuf.coredump.cx/afl/), such that "pen-testing" shifts from being a labor cost to a capital cost.

Open telnet servers are a solved problem (taking the solution off the rack is a question of time and, effectively, the willingness to be negligent). The automation exists.

It's the hard stuff that is context- and environment-dependent to a degree that it resists automation.

It pen testing necessarily expensive? I wonder if we could train QA to use something like kali (or even just some network tools) to find 99% of vulnerabilities.

Sounds like a good opportunity for something analogous to UL certification, albeit for security.