Many organisations have turned to DevOps, an agile blend of development and operations, to transform the way they develop, deploy and support software. But security concerns are increasingly becoming a bottleneck that undermines the business value derived from DevOps. To answer this challenge, many organisations are embedding security into their DevOps approach - they’re looking to create DevSecOps.
While the case for DevSecOps is well known, organisations often struggle to unlock all the desired benefits. Having worked with dozens of organisations to embed agility and security, we know there are four secrets to making a success of DevSecOps:
Before embarking on a DevSecOps change programme, organisations need to understand the quantifiable benefits they’re aiming for. Many leave this out of their strategies, meaning they struggle to see where they’re going or how to measure success, which makes it almost impossible for organisations to consistently commit to funding.
A clear DevSecOps strategy should articulate the desired benefits, such as enhanced customer satisfaction resulting from fewer patches and lower costs from teams resolving security issues sooner. It’s also important for the strategy to show the link between funding, action and benefit to bring accountability to the transformation programme.
It’s crucial to engage key stakeholders during this strategy development. To maintain momentum, stakeholders like the product owners and Chief Information Security Officer must understand the benefits of DevSecOps for their part of the business. A successful programme must also recognise the dependencies on the wider organisation, such as hiring practices in HR or IT tool selection strategies. Without acknowledging these dependencies, there’s a risk some stakeholders won’t come along on the journey.
Embedding security throughout the development process is a cultural challenge. To collaborate effectively, development, security and operations teams must understand how each other works. Security teams tend to use specialist vocabulary, for example, which can be a barrier to engaging DevOps teams. While DevOps teams thrive on rapid progress, something that could make security experts, who want time to check things from all angles, nervous.
To successfully embed a culture change, organisations need to educate teams on the importance of DevSecOps as a single function and measure progress regularly. That starts with embedding key principles in people’s minds – developers need to see why security matters, security experts need to understand how to work in an agile environment, and operations teams need to bring security teams into ongoing maintenance. All while leaders set the right collaborative tone.
When everyone understands why the switch to DevSecOps is happening, it’s important to consistently track progress towards the cultural change. You could do this through staff surveys that measure how excited people are to make improvements and learn new skills, or through manager reports on how ‘us and them’ attitudes are reducing.
While having teams of people who can perform multiple roles in a DevSecOps setup would be the ideal, it’s almost impossible to achieve. Most people specialise, and those with a wide range of skills don’t come cheaply. But with the right training offering key insights into the various specialisms, diverse teams of experts can still make a success of DevSecOps.
To achieve this, a comprehensive training strategy is vital. Chief Product Owners need to learn to think about security when defining backlogs or objectives and ensure traceability of security and resilience requirements through the development pipeline. Architects need to think about security when defining acceptance criteria and learn techniques such as Threat Modelling. Developers and testers must work with security experts to learn how to run security tests for each sprint. And operations teams need to better understand security metrics and how to identify security issues.
Of course, even with clear objectives, a collaborative culture and the right training, switching to DevSecOps isn’t as simple as merging agile development and security processes. Those processes need a redesign to adopt the best of both worlds. This can be very challenging due to inherent differences between agile and security. For example, when recently working with a financial services firm, many agile processes weren’t compatible with their legacy security testing tools and techniques, so they needed to retool.
Each process redesign needs to be managed as a change initiative or project. That starts with identifying, documenting and assigning ownership for each process that needs to change. For each process, you then need to identify its stakeholders and get their buy-in ahead of the transformation. All stakeholders need to agree the changes in advance and create delivery plans for them. And you’ll need clear metrics for success so you can track progress for at least six months. Don’t be afraid to rework processes if you’re not seeing the results.
Making security an integral part of agile development and operations unlocks significant value by accelerating delivery and enhancing customer trust. As DevOps comes to maturity in many organisations, now is the time to use what you’ve learned and build a comprehensive approach to DevSecOps.