How To Move From A DevOps To A DevSecOps Approach

Phill Harris
Head of Support
NNT - New Net Technologies

• Share
• Tweet
• Share

• Share

The focus of DevOps is to significantly decrease and streamline the development to operations life cycle of a system as if moves along the DevOps pipeline. A DevOps pipeline pays close attention to testing the code as soon as possible in order to identify and fix any problems. DevOps is well recognized and has been adopted by many organizations, but it leaves the security assessment as an implied task. The result is, as an organization strives to improve their DevOps process, that any security assessment is left as an afterthought.

A development pipeline designed with a security assessment at the end of the process has obvious problems, specifically, should that assessment discover issues that require development fixes, delays will be introduced. It’s likely that the engineer responsible for the area of code that requires attention will have already moved onto another task, requiring the engineer to re-familiarize themselves with that portion of the code. This of course will impact the development of new features as the fix is developed, taking up already limited resources and valuable time.

DevOps and DevSecOps (Development, Security, Operations) are closely related and very much share the same goal: to develop and build in the most efficient manner possible. The main difference is focus - DevSecOps quite literally puts security at the center of the process. With the addition of security, we are of course still focused on developing quality for production, but we are considering the security at all times as we move down the pipeline.

“Considering the security at all times” – now let’s break that down. It’s an easy statement to make, but how exactly do we go about doing this? Let’s consider some security centric stages that might be added to the pipeline to help your team consider security at all times in our next section.

It’s important to note that there is no definitive pipeline for DevOps and DevSecOps; the different stages in your pipeline will be closely aligned to your organization’s specific requirements. Having said that, here are some typical security stages you might consider when adopting DevSecOps in your organization:

• Source Composition Analysis (SCA) – With a modularized approach to development we do not write each and every line of code and as such, it’s essential that we track the 3rd party libraries that we are using and check all libraries for concurrency and vulnerabilities.
• Static Application Security Testing (SAST) – Along with SCA, this type of testing is performed early in the development cycle and is not a one-time only process. All code that is deemed to be completed should be assessed by SAST. There is no need for a built application, as SAST checks the code looking for the easily identifiable vulnerabilities.
• Dynamic Application Security Testing (DAST) – The next logical step from a vulnerability testing standpoint is DAST. DAST requires a deployed application and tests in the runtime environment and as such, has the potential to identify issues that would not be detectable just by looking at the static code.
• Infrastructure Scans – Ideally, within our pipeline we have infrastructure as code. Using scripts, APIs and containerized technology we can build a variety of likely deployment scenarios to check for vulnerabilities. It’s worth noting that the introduction of any infrastructure, such as docker images, for example, may well also bring vulnerabilities and so, a scan of those images with a commercially available scanning tool such as NNT’s Vulnerability Tracker should be used.
  The results of a scan from Vulnerability Tracker will need to be analyzed carefully to distinguish between the vulnerabilities linked to the code and the vulnerabilities linked to the infrastructure. It is unlikely that you will get to a point of no vulnerabilities and so a decision will need to be made regarding which vulnerabilities are acceptable in order to move forward. For more information, read our recent blog post – Top 5 Vulnerability Management Best Practices.
• Compliance Scans – It’s not unusual for an organization to follow one or perhaps multiple compliance standards such as the Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), Federal Information Security Management Act (FISMA), Sarbanes-Oxley Act (SOX) and as such, systems within the organization will be exposed to a configuration or build standard. Because of this, you should have a stage within your pipeline that tests against systems which are configured with the particular brand of build standard that you follow.

This can be achieved by using a tool such as NNT Change Tracker. Change Tracker can be driven via its REST API to provision system monitoring and configuration checking in order to assess how your project will behave within the compliance standard into which it will be deployed.

I have mentioned a few NNT tools that can be used within this blog, but there are many other solutions available that would help address the needs explained in the stages above. However, DevSecOps, and DevOps for that matter, are not exclusively addressed by products, either commercially available or open source. These concepts are only formed with an equal blend of people, processes and tools. The challenge is to be secure by default, by culture, by tooling, and by embedding security processes into the development pipeline that addresses risk.