Integrating security into DevOps

Source – networksasia.net

Many developers today find themselves working in a DevOps (“development and operations”) setup in which an agile relationship exists between development and IT operations, with close communication and collaboration between these business units.

DevOps brings many advantages such as releasing features and fix bugs faster using Agile methodologies, CI/CD processes, and open source tools. However, traditional security activities can’t seem to keep up with this fast-paced tempo. How can you make sure security doesn’t get left behind?

The answer is putting security back in the spotlight during the development process. Instead of waiting to fix security vulnerabilities until after they wreak havoc on your applications, treat them like any other bug within your DevOps process. Hence the term DevSecOps is increasingly becoming a buzzword.

Inline and out-of-band activities

Activities that can be completely automated and run in a CI/CD pipeline without any human intervention are categorized as in-line activities. Examples include SAST, DAST, and open source management.

Activities that cannot be completely automated are categorized as out-of-band. Examples include architecture risk analysis (ARA) which identifies technical risks to a business due to technical flaws in a system’s design, threat modeling which maps out describes your system’s attack surface, and manual code review.

While most in-line activities can also be performed out-of-band, out-of-band activities can’t be performed in-line. As an example, there is currently no way to automate architecture risk analysis or manual code review.

Security issues must be treated with the same level of importance as quality and business requirements. If quality or security tests fail, the continuous integration server should break the build and email notifications sent out. When the build breaks, the CI/CD pipeline also breaks. Based on the reason for the broken build, appropriate activities such as ARA, threat modeling, or a manual code review are triggered.

“It’s important to have the capability to break the build when security issues arise,” says Olli Jarva, Senior Solutions Architect with Synopsys Singapore. “Developers need solutions and capabilities that identify and flag the problem early so that a timely fix can be introduced without delay.” To do this, Synopsys’ Cigital Secure CI/CD service offering aligns with the CI/CD process flow and injects AppSec solutions during the precommit, continuous integration and continuous delivery phases in a reliable and repeatable way.

Breaking the build

The first step is to determine the rule sets that will break builds on critical- and high-risk issues. All in-line activities can break the build. Out-of-band activities cannot break the build since they are not automated and are always manual or need a human to carry out the activity. While not every finding or security issue will break the build, points at which the build should be broken include:

1.  Crossing a threshold for critical vulnerabilities.
2.  Crossing a threshold for high vulnerabilities.
3.  Identifying a specific vulnerability such as SQL injection or cross-site scripting (XSS).
4.  Recognizing a zero-day vulnerability (e.g., Struts2 critical issue) using an SCA tool.
5.  SAST scan results indicate that one or more source files failed to compile. Thus, significantly reducing the overall confidence in the completeness and validity of the scan results.
6.  SAST and/or DAST tools running out of memory.

While this list isn’t exhaustive, the processes it outlines helps to identify code strength. It also helps the organization to prevent weak or insecure code from remaining undetected until later phases within the CI/CD pipeline.

It is important to incentivize teams to break their builds for security issues in addition to quality issues. The security team, DevOps team and Development team need to coordinate to make sure the process is well defined, tools are properly configured, and developers are ready to fix issues when the build breaks.

Security team responsibilities would include configuring appropriate tools for security and integrating them into the build pipeline. They can also define rules on which the build breaks and keep a dynamic record of outstanding security defects.

DevOps team responsibilities would include assisting the security team in breaking the build, notifying development teams of broken builds and why specifically the build was broken. Development team would then be responsible for fixing the issues.

Security is too important to be an afterthought. Just as you would break the build when code doesn’t compile, or when unit tests fail, it’s critical to mandate breaking builds for security issues as well.