Building a DevSecOps Culture

Talk to any enterprise that has embraced DevOps and are trying to ensure security is adequately integrated into the organization and they'll likely say the challenge is twofold: tools and culture. Moreover, the most difficult of those two is culture.

Integrating security culture into DevOps, or getting to DevSecOps, is an ongoing exercise. It requires leadership, a change in individual behavior, and a change in the overall culture. This takes time and the right efforts.

I know it’s easier said than done. Consider a recent survey from the Sonatype DevSecOps Community Survey. This survey found that 58 percent of the nearly 2,300 surveyed view security as an inhibitor to DevOps agility.

The survey wasn’t all bad. The higher the maturity of the organization the less likely that DevOps teams believed that security policies and the security team slowed IT down. Only 28 percent of highly-mature organizations thought security to be The Department of Slow. Still, a hefty 47 percent of responses immature organizations did find that that to be the case.

Interesting, and by “interesting” I mean depressing: 50 percent of developers know security is crucial, but they just don’t have “enough time” for it.

We can't merely blame developers for this. That's all too common and all too easy. We can't assume that many developers are lazy or evil and don't care that sensitive information is easily stolen — but instead that they are stuck in poorly implemented processes.

With that in mind, there are ways — especially in the software-defined everything, highly-automated DevOps world for security to be baked better into processes and workflow.

Here are some keys essential to making sure security is established as part of the DevOps culture:

Provide training. Let's face it, there's not enough formal application security training in college, and there's not enough application security training on the job. Considering the amount of software created every day, and how critical that software has become to the functioning of society, there are not enough application security experts to go around. If an enterprise wants to build and manage secure efforts, it's going to have to train its experts.

Secure by design. The very idea of DevSecOps is to integrate security into all of the appropriate DevOps processes so that software is secure by design, development, and in deployment. This is also along the same lines as GDPR, which calls for privacy and security by design. So wherever and whenever possible put security processes and controls in place. This goes beyond automated security code tests and includes threat modeling new apps, services, and capabilities as they're being designed, figuring out ways to improve security throughout such as having secured shareable libraries, and reusable components developed and made available to teams.

Leverage scripts and automation. There are many potential security enhancements in DevOps environments. This includes the virtualization of software, infrastructure, and networks which makes infrastructure, networks, and applications programmable. All of this, if managed correctly, is a significant benefit to security. If executed poorly, it can increase vulnerability and risk.

This makes it possible to automate previous manual activities, such as asset management, networked device discovery, some levels of patching, configuration management, security assessments, and more. Look for areas where you can automate away tasks so that security staff can focus more on higher-level areas.

Incentivize security. It’s all too common for security staff to identify a poor security practice and immediately swing the pain-hammer. No good. Instead, if a development team starts filing more secure software (perhaps measured as fewer defects per 1,000 lines of code) provide some kudos or award. When someone falters, maybe offer encouragement and training. Also, rather than try to rid all of the security-related mistakes developers are making in one fell swoop, pick one or two common ones or the riskiest and focus on eliminating those, and expand from there.

Standardize tools and processes. Frequently DevOps processes sprout in various parts of an organization organically. The risk here is that security efforts become haphazard and irregular. Every group starts to do things their way, choose their testing tools and methodologies. What happens is no one is speaking the same language and efforts, and communications falter. Indeed, many different teams will need to use different toolsets because they may be working with various cloud infrastructures, development languages, and platforms. However, whenever possible organizations should seek to standardize.