How to develop and maintain an effective DevSecOps culture

With the creation of DevOps, just over a decade ago, the intention was to break down the silos between development teams and operations. These silos created divisions and friction points that increased frustration, reduced productivity and prevented a holistic view of the delivery process. The focus was on uniting the different world views people had so both delivery speed and the quality of the product would improve. 

Now, with DevSecOps, there’s a similar desire to help the people doing the work, to reduce silos, delays and friction, but this time ensuring the product and all its ingredients are secure.

Through bringing roles together - development, operations and security - the team becomes more united, capable and knowledgeable, and thus better qualified to make decisions autonomously. The place of management, which might previously have been situated between teams, operating from the centre, and perhaps adding extra friction, becomes more directed towards supporting this broader team and facilitating further collaboration. A successful DevSecOps culture means everyone has equal stake in all three objectives and uses their own expertise to support the others. Accountability, empathy, and enablement become crucial characteristics of successful teams. 

Of course, this is not a change that can be introduced overnight, and the gestation period for DevSecOps will vary between companies. The nature and maturity of a company’s collaboration culture is largely set by the CEO and will contain a mixture of control to create safety, measurement and KPIs to improve, as well as employee empowerment to foster autonomy. Moving towards DevSecOps will benefit from continuing to improve the functionality of each of these layers. And each company will need to decide where to draw the line between team responsibilities and central management.

Similarly, different company cultures will gravitate towards different models of collaboration. In some, DevSecOps might be regarded as almost a separate project team, bringing together individuals from different teams on a temporary or part-time basis, or as a service layer added to the existing departments. At others, whole teams will work together, side-by-side, on a continual basis. Some of these models (those that encourage more collaboration and ownership) are likely to be more effective - but the nature of the particular company culture will determine what can be done successfully. 

Trust is crucial

However the initial formation is created, growing trust between Security and DevOps is going to be a major point for development. Creating real trust relies upon four, equally important elements: competence, reliability, sincerity and care. You might view a colleague as competent to conduct a security scan, for example, but if they won’t  respond  to your questions (reliability), or aren’t concerned about the impact (care), it will reduce trust. And trust is a two-way street: You can’t realistically ask for trust without also being trustworthy, and thus demonstrating these four characteristics. All of this takes time, and it’s worth spelling out these ingredients of trust for all parties involved.

Four pillars of DevSecOps

Beyond these organisational and cultural considerations, DevSecOps typically has four main focus areas in which the development teams’ responsibilities and considerations will extend far beyond their traditional remit.

The stack: The tooling that supports a DevSecOps pipeline is generally the beginning point for most organisational transformations: if your underlying technology doesn’t accommodate the changes required, the attempt will fail. Developers want to ensure the application is secure and can be operated securely. Historically, this revolved around the code, but, as the organisation evolves towards DevSecOps, can extend to code dependencies, infrastructure, and external services. Then, pushing further, considerations will extend into user identity and key management frameworks, into logging and exception handling information, and even broader business considerations such as licences and data management. 

Delivery: The technical process supporting development, security, and operations teams with cohesion and uniformity. Now, teams should ensure how the application is delivered is secure too. This again takes teams beyond code and into the application environment, how it’s tested, how it’s deployed, how patches are deployed and further. 

Teams will need technology and tooling that can seamlessly integrate into the development pipeline. Integrated tools that require little effort are more likely to be adopted by developers, so adopting automation that supports the multi-functional needs of a DevSecOps model is key. Organisations need to look at their technology and automate when necessary and capable, streamline where possible, and eliminate where it’s not practical or it is redundant. Minimising the various technologies through which the pipeline travels is an underrated but effective way to optimize software delivery. 

Achieving DevSecOps requires technologies in place to enable employees to execute these processes as well as automate them. This, ultimately, reduces the organisation’s attack surface and enables effective management of the technical security debt.  

Delivery in a DevSecOps culture, should improve collaboration as well as achieving more secure development processes as a whole. 

Governance: It’s essential for a DevSecOps team to discuss how the processes for managing security can be improved. 

Organisational processes in DevSecOps break down traditional barriers of authoritarian policies and workflows. To support the model of shared-responsibility, equity of purpose needs to be established between disciplines. 

Gating models must be reviewed and removed where possible when shifting to DevSecOps. Traditional security strategies involved key milestones when progress could be halted until an acceptable result was achieved, creating lengthy feedback loops that slowed delivery and ultimately reinforced silo-based thinking. Mutual accountability must be embraced, as a replacement to gating, supported by subsequent process changes.

A significant feature of governance in the DevSecOps culture is to establish a comprehensive metrics program. The ability of the culture to grow and continually improve needs to be demonstrated to the business. Measuring a baseline of vulnerabilities can begin this process, but keep in mind that collaboration is part of the culture.

Teams should be considering security management, threat and risk management - and again, outwards into affairs around compliance, regulations and supplier management.

While the technologies, delivery methods, and empowerment come together to support each other, governance provides perspective into each. It measures the performance of the other elements and can show where more focus is needed.

Empowerment: the fourth and most critical pillar. Ultimately, developers working in a DevSecOps culture will want to be empowered to make decisions because they want to take ownership over the security of the application. Restructuring DevOps and security teams to establish efficient cooperation between them will ensure security becomes a frame of mind rather than a hindrance. Again, this takes time and trust to build through stages, each of which will be ongoing. 

Stages to empower a DevSecOps team

The first of these stages will be a collaboration over conversations. This can partially be facilitated by technology, but also requires human interaction. They will raise issues face-to-face, volunteer ideas and get problems fixed by working together. 

The second stage for developers involves building a learning culture around security (and vice-versa for security personnel, of course). We’ll always need domain experts on particular matters in development, security and operations, but to take their collaboration to the next level, participants from each domain need to develop an active curiosity and learning attitude towards each other’s areas of expertise. They’ll be able to bring up new issues, for example, that belong in their counterpart’s domain, bring their own perspective and start a conversation to understand how to address issues.

The third and fourth stages are accountability and ownership. That developers feel accountable for security, and lastly that they feel ownership of the domain to as great an extent as anyone else involved. 

These are advanced stages and might take considerable time to mature. So organisations cannot rush this. Since a culture change, like the DevSecOps journey, is a long-term investment, it’s important that the value of initiatives can be demonstrated along the way. A DevSecOps journey should not be focused on a final outcome, but rather continuous improvement and maturation of the culture within the organisation.

Every increment in understanding and collaboration around the stack, delivery, governance and empowerment is a positive step forward in realising DevSecOps and safer applications.