In my experience pentests were just a box ticking exercise. I consider it a cultural thing. If you're having to run a pentest right before release and it uncovers a vast amount of issues then you never cared about the quality of your software to begin with and it would show up not just as insecure software. Running automated test suites periodically should be a part of software building practices. That and deep code reviews and so on. All of that to feed into the quality of what you're building.

The problem is getting the decision makers to care. And/or changing the process to at least consider quality as an important factor even if velocity is preferred(and featuritis has taken over).

Story time. In one gig I had, a couple of weeks into it I discovered that AWS keys to the production data in the S3 buckets were being exposed on the client side(an SPA). Those keys would give you access to the data for all the clients on that platform. So I figured I'd do "the right thing" and told my manager(the CTO) who said something along the lines of "yeah that sounds serious" and asked me to talk to the CEO who wrote that code. At this point, I was still expecting that I might be wrong or at least being told that it was written in a rush or something and thank me for pointing it out. The CEO just dismissed it as being "temporary production keys" and closed down the conversation. Suffice it to say that I was not the CEO's favorite person moving forward.