Implementing DevSecOps: Some Practical Considerations for CISOs

Originally published by CXO REvolutionaries.

Written by Sam Curry, VP & CISO in Residence, Zscaler.

“The perfect is the enemy of the good.” – Voltaire

In early development models like Waterfall – where all processes were performed sequentially – a high wall separated build teams and run teams, development code and object code. Then came the Agile Revolution in recognition that these processes were too long, their scopes too siloed, and punting the code over the wall for someone else to deal with was...kind of wrong.

The Agile Manifesto asserted that code creators and those who ran and maintained the code should be one and the same. Builds would no longer be epic, monolithic efforts but short, iterative improvements. The resultant code would be more reliable, more manageable, and more valuable.

Hence the marriage of "Dev" and "Ops" and the birth of the coding process called DevOps. Eventually, with the rise of cloud computing, this spawned a process of continuous integration/continuous delivery (CI/CD). CI/CD is agile DevOps pushed to its logical conclusion. While both the left and the right ends of the CI/CD spectrum seek to span the whole, I would suggest it's more important to collaborate on interoperability, aligning with industry standards, and encouraging the same of vendors.

It’s about moving even further away from huge, painful, and slow release cycles of monolithic software, and toward shorter and more numerous release cycles that allow for faster total progress as the codebase evolves. The process can be applied whether the code is intended for internal use by employees or externally by customers, clients, and partners. It yields benefits for both worker productivity and the bottom line.

Security enters the chat

For CISOs, CI/CD is also a natural mechanism by which to bake security into the software development life cycle earlier and more comprehensively. Instead of throwing a new build over a metaphorical wall into operations/production, you try to discover a larger percentage of security issues pre-rollout.

As a rule, earlier discovery is easier and less costly for developers to fix. It also substantially reduces the potential business impact, because a security flaw that never even hits production is far harder for malicious actors to find and leverage.

As modern CISOs act as a link between security and the business, they face a juggling act. Among other priorities, they must:

• Implement policies for separation of duty, segmentation, and the ongoing authorization of users
• Secure services and their resources as comprehensively and consistently as possible, everywhere they’re used
• Demonstrate this security in activities ranging from risk management to auditing and from integration to operationalization
• Integrate development teams and operational teams as naturally as possible while also bolstering security
• Accelerate new service rollout without compromising either performance or security
• Accelerate bug discovery and remediation

So if you want to logically and seamlessly add a security perspective into the software lifecycle spanning different teams and perspectives, how do you best do that?

One answer is to transform DevOps (or Dev and Ops) into DevSecOps — that is, literally add cybersecurity talent to the lifecycle so that hard-won security wisdom can guide development and operations personnel. This baking in of security into source code is a key element of a Defend Forward approach, in this case focused on resilience, that I have previously recommended the private sector adopt.

How DevSecOps gives life to secure code

Think of the secure software development lifecycle as a kind of lifeform that grows and changes over time. The code generated by developers is the genetic basis, or genotype, of this life-form. The expression of that code in operations environments, how it runs, is its phenotype.

The “Sec” in DevSecOps is constantly situated between the genotype and the phenotype and can collaborate with both sides to ensure the service securely does what it’s meant to do in the right ways for the right people. This increases the odds of a successful and secure “organism,” which also empowers Dev teams to focus more directly on development and the Ops folks to focus more directly on operations (their core competencies).

Or consider the Channel Tunnel (a.k.a. the Chunnel) that connects England and France. This tunnel is just more than thirty miles long and mostly underwater; it was also dug simultaneously from both sides.

In this sense, its engineering reflects the way DevOps or Dev and Ops teams simultaneously aim for a secure service, each taking action to drive that outcome.

What happens if the two teams aren’t aligned? The tunnels miss each other, or in software terms, the service’s security is inadequate. (The two teams actually dug the Channel Tunnel to an impressively accurate tolerance despite the enormous logistical challenges).

This is where Sec folks can come in extremely handy. They know what the DevOps/Dev and Ops teams are doing, and because their own focus is security, they can help both sides align their processes with security best practices and the superior business outcome those best practices can and should generate.

Moving from metaphor to implementation

These ideas are still all fairly abstract, though, so I’ll make a few practical suggestions for running an effective DevSecOps shop. Much attention has already been paid to improving the secure software development lifecycle (SSDLC) in terms of source improvement on the left and vulnerabilities, configurations, and posture management on the right, so this advice focuses on additional areas.

Based on my experience, I suggest CISOs:

• Products – Get used to creating a security bill of materials (SBOM). To optimize security on a project, it is essential to know, as comprehensively as possible, exactly what code, drawn from what sources, was utilized in creating a given package or build. An SBOM is essential both for technological reasons (is the service’s code actually as secure as you think it is?) and business reasons (what if your company’s going public, and you need to prove you actually own the intellectual property involved?). At a time AI is increasingly “generating” code – which often really means that it’s drawn from somewhere on the Web – an SBOM can help mitigate the possibility of AI-generated security problems.
• People – Take the opportunity for champion-building. Embedding a security representative into Dev and Ops teams is an opportunity to extend security’s influence throughout the organization. I have even gone so far as to suggest the sharing of OKRs. Ask DevOps to take a KPI for cyber while you take one for uptime. This demonstrates that the teams are working toward the same shared purpose and builds trust among the departments.
• Process – Don’t be the department of “no.” Security leaders must be present early, not as watchdogs but as partners in the process of developing secure products and solutions. Realistically, organizations’ SSDLC maturity will be at different stages, and there’s always room for improvement, whether that entails incorporating more AI/ML into the process or streamlining how Dev and Ops work together.

Finally, it’s imperative to lock down code, both source and object. Then lock it down again. All the best-in-class security tools, theory, and talent in the world won’t suffice if your project codebase is accessible online by malicious actors bent on engineering a supply chain attack like the world has seen several times in recent years. You simply cannot afford any failure of security on this sensitive subject, so once you have a champion or two, make sure that champion allocates time and energy not just to the security of the code per se, but also to the repository where it’s stored, including who accesses it, how, and under what circumstances.

When in doubt, I recommend erring on the side of caution.