DevSecOps – Dramatically Improving your Information Security Quickly



“Shift Left” might be the center square on most “buzz word bingo sheets” these days. For most of us, it really means getting the folks “upstream” from us to become more involved with, or even take over, part of what we do. If you’re the one upstream it might feel like someone is asking you to do their job.

What does doing DevSecOps actually mean?

In this context, what we mean is that instead of waiting until the design is done and then getting the Information Security folks involved… or, instead of waiting until the code is written and then getting the Information Security folks involved… instead, our information security folks work with architects to address security concerns and design systems to increase our security posture before writing a bit of code. It means providing development teams with tools and information that help them avoid security issues in the first place, rather than discovering them in formal testing (or worse, in production!).

Enabling DevSecOps with technology

From an architecture perspective, this means using contemporary approaches that minimize exposure and vulnerability surface area. Using containers changes the game from traditional code execution to sidestep buffer overruns, for example. With just a copy of the container image being exercised, we can replace that container with a fresh copy on a routine basis, and when any parameters are breached. We can even use machine learning to identify unknown attack types or unexpected behaviors and replace the container immediately, so any buffer overrun is eliminated, there is no residual trace. With APIs we reduce the surface area of attack, and again can define the allowable parameters of the API call with greater ease and precision than before.

These steps also enable development using tools that have far greater capabilities than the IDEs and development tools we’ve used in the past. With the advent of DevOps and the automation of the software pipeline, we’ve developed the ability to run automated testing. In addition to the benefits of ensuring that all necessary testing is executed with captured results, we also have the ability to change the way we do testing, especially security testing. Many times, the vulnerabilities that are discovered later on, were actually relatively easy to identify much earlier, had we actually looked.

Empowering people for DevSecOps

In addition, helping developers by giving them tools and the knowledge of how to use those tools can have the biggest impact on improving our information security posture.

For example, every developer knows better than to embed system access credentials into code. But it can be quite tempting, especially very early in development and/or with inexperienced developers. Sometimes that is forgotten in the pursuit of deadlines and catching up on other work. Code reviews don’t always happen like we’d like to think they happen. But, introducing Software Composition Analysis as an automated test in the code integration process is very straightforward and very low cost. There is great open source and free software that you can run on the code in the integration process that looks for standard coding practices (and lack thereof).

Similarly, Static Code Testing is also very straightforward, and looks at pre-compiled code for known vulnerabilities. There are many sources for known vulnerabilities, such as Mitre’s CVE (Common Vulnerabilities and Exposures) – https://cve.mitre.org/. In fact, over 60% of organizations who have had a breach suffered from an exploit of a known vulnerability which they had not yet remediated. (Higgins, 2018). Giving developers the ability to execute this kind of testing as they are developing their code enables the fastest, easiest, and cheapest way to ensure these kinds of problems don’t reach our production environments.

Similarly, equipping Site Reliability Engineers with these kinds of tools, along with the knowledge of how to use them enables them to ensure their infrastructure landscape becomes far more resilient. As SREs continue to automate infrastructure, these tools become increasingly useful, especially when implemented with infrastructure as code and automated patching approaches.

The outcome of DevSecOps

In each of these examples, we’ve moved the focus of information security from testing for it after the code is complete, to the left, or upstream. By doing so we’ve eliminated opportunities for problems much earlier in the process, and in doing so have reduced the cost and impact. We have eliminated rework that is compounded when work is progressed through multiple steps or teams, and the result is much faster delivery of higher quality results.