In my previous article, I have talked about the differences between DevOps and DevSecOps from the secure software supply chain point of view. In this second part, I am going to dig deeper into angles related to the culture and collaboration within an organization, and the automated verification that can be enabled through DevSecOps.
DevSecOps improves culture and collaboration
A part of applying DevSecOps involves changing the culture of security in your organisation, meaning that ‘Security is now everyone’s responsibility’, as we hear more and more in DevSecOps-related discussions. The process is not an easy one and getting people to change their behaviour might be quite challenging. But let’s take a look into it.
Thinking about security as a continuously evolving product is a major shift when talking about a culture mindset. DevSecOps team players usually approach it from a product management perspective. They don’t look at security as project-driven audits and reactive incident responses, but mostly see the developers as their customers and the security process as a product they are creating and delivering for the developer’s use.
Fir starters, what does “culture” mean? The school of DevOps has gradually reduced the importance of clearly defining ‘culture’ in an application-delivery context. I won’t list the attributes here, but I would like instead to point out what I see as a major mindset shift: thinking about security as a continuously evolving product. DevSecOps team players usually have a product management approach to security. They don’t look at security as project-driven audits and reactive incident responses, but mostly see the developers as their customers and the security process as a product they are creating and delivering for the developer’s use.
Applying a product management approach to security shifts the focus from enforcing compliance to focusing the workflow on faster and more accurate actions. This is the reason the tools and automation components of DevSecOps are so important, as they play the role of products. Moreover, the practices of product management are so widely understood and proven over decades, that you don’t need to reinvent the wheel when it comes to applying them in DevSecOps.
Once you take a product management perspective in security, you understand better the reasons why culture tends to focus on empathy, kindness, and more communication with people, when it comes to DevSecOps. These three elements also happen to be key tools in product management. A good product manager has a clear idea about the needs people using their products have, where they are using them, and how all that links to the organisations’ goals those people are working in. They can “get into the mind” of their customers. In this context, if we think that a DevSecOps has a similar role with the one of a product manager, its focus should be oriented towards creating and delivering secure applications. So, instead of rolling your eyes at “those developers” who “don’t know anything about security,” you should put more efforts into creating products that make developers awesome at security.
The product-oriented mindset regarding security is a helpful way to think about one of the most popular phrases in DevSecOps, that says ‘shift left’. At first glance, ‘shifting left’ suggests giving developers more responsibility over writing secure code, ensuring compliance and controls. I think that’s sort of true. Part of DevSecOps involves getting developers to write more secure code, indeed. Though, expecting developers to handle most of the security tasks is too much to put on their shoulders. To be more precise, ‘shifting left’ means moving security activities and policy enforcement closer to developers, treating them as ‘customers’, and building out the guardrails, platforms, and tools they need to develop secure applications. Let’s go over some of these tools and platforms.
DevSecOps enables automated verification
With all the tracking that goes on in a secure software supply chain, you can automate much of the verification and governance that security teams require to check and release software. This verification has been done manually for years. Often, literally, with email and spreadsheets, that is time consuming, error prone, and generally unpleasant. For organisations that want to start deploying their software weekly, if not daily, manual security checks are impossible to work with.
Thankfully, the automation that comes with DevSecOps build pipelines helps reduce the toil of governance. It makes it easy, for example, to create a bill of materials (BoM) and sign container images. You can store all of that in a repository, even add it to version control, and security staff can create starter application designs and configurations that template out security best practices.
Automating these activities got easier because of the infrastructure standardisation that stays at the heart of Kubernetes. The configuration enforcement that Kubernetes performs improves your security capabilities. and in case of any configuration drift, it can usually kill and then redeploy applications into their secure, trusted state. This doesn’t solve all of your problems, of course, but it does make cleaning up production easier and deploying patches much faster. And if you regularly redeploy, or “repave,” all of production from scratch, you reduce the window of time people have to mess around.
In the third part of this article, I am going to talk about how DevSecOps can empower security through guardrails, and about the transition from DevOps to DevSecOps. Stay tuned!