Three Easy Steps to DevSecOps

There's a lot being discussed these days about secure DevOps. What does it mean to do continuous integration and deployment in a secure way? Is it about securing the pipeline itself? Or, is there more to it than that?

We have your back. There are just three basic steps to DevSecOps.

1) Build security in

This is perhaps the biggest leap in getting to secure DevOps pipelines but by far the most critical.

A big part of the reason for doing DevOps in the first place is to achieve a level of consistency and repeatability through codification and automation. If you can code your deployment, then there's less chance to fat finger something when it comes time to ship it. Similarly (on the OPS side) if you can define your Infrastructure as Code and use the same definitions at every stage of the SDLC then in the same way you can both a) avoid the delays of needing someone to manually set up the environment, and b) eliminate the mistakes inherent with deploying manually.

So how does that translate to Security?

Easy. Simply take the same software defined development and operations steps and insert codified and automated security checks. Most of today's modern security testing and assurance platforms are either scriptable via a command line integration or via an API. SourceClear is no different. You can run the SourceClear agent via the CLI in a GitHub CI Runner on every build, or just as easily add the shell version to your Jenkins post-build actions so that on every deployment the checks will run.

2) Keep your code fresh

A big reason for implementing SourceClear is to make sure that you identify open source vulnerabilities in your code, especially those that have yet to be published. This is why our premium data is so important as it allows you to be aware of flaws that otherwise would not be visible.

However, another equally important factor in maintaining good software security is through implementing policy and practice to ensure code freshness. The reason for this is that when a fix for a vulnerability is patched, it's usually implemented first and sometimes ONLY in the most recent version of the software. The goal is to keep the delta between what you have deployed and which version is fixed to be as small as possible. If you have version 1.1 as a dependency, but 3.7 is what's being actively maintained then the effort to plug in a fix will be much greater for you when the flaw is found than if you had kept pace with new versions as they were released.

3) Fix it fast

This last one is closely tied to #2 but important enough to warrant having its own bullet. Your ability to protect your company by fixing security defects in the software you build and the open source libraries that ship with it is only as strong as the speed by which you can a) identify flaws, and b) mitigate them.

This is a reason why you do DevOps in the first place and why moving to DevSecOps is so important. If you have security built in, everything-as-code, and keep your open source libraries up to date, then when the next Apache Struts vulnerability comes along you will be able to patch it quickly because you'll be a simple minor version behind, and you'll be able to push out a verified secure build without even thinking about it.

Does this sound too good to be true? It's not. Our customers are doing this every day.