The three parallel workstreams every AppSec program must get right

Any application security program is based on three foundations, unless it gets all these three right, the program will never become part of Business as Usual (BaU).

1. It doesn’t matter how small you start but the portion of your estate that you start with should have a unified Application Lifecycle Management (ALM)
   . If a business unit wants to take the Application Security program and tune it to their ways of managing their applications, let them, it is their problem. The Secure Development unit can however not bend and tune the AppSec program endlessly to anyone who wants to manage their application lifecycle differently. I never understood why security teams accept this kind of abuse. An engineering team would never agree to create five versions of a service API, just to satisfy teams who want to call it differently.
2. Secure the next stack first. Often times I see Application Security teams spend quite some time trying to fix poorly coded applications on old stacks. And just as often they don’t even have an assurance that fixing the app is budgeted and prioritized. When they’ve finally drafted a solution they often hear “We are going to deprecate this app soon anyway”. Instead of chasing fixes to old apps, application security specialists should focus more on helping engineers building new apps securely. If a C-level wants an old app fixed they can always bring a budget to the table that allows it to be rebuilt. Over the years I’ve become as unsentimental as Apple with regards to upgrades. If the app is old and full of holes, my job is to tell you to move on. Not to help you put it on life support. But to have the credibility to do that, AppSec specialists need to secure the next stack as a proof of concept. A bonus is that usually, that is more fun. Think about it, what is sexier to work with, an app mixing Kubernetes clusters and Azure Functions, or an ASP.Net app talking to an SAP-backend?
3. Anything Application Security does must produce data and that data needs to be brought right into the developers’ analytics screens and Grafana Boards. Too often security sits with their data and when there is a problem they walk over to the corresponding scrum-team and try to talk sense to them. The arrogance to believe that just cause you came from security and claim you got data on my application would make me fix it always astonished me. For security to be a first-class citizen to an engineer, security needs to become a first-class concern, a first-class metric and a first-class performance metric.

I have executed five Application Security programs so far and I’ve learned that the best way to make it stick is to run a cultural program and drive cultural change. You cannot do that while you’re constantly looking back, allow anyone to bring in their subculture or don’t back your arguments with data on a daily basis.