Modern software leaders are all too familiar with the concept of moving the goalpost. The business demands they deliver new features faster, and when they do, the feature must then be compatible across platforms.
These days, the goalpost has moved again: Now the business wants quality software quickly –and they want it to be free of critical vulnerabilities, compliant with data privacy laws, and easily adaptable to new requirements the business demands in response to the market.
DevSecOps was born to keep up with these requirements. The goal of DevSecOps is to unite software development, operation, and security into a collaborative system where all stakeholders work together to proactively address security issues before software is developed and through its deployment.
Getting there is, of course, easier said than done. The four principles outlined below are drawn from the direct experience of putting these ideas into practice.
[ Want a shareable primer on DevSecOps and its benefits? See What is DevSecOps? ]
1. Define meaningful metrics that keep teams aligned
The three discrete functions represented by DevSecOps are motivated by very different incentives. The Dev group is measured by its ability to deliver new features in accelerated timeframes. The Ops team is judged by the performance and availability of the infrastructure that supports the application portfolio. While DevOps emerged to unify these two areas in the name of improved efficiency, it became evident that security was too often bolted on as an afterthought. Applications were insecure and processes became bogged down.
It’s essential to align the DevSecOps practice with business goals by applying a commonly understood framework such as Objectives and Key Results (OKR). Such a framework serves to establish a baseline of objective-based outcomes on which all stakeholders agree. It also helps the teams define and prioritize a shared set of metrics that serve as the unifying source of truth. For example, one objective might be to increase the number of releases to the production environment with an underlying key result to decrease the Mean Time to Detect failure from two hours to 20 minutes.
[ Also read: OKRs and KPIs: 6 counterintuitive tips for leaders. ]
2. Bake security in, don’t brush it on
If the past few years have taught us anything, it’s that security vulnerabilities can be introduced into an application at any point in the development lifecycle. Too many organizations adopt a piecemeal approach of tools and staffing that address key issues but still end up leaving gaps.
Gaps occur when security doesn’t touch every part of the development process. A mature DevSecOps practice seeks to address these concerns by baking security into all phases of DevOps, shifting security left to include pre-production all the way through production and release of new software features or updates.
Baking security in also means that security becomes the responsibility of every team member, at every phase of the software development pipeline, from the CIO to the application architects, developers, and site reliability engineers (SREs). Concepts such as Zero Trust Security and Secure-by-design need to be mandatory design principles rather than nice-to-have options.
3. Think holistically, act iteratively, automate appropriately
Modern software is increasingly assembled, not developed. Gartner estimates that the actual amount of code a developer writes represents less than 10% of the final application. Accordingly, a mature DevSecOps practice must continuously think about the sum of the individual parts lest they get mired in the minutiae of their sprint cycles.
So, while automation for simplification, repeatability, and speed is key for shifting security to the left, be wary of automation for the sake of automation itself. Automate as much as possible after you standardize your technologies and processes with repeatable configuration and change management.
[ What DevSecOps tools might your team consider? Read also: 5 DevSecOps open source projects to know. ]
Too often, we’ve seen teams work to automate processes that change too frequently or haven’t been standardized. This results in a “thicket of tickets” maintenance nightmare in which team members spend more time tracking and remediating issues than reaping the benefits of automation.
4. Cultivate a culture of accountability
At the heart of every mature DevSecOps is an intentional culture that facilitates collaboration and encourages shared responsibility. But when everyone is responsible, is anyone really accountable? And perhaps more to the point: How do you get people with very different skill sets, personalities, and motivations to work together effectively?
Just as the Agile Manifesto emphasizes individuals and interactions over processes and tools, a mature DevSecOps culture is more about people and culture than it is about the tools people use to do their work.
A culture of accountability is characterized by shared responsibility with guiding principles that are forged through actions. CIOs who create such a culture empower individuals across the organization to embrace behavioral change. In other words, it starts at the top but percolates from the bottom up. Sharing lessons learned and modeling self-awareness are ways CIOs can “be the change” and develop the culture of accountability they are working to cultivate.
There’s little doubt that software will continue to eat the world. But the appetite of modern software will only be satisfied if all stakeholders are ordering from the same menu. A mature DevSecOps practice will enable CIOs to evolve their strategy from reaction to resilience and enable them to deliver innovations that transform the business.
[ How do containers and Kubernetes help manage risk? Read also: A layered approach to container and Kubernetes security. ]
