This is the first blog in a short series on exploring the challenges with software development through a security-first perspective.

Noise #1: Tools

Perhaps the biggest contributor to this noise is the DevSecOps market itself. “Buy me! I can solve that single point problem for you!” The offerings of DevSecOps tools and platforms has grown exponentially over the last decade, which has turned up the level of volume with a basic value proposition: more tools = better security. But that’s not how you build more secure software. 

Good Application Security starts with healthy processes that are supported by the tools – not the other way around – otherwise security and development teams become awash in data without the context to transform it into actionable information. Yes, the evolution of the DevOps pipeline has demanded the need for expanded automated security testing, however, thinking that because you have the tools you have security as well, leads to lazy AppSec and a false sense of confidence in thinking your application is secure because you’ve fixed the things the tools told you to – not the ones that are most critical for you, your application, and your company.

Noise #2: Compliance

Compliance and Application Security are often confused. Yes, there are always things you have to do like PCI, HIPPA, and eating your veggies because your mother told you to. However, if that’s all you’re doing for security, then you’re only covering the “low bar,” leaving your code and company open to more than just compliance risk. 

Good Application Security is about overall DevOps efficiency and Application health.  – it’s about making the right decisions to ensure your code meets your organization’s tolerance for risk and preparing for them as part of SDLC. It becomes a strategic asset in delivering code on time, on budget.

Noise #3: Culture

There’s no doubt that every member of the Development team understands that security must be an intrinsic part of the Development process. However there is a direct conflict with their understanding and having a culture that supports it, as with one recent study finding that they still find it a “soul-withering chore” and an “insufferably boring procedural hindrance.” But it is not that Developers do not want to incorporate security  – 74% are either part of the process or want to be – it is that they lack the solutions to manage it in their workflow without creating additional burden.

Good Application Security doesn’t just pile more tools and training on Developers, nor does it rely on security engineers or DevSecOps evangelists on teams. These efforts are just putting fingers in the dam rather than addressing how to reinforce the structure of the dam itself.  By providing the information and automation to design, develop, and deploy secure software natively in their workflows, security becomes just part of code quality, rather than hurdle to shipping.