A complete beginner's guide to blending DevOps and security

DevOps can be daunting enough for those brand-new to it. And it becomes even trickier when you begin to add security into the mix. If you want to build out your DevOps and security programs in order to improve your application security initiatives, vulnerability testing and verification have to be baked into your day-to-day processes. The DevOps/DevSecOps approach allows for security to be introduced earlier in the software development lifecycle. Instead of performing security checks once code is fully developed and has gone into production, the process must begin much earlier so both development and security professionals can test (and provide resolution) for software flaws along the way -- even if it's in small code snippets here and there. Modern development environments, static source code analyzers and dynamic application security testing tools make this process much easier. Interactive application security testing (IAST) is an evolving approach that introduces automation and related efficiencies in security testing to ensure both static and dynamic approaches are taken.

The long-term goals of DevOps and security are to prevent vulnerabilities from being introduced upfront and then to catch and resolve them quickly when they do exist. It is critical to reduce the overall attack surface and maintain proper visibility and control at the network and application layers. Visibility and control are the essence of what DevSecOps is all about. You'll get out of application security exactly what you put into it. It has to be treated as a core component of an overall security program, not just something developers, QA professionals or IT operations staff is responsible for. Don't implement DevOps or DevSecOps just for the sake of doing it. Collaboration, speed and agility mean nothing if security is not integrated properly and low-quality software is still being produced.

The overall best approach to addressing DevOps and security today requires just a handful of things:

• Have the right people on board. The team should include not only development, QA and IT professionals but also those responsible for application security oversight, internal auditing and compliance. Even higher-level business executives should be a part of these discussions and the decisions that are being made.
• Outline specific security requirements. This involves more than just application security basics, like passwords, encryption and so on. Detailed security requirements must include operations-specific issues at layers below the application, including database setups, cloud versus on-premises configurations and integration with existing network security controls, to ensure proper oversight.

  I have seen plenty of situations where DevOps and security were well-integrated into the business, but still, numerous high- and critical-rated vulnerabilities were uncovered when the software was given a fresh look.

• Know what you have. Many organizations aren't aware of the extent of the existing code and applications. All it takes to lead to gaps in your application security program is to overlook critical applications and data or, just as bad, acknowledge them and assume they don't need attention. In certain situations, this can be a simple exercise that developers and/or security operations team members can perform quickly. Other times, it might require a more in-depth -- i.e., cross-departmental -- review/audit of applications. Be sure to look at internal, external and third-party code. It all counts when it comes to DevOps and security.
• Understand how it's at risk. Manual code reviews and simple vulnerability scans are not enough, especially when they're done after the fact. Proper security assessments that include vulnerability and penetration testing, static source code analysis and perhaps even IAST are essential for finding the flaws so they can be fixed. Keep in mind that, just because security vulnerabilities have been uncovered by the tools or even by manual analysis, it does not mean they necessarily matter to the business. This is why it's important to get the right people on board and establish reasonable security standards so you'll have something to aim for.
• Create a plan to properly address the risks, and see it through. Sometimes, one specific vulnerability that's uncovered can help all DevOps and security team members produce higher-quality applications moving forward. One of the biggest gaps I see in application security programs is people who go through the motions to find and report on security flaws and then do nothing about them. Perhaps, in some cases, it's justified because there is no real risk or there is simply no budget to properly address an issue. Still, you need to see things through -- at least to the point where risks are reasonably mitigated. Otherwise, you've got a liability on your hands that's only going to get worse, especially once an incident or breach occurs.

DevOps and security, or DevSecOps, are not the be-all, end-all solution to all of your challenges. With culture, skill sets, budget and the growing need to define the outcomes of application development and security, you're going to have to do the best that you can with what you've got. I have seen plenty of situations where DevOps and security were well-integrated into the business, but still, numerous high- and critical-rated vulnerabilities were uncovered when the software was given a fresh look. An unbiased perspective and the use of different security tools and known hacking approaches are often what's needed to initiate the cleaning up of risky code bases and get the applications back on track for a smoother DevOps experience.