DEVOPSdigest

Long gone are the days when security is merely an afterthought in the DevOps process. Instead, recognizing that vulnerabilities can be inadvertently introduced during development, the issue of security has moved front and center, becoming an integral part of the development lifecycle rather than something to be bolted on at the end.

To help organizations navigate the myriad issues and challenges that arise when embedding security into the DevOps process and provide a path to success, the Cloud Security Alliance (CSA), together with Software Assurance Forum for Excellence in Code (SAFECode), drafted a series of white papers based on six critical pillars described in CSA's Reflexive Security Framework(link is external). Each paper tackles a different aspect of implementation and empowers readers with actionable security resources and guidance.

Overview: Six Pillars of DevSecOps(link is external) provides an overview of DevSecOps — what it is and why it's important — and defines the six focus areas that are considered to be critical in its implementation and integration into an organization. Together, these pillars provide a holistic framework, blending traditionally siloed operations — development, infrastructure operations, and information security — into a cohesive group that facilitates creation of secure software. This is a go-to document for anyone looking to get buy-in from stakeholders.

Pillar 1: Collective Responsibility

Pillar 1: Collective Responsibility(link is external) describes the common practices shared by organizations that have taken a program-level approach to security culture development. Broken into three key areas: 1) executive support and engagement, 2) program design and implementation, 3) program sustainment and measurement, the paper suggests how to best garner (and keep) executive support and engagement while building an inclusive cultural program based on cumulative experience. The paper also touches upon how to leverage security champions to create deep engagement and using metrics to sustain, build, and help evolve the program. (Those looking for a deeper understanding should consider the DevSecOps: Collective Responsibility self-paced course(link is external).)

Pillar 2: Collaboration and Integration

Pillar 2: Collaboration and Integration(link is external) addresses the importance of integrating DevSecOps into organizational processes and stresses the key role that fostering a sense of collaboration plays in its successful implementation. Notably, the paper also dives into the convergence between DevSecOps and various technology areas, providing an overview of how DevSecOps can be leveraged for Zero Trust and MLSecOps, and AIOps. Among the topics covered:

■ Overarching principles for successful collaboration in DevSecOps

■ Role-based security training programs, including details on implementing a continuous, role-based security training program at an organization

■ How various organizational roles can and should join forces in an end-to-end DevSecOps delivery pipeline

■ Role-based communication requirements to integrating a new acquisition into an organization's existing DevSecOps processes

■ Crafting a winning DevSecOps culture

Pillar 3: Pragmatic Implementation

Pillar 3: Pragmatic Implementation(link is external) outlines the practices, processes, and technologies that organizations should consider when building out any DevSecOps program and how to implement DevSecOps pragmatically. The paper offers such key take-aways as:

■ Different role profiles to consider during DevSecOps adoption

■ Common mistakes in designing a DevSecOps team structure

■ Impact of culture on velocity and performance

■ Characteristics of an optimized and productive culture

■ Which technologies and processes underpin the pragmatic implementation of DevSecOps

■ Considerations for various activities across all stages of the DevSecOps process, including threat modeling, developer training, security unit testing, penetration testing, GitOps, secrets and key management, and chaos engineering

Pillar 4: Bridging Compliance and Development

Pillar 4: Bridging Compliance and Development(link is external) is broken into three parts offering 1) an approach to compartmentalization and assessment with an eye to minimizing operating impact, 2) best practices on how compliance can be designed and implemented into applications, and 3) a look at the different security tooling practices that can provide assurance to compliance requirements. This paper provides actionable, measurable guidance to DevSecOps teams on translating security and compliance requirements into the development cycle thereby ensuring that the gap between compliance and development is addressed.

Pillar 5: Automation

Pillar 5: Automation(link is external) provides a holistic framework for facilitating security automation within DevSecOps. It offers a series of best practices for automating those security controls, as well as clarification of common misconceptions surrounding DevSecOps security testing. Specifically, the document provides insight into:

■ Triggers and checkpoints that should occur in the delivery pipeline

■ Shifting security left while accelerating right

■ Prioritizing and balancing resources along with deliverability

■ Risk factors throughout the delivery pipeline and how automation can mitigate them

■ Automation best practices beyond DevSecOps

Pillar 6: Measure, Monitor, Report, and Action

Pillar 6: Measure, Monitor, Report, and Action(link is external) emphasizes the importance of continuous measurement and observability in DevSecOps and offers a detailed exploration of making security data observable, applying these principles to various team performance levels, and improving security observability through effective reporting. Among the paper's key recommendations are the adoption and use of specific principles for enhancing reporting to drive continuous improvement in security. Topics of exploration include:

■ Data observability, specifically turning security data and metrics into observable data

■ Scenario-based review and how security observability can be applied to high- and low-performing teams

■ Improvement through reporting and where companies should start on their security-observability reporting journey

DevSecOps is still relatively new, and I'd encourage anyone interested in shaping its future to join CSA's DevSecOps working group(link is external). It's open to anyone — no prior experience is required — and you can participate as much (or as little) as you like. I hope to see you there.