DevSecOps 101, or How to Truly Keep Software Secure

A lot has been said about DevSecOps from experts, practitioners, pundits and vendors (even us). We’d also like to take this opportunity to offer up our own viewpoint on the subject. CloudBees believes in order to keep software secure, you must go beyond just securing the code you’re developing and also securing the pipeline that delivers that code. Plus, to be really secure, you need to have systems and tools in place to immediately mitigate - and then remediate - vulnerabilities that are found in production. 

There’s no such thing as DevSecOps.

If you’re doing it right, the “Sec” is silent. Security becomes an integral component of your entire SDLC. Think of it as “Shift Security Everywhere.” Yes, the code must be secure, but so must the mechanisms you use to get it to production. You also have to be vigilant to vulnerabilities that will happen once your code is released. (They will happen, which brings us to...)

Perfect isn’t possible so don’t even try. You better be world-class on discovering vulnerabilities prior to release as well as responding to them post-release. Practice failures. Scan everything, everywhere, constantly.

The time between mean time to detection (MTTD) and mean time to repair (MTTR) is the time you are exposed to that vulnerability. Put systems in place to automatically mitigate the problem via feature-level kill switches or well-rehearsed, surgical roll backs. Closing that vulnerability upon detection gives you a safety buffer to develop and thoroughly test a fix. Feature flags can help with this.

Basic information security principles are founded on CIA: confidentiality, integrity and availability. Keeping software secure requires (CIA) of that software. Ensuring confidentiality means using RBAC to ensure segregation of duties as well as managed visibility. Ensuring integrity means guaranteeing not only the right right bits or code are used but also that they are the right bits of code. Ensuring availability means everyone has the right access and privilege levels to do their job and also your software delivery systems are resilient enough to be always available. 

Problems will happen (see above). Rather than shooting the messenger when they do, applaud the messenger who found it (hopefully before the bad actors have found it). You’ve expected and practiced for this, right? Celebrate when your practice and forethought has paid off (after you have the problem fixed, of course).

Treat all automation artifacts the same level of assurance you treat any source code. They’re as important to your security posture as the code you develop. Version them. Audit them. Review, revise, and update regularly. Retire the ones that don’t fit any longer.

If it’s not automated, it’s not auditable nor protectable. If it’s a manual step, it can’t be controlled, audited, or mitigated easily. Automate every security measure so it’s part of the process.

Make sure auditors are at the table with you, not across from you. If you have security and governance built in the right way, they will be able to get what they need themselves. Plus, the data you have is immutable (because you’ve protected that, too, right?).

Security is everyone’s job, but not everyone needs to know how to fix a vulnerability, nor does everyone need to know how to detect or mitigate one. Make sure the right people know how to handle their individual responsibilities for keeping software secure.

Or maybe better, knowing that you’ve baked tools and processes into the entire system. You’ve got systems in place to detect and mitigate problems, you’ve practiced failure, and you’ve automated everything you can. When something happens, you’re prepared.