DevSecOps: Eight tips for truly securing software

Essential guidance for keeping software truly secure

A lot has been said about DevSecOps from experts, practitioners, pundits and vendors. However, recommendations that start and finish with securing code leave critical gaps.

In order to keep software secure, businesses must go beyond just securing the code they are developing to also secure the pipeline that delivers that code. To be really secure, organisations need to have systems and tools in place to immediately mitigate – and then remediate – vulnerabilities that are found in production.

While seemingly controversial, the truth is that there is no such thing as DevSecOps. If businesses are doing it right, the “Sec” becomes silent. Security should be an integral component of your entire software delivery life cycle (SDLC), not a separate way of working.

A good way to think about securing software is to think of it as “Shift Security Everywhere.” Of course, the code must be secure, but so must the mechanisms used to get it to production. Furthermore, businesses also need to remain vigilant to vulnerabilities that will happen once the code is released.

This mindset shift can be daunting for businesses simply trying to secure their organisation and its code. The following eight tips are crucial and provide good guidance for organisations looking to keep software truly secure.

Keep Software Resilient, not Invulnerable

It is nearly inevitable that vulnerabilities will happen. Striving for perfection is nice in theory, but achieving it is not possible. Instead, developer teams need to focus on trying to discover vulnerabilities prior to release, but also be quick to respond to the vulnerabilities post-release. If teams can practice the potential failures by scanning everything, everywhere, constantly then they will be in a much better position to recover faster.

Close the Gap Between MTTD and MTTR with MTTM

The time between mean time to detection (MTTD) and mean time to repair (MTTR) is the time businesses are exposed to that vulnerability. Systems need to be put in place to automatically mitigate the problem via feature-level kill switches or well-rehearsed, surgical roll backs. Closing that vulnerability upon detection provides a safety buffer to develop and thoroughly test a fix. Forward-looking enterprises use feature flagging management solutions to expedite their continuous delivery and bring new innovation to market faster, with less risk.

Apply Confidentiality, Integrity and Availability (CIA) to Software, Not Just Data

Basic information security principles are founded on confidentiality, integrity and availability. These three core principles are the key to keeping software secure. Ensuring confidentiality means using role-based access control (RBAC) to ensure segregation of duties as well as managed visibility. Ensuring integrity means guaranteeing that the right bits of code are used and 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 that their software delivery systems are resilient enough to be always available.

When Problems Happen, Culture Matters

Problems will happen. Rather than shooting the messenger when they do, applaud the messenger who found it; hopefully before the bad actors have found it. The teams should have expected and practiced for this, so the team should also celebrate when the intentional scanning and forethought has paid off (after the problem has been fixed, of course).

All Software Components Must be Treated Equally

Treat all automation artifacts with the same level of assurance as any source code. Automation artifacts are as important to the security posture as the code being developed. Version them. Audit them. Review, revise and update regularly. Retire the ones that do not fit any longer.

Automate Everything

If it is not automated, it is not auditable nor protectable. When processes are manual, they cannot be controlled, audited or mitigated easily. Automate every security measure so that it is part of the process.

Auditors Are Not the Enemy – Delight Them Instead!

Many businesses can see auditors as the enemy; however, this is a mistake. Instead, make sure the auditors are at the table with you, not across from you. If security and governance is built in the right way, the auditors will be able to get what they need themselves. Further, the data collected from the automated process that are in place is immutable (because that has been protected, too, right?).

Not Everyone Needs to Be a Security Expert

Security is everyone’s job, and all employees can do their part to stay vigilant and help the development and security teams. But not everyone needs to know how to fix a vulnerability, nor does everyone need to know how to detect or mitigate one. What’s important is to make sure the right people know how to handle their individual responsibilities for keeping software secure.

To truly secure software, security tools and processes should be baked into the entire software delivery life cycle. These include putting systems in place to detect and mitigate problems, practicing failure and automating everything you can. It is key to remember that there is no such thing as DevSecOps as when businesses are securing their code effectively and as an integrated part of their entire business, the “Sec” becomes silent. By embracing these eight steps, business will be prepared to act if any security issue arises.