DevOps moves security closer to the beginning of the software lifecycle.
The speed at which applications must be brought to market, coupled with the need for more secure code, has started organizations on the path toward tighter integration of security into the development process. That trend will continue in the coming year.
Today's world is one of automation and continuous iteration. We call the process "DevOps" because it melds the development of software and the definition and automation of infrastructure to create models for deployment and operations that are self-enabled.
When we add security to that, we apply the same expectation that we automate everything and define the patterns and process such that they can be repeated continuously. We end up with what I like to call "DevSecOps."
The key in this new approach is to "shift left," moving security testing and open source composition efforts away from late-stage production and towards design and development.
Just like in DevOps, where developers are enabled to define software-based architectures, version them, and deploy them using automation, DevSecOps gives those same developers tools, technology, and processes to do the same for software security.
Step 1: Start in Design
The biggest way open source gets off the rails quickly is by not considering the app's makeup before we start coding. Are you still using a two-year-old copy of Struts for your new app just because it's what's already on your workstation, left from the previous 10 projects you did? Each time you start a new project, make sure you're using the freshest, most trusted version of the frameworks you rely on. Use free or inexpensive tools like SourceClear to identify the bill of materials (BOM) in your app and be sure it makes the grade before you start work. It will save you headaches later.
Step 2: Automate All. The. Things.
As a developer, few things can be more irritating than someone coming to me with yet another thing to do in my already overloaded day. If you expect developers to use a tool, look on a website, or ask someone permission each time they deploy, they will inevitably find a way to avoid it.
On the other hand, if you can automate the process of running that thing, or checking that list, or notifying that group, then developers stay focused on what makes the company money or adds value for a customer. InfoSec likes to say "security is everyone's job" but often forgets that adding value comes first. If we can't add value for our customers or our shareholders, there won't be anything to secure.
The key here is to do it out-of-band and make it transparent. It must be asynchronous and invisible or it will become somebody's pain point.
Step 3: Develop "Good Citizens" Not "Good Builds"
Last, for DevSecOps to truly be achieved, we have to work to change the mindset around InfoSec policy and deployment processes related to that.
Most deployment models that involve security have in the past looked something like:
Design –> Code –> Integration test –> QA –> InfoSec Review –> Production
But, when DevOps cycles are potentially only hours or even minutes, how do you get InfoSec to review before production? The answer: You don't.
Let me put it this way: If developers are getting good information early on because you automated static code analysis, and you provided an automated method for generating a BOM for your open source frameworks, and you have been providing this early in the software development lifecycle since development or even design, then what exactly are you testing in the build?