Cutting Through the DevSecOps Noise

Brittany Greenfield

February 8, 2021

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

The importance of Application Security continues to advance in broader awareness as 42% of organizations that had experienced an external attack blamed the incident on a software security flaw, and 35% said it had resulted from a buggy web application. Yet, organizations still struggle with addressing the issue as 64% of all reported unpatched vulnerabilities during the first half of 2020 involve known bugs dating from 2018 and earlier

Adverse to workflow disruption, many companies accept the risk of a potential cyberattack instead. Despite knowing that these defects serve as an entry point for adversaries, security remains an afterthought in software development.  It is not that engineers and product managers don’t consider security, but rather that understanding and managing today’s security requirements has failed to be integrated into their workflows.  

Perhaps the biggest contributor to this noise is the DevSecOps market itself.

But then why few, if any, applications are built, with security considerations integrated into their workflows just like all other quality controls? It is not because organizations can’t create security policies and manage them across development teams and platforms, but rather because there’s too much noise in the industry about how to develop secure software and what’s needed to do it. In other words, the “solutions” have just made the problem bigger. But when you step back to identify the causes of the “DevSecOps” noise, you can remove the distractions so software security can be looked at more intrinsically to the development process rather than a practice to adhere to after-the-fact.

When you step back to identify the causes of the “DevSecOps” noise, you can remove the distractions so software security can be looked at more intrinsically to the development process rather than a practice to adhere to after-the-fact.

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.

Once It’s Quiet, Then What?

After you turn down DevSecOps noise, you can take an honest look at your software development process to understand how and where security naturally fits in. You’ll then see that starting to build secure development operations (SecDevOps) will not only reduce your security risk, but overall project and business risk – and you can do it immediately even with simple processes, policies and tools. In the next post, we will look more in-depth at the first kind of noise – tools – and how you can turn down its volume.

 

 

Related Articles

What is SecDevOps?

What is SecDevOps?

With 9 out of 10 breaches beginning with defects in code, it's no wonder that companies have rushed to incorporate security into their development pipelines. And with that rush has come a whole new industry – DevSecOps – and the jargon to go with it.   What are some...

Why SecDevOps Is This Season’s Buzzword

Why SecDevOps Is This Season’s Buzzword

DevSecOps has been a buzzword for a while now, but there is still debate about the right way to approach it in practice. Especially among development teams, there is constant noise around the definition of DevSecOps and what it really means for an organization.  Let’s...

What is SecDevOps?

What is SecDevOps?

With 9 out of 10 breaches beginning with defects in code, it's no wonder that companies have rushed to incorporate security into their development pipelines. And with that rush has come a whole new industry – DevSecOps – and the jargon to go with it.   What are some...

What is SecDevOps?

What is SecDevOps?

With 9 out of 10 breaches beginning with defects in code, it's no wonder that companies have rushed to incorporate security into their development pipelines. And with that rush has come a whole new industry – DevSecOps – and the jargon to go with it.   What are some...

0 Comments

0 Comments

WordPress Video Lightbox Plugin