Use the right DevSecOps tools for more secure development
Making applications safer requires more than just new tools; it also requires a cultural shift. DevSecOps is an effort to shift security left. Here's how to get started.
We hear all about DevOps in relation to velocity, but speed shouldn't sacrifice security. That's where DevSecOps tools come in.
The operating principle of DevOps is shrinking the time from business idea to working code, through continuous integration and continuous delivery (CI/CD). But, sometimes, lost in the race to get there first is the reality that getting there with a stable product is better. According to a recent CA Technologies study, this isn't something at which DevOps shops excel.
CA Veracode's State of Software Security Report 2017 found vulnerabilities continually crop up in previously untested software at alarming rates. Seventy-seven percent of apps have at least one area of weakness on initial scan. Furthermore, 74% of respondents agreed vulnerable software and code susceptible to security threats are growing industry concerns. And that's why, as DevOps grows more pervasive with not just the unicorns, but with the horses, as well, its security-oriented cousin, DevSecOps, is a topic and practice of considerable interest.
Adopting DevSecOps tools and culture
DevSecOps is no different than all the other DevXOps in the family tree. While DevSecOps counts on culture to instill a sustainable process of security, as in regular old DevOps, culture is hard to measure. But if you want DevSecOps tools and processes to work, culture is essential.
An alarming 58% of respondents cited existing culture and lack of skills as reasons why it is so difficult to install security testing measures. And only 24% strongly believed their organization's culture and practices support collaboration across development, operations and security.
It's important to clarify when we talk about DevOps culture -- especially DevSecOps tools and culture -- what we're really talking about is ownership. Breaking down silos is one way to establish communal ownership of quality, but that's not entirely instructive. Essentially, organizations need to move from a model where developers -- or IT ops or quality assurance (QA) -- own their corner in the pipeline to a model in which folks across the development pipeline feel responsible for the code they produce.
Executive buy-in
We hear it all the time: Grass-roots movements -- as DevOps often is -- can't survive without support from the higher-ups.
Ayman Sayed
"The first step toward making security part of the process is getting buy-in from all of the teams that are involved -- from coding to test to deployment -- and this starts at the executive leadership level," said Ayman Sayed, president and chief product officer of CA Technologies, based in New York. "Leadership needs to set the tone, ultimately orienting an organization's culture toward a security-centric mindset."
Getting executive level buy-in, though -- especially for an endeavor that seeks to lengthen time to market -- isn't exactly an easy first step. In fact, less than a quarter of survey respondents strongly agreed with the idea that senior management would sacrifice time to market in order to assess and repair software security vulnerabilities.
So, how do you convince your boss to use DevSecOps tools and deliver software later? Well, start with a reminder that the earlier a bug is fixed, the less expensive it is. Use language the business side can understand. Point out the obvious business benefits inherent in DevSecOps tools and continuous quality.
Shift left testing
So, you've convinced your boss and have as much executive support as you can get. What's next?
Each developer needs to be responsible for the security of the code they produce.
Ayman Sayedpresident and chief product officer of CA Technologies
The silos must be broken down so you can instill a new kind of culture of ownership. In other words, testing and ownership must shift left.
"The development cycles are shortening, and this change is causing everything to 'shift left' -- from roles and responsibilities to the timing of certain processes," Sayed said. "Each developer needs to be responsible for the security of the code they produce, rather than task one particular group to be in charge of security."
Sayed suggested teams appoint a "security champion" as a role model and vulnerability watchdog. This might be a security-conscious developer who always urges his charges to add tripwires and other forms of deception into the codebase. If developers bake security into the process and automated testing is in place, QA pros down the pipeline have time to take a more holistic and exploratory role in the software development lifecycle.
We can't forget that doing DevOps is as much about quality as velocity. Continuous quality should be as integrated into your DevOps process as CI/CD and DevSecOps tools.
Ayman Sayed
