As an independent developer, I live and eat and have a roof because of billable hours. For many, many hears, my strategy had been to stay calm and bill hours, even in the face of weird situations, and the advice I gave to customers more or less led to that. Don't worry, let's build it. Don't worry, let's test it. Don't worry, let's break it and make it something else. Stay frosty.
But now I am changing my tune a little bit. This is because of a couple of factors. First, the "go fast and break things" strategy had gotten its ultimate test in the federal government of the US and failed totally. That strategy is over for me, I am not recommending "well let's just try it and see" any longer. Done with that.
Another impact was The Devil Never Sleeps by Juliette Kayyem. This book is about actual real emergency preparedness at the strategic level. It, not to put it too lightly, has changed my language about preparing for things to go wrong. Key to Juliette's teaching is the horizontal graph of time, where an event or "boom" is in the center, and then there is space on either side of the boom. Her primary goal is to change where we put effort, left or right of the boom. It's not just emergency preparedness, it's emergency management.
Remember "shift left"? Corporate buzzphrase from 20 seconds ago or whatever, I think it's already 'out'. Anyway, that is where I am headed in the application security space. No more "stay frosty and test your apps". Proactivity has shown over and over again to be the better solution in my estimation. Finding bugs before they ever get into the code base or never coding bugs in at all. Putting the effort to the left of the boom.
To that end, I have started recommending static analysis tools to clients with developer tool plugins. The difference? Education around that fact. Snyk does a really good job at this. Not just throw the tool out there and assume everyone will magically get it just because it makes a red squiggly line. Not just training on the tool, but real security education that just happens to use the tool. Developer education around the toolset, using their real source code, their real source code control system, real talk.
Another piece that I have always given a polite nod to but haven't really pushed is non-functional security requirements. I don't care if you are all fancy and agile and scrum and whatever the latest weird project management strategy is, at some point you need to write down what the software you are building is going to do. If there is not a list right along side describing the non-functional security requirements, requirement gathering is not complete. The OWASP ASVS is a great resource for this. I already use it on the other side, as a test plan, it really is designed to be used on the front side of a project, defining the non-functional security requirements before you start.
Front load your security. Keep it left of the boom. It's the fastest, easiest path out of this mess we are in.