What Happens When You Inject Security into DevOps: DevSecOps

Over these past few years, I’ve had the chance to work very closely with some of the most talented development teams. Even today, I’m still involved with DevOps and helping design core applications that’ll impact users, businesses, and entire methods of technology and even data center management. In working with Agile coaches and Scrum masters, I learned quickly that DevOps is a true culture.

Actually, labeling DevOps as just one ‘thing’ isn’t entirely accurate. I’ve written about DevOps here on InformationWeek previously where I define it as:

Believe it or not, those bullet points make a world of difference. When you look at development today, you’ll see a complex process of parallel operations where multiple teams are working to get everything operating properly. Rather than a waterfall style, DevOps allows developers, project leaders, and even business heads to have an impact on both code and the outcome.

While coding and having a good process is absolutely critical, I was quickly shown that you can inject other key processes into the DevOps practice. Specifically, security.

"We already do security testing in DevOps. How is DevSecOps different?"

In having conversations with leaders in the DevOps space, many will argue that security, regression testing, and ensuring that code is designed properly are already a big part of the DevOps process. However, over the course of a few projects with specific customers, I learned that DevSecOps actually takes security further than just code reviews and ensuring there aren’t any holes.

Beyond code, DevSecOps looks at the following:

Beyond that, DevSecOps will also look at things like Open Web Application Security Project (OWASP) best practices, HIPAA compliance, and even security research labs where certified ethical hackers try to tear apart your services and applications for security holes. When an application, piece of code, or service is given life, there are other core security aspects to be aware of.

For example, once you finish a piece of code or function in an application, do you do a penetration test against it? A part of DevSecOps can include understanding how a target tolerates a real attack and just how far an attacker can go. Further, you can also look at the infrastructure side of where and how the application or service operates. Specifically, you can work to identify infrastructure vulnerabilities like poorly patched or not properly secured machines, misconfigured network or WiFi connections, and even identity access and user management.

Finally, and this is an important part of DevSecOps, you can learn and better apply organizational processes, procedures, governance, and controls. This helps address not only technical weaknesses and challenges, but issues in organizational processes and procedures as well. Some great tools to use here would be NMAP, Metasploit, Acunetix, SQLMap, Portswigger, and Nessus. Of course, there are other tools as well; just be sure they fit your specific use-case.

Secure coding and code security analysis

When it comes to coding and security controls, you have three core areas of concern. That is, classification, assurance and automation, policy and processes. Each of these areas help create security controls that then inject availability, integrity, and confidentiality into the entire development processes.

So, for DevSecOps to work, consider adding these to your processes:

Classification

Data and services classification. Oftentimes, misclassification can lead to security issues. And, in really complex environments, proper classification can be a challenge.

Zones and access perimeter. Who has the keys to your kingdom and how are they getting in? Properly defining access and zone perimeters can go a long way in locking down your architecture.

Assurance and automation

SDLC controls and audits. This becomes a continuous process to ensure security. That is, your development lifecycle is now a direct part of the development security process.

Continuous code and artifacts scanning. It’s not just code. You’re looking at dependencies, access, libraries, and much more. Scanning this continuously allows you to find issues before the bad guys.

Manual code review. As much as I love automation and automated reviews of code and data, sometimes you need to do things manually as well. For really complex environments, manual code reviews are required.

Integrated and intrusive security testing. We discussed this earlier. Leveraging penetration and vulnerability testing to intimately understand your code and your application can really help identify potential threats.

Policy and process

Business and resiliency requirements. The business is a major part of the security process. And, a part of that would be to identify your resiliency requirements and how to protect your most critical business services.

Policies and compliance. Each business is different and will have different sets of policies to work with. Furthermore, things like General Data Protection Regulation (GDPR) and other compliance requirements can actually complicate things even more. A part of DevSecOps must be to understand privacy ramifications and where compliance plays a role.

Architecture and coding guidelines. You don’t have to do this part alone. Good partners can help you understand your architecture and actually help you improve coding guidelines. Basically, this helps you design a DevSecOps process that’s built around security and efficiency.

Finally, code security analysis can help you detect potential vulnerabilities that are often integrated and very complex. You can leverage powerful tools that will help you identify weaknesses in code at the exact line location and catch these issues very early during development. These tools also help with things like testing dependencies and services even when there is no code available. Tools like Fortify, Sonarqube, Coverity, and FxCop can help you with issue remediations, risk mitigation, testing hard-to-trace vulnerability sources, dependencies, and more.

Putting it all together

It never hurts to be a bit more secure. And, I’ve seen the evolution of DevOps where more and more security best practices are being injected into the entire process. In fact, DevOps itself has grown from just development operations to DevSecTestOps and more! The point is that the way you create applications, services, and code in general may be unique. But that doesn’t mean you can’t think outside the box and leverage new security tools to make your coding and development process even better. And, as mentioned earlier, none of this has to be done alone. Good partners can help with guidance, tool selection, and just be your second set of eyes to ensure your design procedures are both secure and efficient.

For more about DevOps and DevSecOps check out these InformationWeek articles.

Attributes Employers Look for in a Coder Beyond Coding Skills

Q&A: LightStep’s Spoonhower on Microservices, Deep Systems

Why Design Thinking Will Save Businesses From Themselves

Misconfigured Containers Open Security Gaps

Tech Nation Report: Robust Online Collaboration in DevOps