Lawrence Crowther from Snyk outlines steps which can support the integration of a DevSecOps culture across organisations.
When DevOps emerged more than 10 years ago, the main focus was to bridge the gaps between Dev and Ops teams by introducing automation to the processes of building, testing and deployment of applications. What started as a loose collection of standard practices shared among high-functioning software engineering teams transformed into a modern statement of engineering culture and process: DevOps. At this point, security certainly played a role but wasn’t always a priority.
As development teams continue to deliver more rapidly and more frequently, security teams are finding it difficult to keep up and often end up being the bottleneck in the delivery pipeline. For this reason, bringing security early into the DevOps process from the outset – in other words, embracing a DevSecOps culture within a business – has become increasingly important.
Companies should think of DevSecOps as the natural continuation of DevOps, rather than a separate idea or concept; it is an evolutionary step, rather than a revolutionary one. Embracing a DevSecOps culture enables development teams to secure what they build as they build it while creating more collaboration between development and security teams. This allows security teams to become a supporting and enablement function helping to increase developer autonomy while also providing oversight to the business. Eventually the term DevSecOps will no longer be required, and security will be a natural part of software development.
As businesses increasingly understand the importance of embracing a DevSecOps culture, there are three pillars they should consider when moving towards implementation: people, process and technology. DevSecOps principles build on these three intersecting parts, by eliminating silos and creating a collective focus.
People: empowering the team
A modern security culture and mechanisms that work for, rather than against, people are crucial to making security work. Moving to DevSecOps starts by challenging the way traditional security teams integrate with the wider business. Strong links between development, security and operations teams ensure earlier feedback on the quality of the code, software or application from a security point of view, and in turn, reduces the costs of implementing fixes.
Traditionally, development was responsible for fast delivery, security was responsible for application security, and operations were responsible for stability. DevSecOps removes these silos and unites all three roles in a common goal of rapidly delivering secure and stable software.
The other part about empowerment is ownership. Increasingly, developers are responsible and taking ownership of not only the application code but other dependencies that the application has. Such as the configuration to build types of infrastructure and cloud services to support the application.
Process: supporting the new DevSecOps culture
Embracing a DevSecOps culture requires processes in place to ensure smooth adoption. This includes breaking down the barriers of policies and workflows coming from the top that have traditionally got in the way, and instead encouraging shared responsibility.
When shifting to DevSecOps, the right balance between automated gating and manual gating must be found. Traditional security strategies involved setting key milestones at which security activities occurred and not allowing the process to progress past that milestone until an acceptable result was achieved. In some organisations with particularly mature models, operations implemented similar gates before software could be deployed. However, this kind of gating model creates lengthy feedback loops that slow software delivery and ultimately reinforce silo-based thinking. Whereas the key to DevSecOps is creating faster feedback loops.
Mutual accountability is a concept that must be embraced, as a replacement to gating, and supported by subsequent process changes. Development, security and operations personnel should be working together to ensure all the business objectives – leading to the creation of fast, secure and stable software – are achieved. A good place for these collaborative teams to start is with threat modelling to identify the security threats, the weaknesses that allow the threats to be exploited and then identifying compensating controls that can be implemented to mitigate threats.
Processes by which security and operational best practices are implemented throughout the delivery pipeline are crucial in establishing this collaboration and accountability.
Technology: paving a path to success
Of course, putting the processes outlined above in place requires the support of tools and platforms. While people and processes work together to ensure the adoption of this new DevSecOps culture, it can fall apart if the underlying technology doesn’t accommodate the changes.
Often, when people think about AppSec technologies, they get caught up in the automation of delivery processes such as builds, promotions and deployments. But automation isn’t always the correct answer. Organisations need to look at their technology and automate when necessary and capable, streamline where possible and eliminate technology where it’s not practical or it is redundant. In some cases, where automating around the bottleneck is making it costly, it may be necessary to overhaul the process completely. It is necessary to listen to other teams in the business and offer user-proof services.
When choosing a technology platform, it’s important to select one that places the needs of developers at the centre of its solutions. It should also focus on remediating issues rather than just reporting them. Platforms with a developer-first approach can integrate security across the pipeline, helping multiple different stakeholders such as devs, sec and ops teams to get a holistic view to be able to come together and embed a mutual DevSecOps mindset.
Lawrence Crowther is the head of solutions engineering, Asia-Pacific and Japan at Snyk.