Fewer Gates, More Guardrails: DevSecOps Lessons Learned in 2017

2017 has come and gone.

This past year saw dominant players in transportation, retail, media, advertising, healthcare, and consumer electronics disrupted by innovative software companies no one had ever heard of before.  And so, it's easy to see why CEOs and board members everywhere are looking over their shoulders and pleading with IT leaders to develop innovative applications faster than the competition.

2017 also witnessed yet another year-over-year increase in application security breaches.  TSA, Verizon, NSA, Equifax, Uber, NHS; just to name a few.  Thus, it's clear why application security is more important than ever. 

As we prepare to enter 2018 -- it’s a good time to reflect on the fact that both "speed" and "control" are equally critical to any business seeking to out-innovate the competition.  It's also worth reflecting on the friction that has long plagued the working relationship between software developers and security professionals.  And, most importantly, it's the perfect time to understand how DevSecOps automation can promote tribal trust and enable teams to accelerate software innovation while simultaneously maintaining security and governance controls.

Fewer Gates.

Given that application security is critical to modern software development; then why do so many developers have disdain for something that is fundamental?

The primary reason is because traditional AppSec tools have been implemented as "toll gates" within waterfall-native work flows.  In this model, developers are required to get in line, submit to a security scan, and wait to see the results.  When the results are produced, developers inevitably spend significant time and energy investigating red flags raised by security.  In far too many cases, these red flags turn out to be false positives generated by legacy tools that are incapable of accurately identifying real security concerns.  Thus, developers find themselves jumping through hoops, chasing down suspects, and wasting time.  It's no wonder developers "hate the gates" and view traditional security programs as inhibitors to innovation.

More Guardrails.

Software development is changing fast.  Continuous integration.  Continuous delivery.  Containers.  DevSecOps automation.

Contrary to what some people might think, these practices are not an excuse to cut security corners.  Rather, they represent the perfect opportunity to do security better than ever.  But how?

Modern application security tools must be fully automated, largely invisible to developers, and minimize friction within the DevOps pipeline.  To do this, these security tools must work the way developers want to work.  Security controls must integrate into the development lifecycle early and everywhere.  These controls should live within the developer's preferred tools and create rapid feedback loops so mistakes can be instantly remediated at the time they're made.

Such controls can not take the form of "toll gates".  Instead, they must take the form of high performance "guardrails" and create a governance environment in which developers can go fast -- and security professionals can rest comfortably knowing that their policies are being complied with every step of the way.

Dawn of DevSecOps.

According to Gartner, corporations spend nearly $100 billion per year on a wide variety of infosec products and services. 95% of these investments are aimed at building massive perimeter defenses designed to keep bad guys out.  Yet, only 5% of these funds are invested in AppSec tools designed to empower developers to deliver software that is secure by default.

The problem is obvious.  Over the past decade organizations have invested nearly a trillion dollars to improve cyber defenses by bolting security on at the end of the application development process — and yet the industry is still experiencing a steady increase in breaches.  Thus, these simple questions are begged:

• Is 2018 the year when a majority of organizations will focus less on building perimeter defenses -- and more on building applications that are secure by default?
• Is 2018 the year when appsec professionals demonstrate to developers how security guardrails can be baked into the DevOps pipeline without inhibiting innovation?
• Is 2018 the year when DevOps teams create a permanent seat at the table for security professionals and welcome their contributions as critical to success?

I am not entirely sure what the future holds -- but, I do know that integrating and automating security into the application delivery process is far more efficient than fixing vulnerabilities after the fact.

2017 was a terrific year for Sonatype, punctuated by phenomenal 4Q.  Based on the momentum in the market, I am hopeful that 2018 will forever be remembered as the dawn of the DevSecOps era.