CSA Pragmatic Implementation
Organizations have a wide array of tools and solutions to choose from when implementing security into the software development process. They often end up procuring solutions that are hard to deploy or challenging to operationalize and observe. Instead, using a framework-agnostic DevSecOps model that focuses on application development and platform security allows organizations to approach security in DevOps pragmatically. This publication outlines the practices, processes, and technologies that organizations should consider when building out any DevSecOps program. Readers will learn how to implement DevSecOps pragmatically, focusing on security covering all software, regardless of where it runs.
Introduction
Organizations have a wide array of tools and solutions to choose from when implementing security into their Software Development Lifecycle (SDLC). Organizations often procure tools and solutions that are either hard to deploy, challenging to operationalize and scale, or do not provide actionable insights that can help mitigate the actual security risks. Since every SDLC is different in terms of structure, processes, tooling, and overall maturity, there is no one-size-fits-all binary blueprint to implement DevSecOps. Using a framework-agnostic DevSecOps model–focused on application development and platform security to ensure safety, privacy, and trust in the digital society–organizations will be able to approach security in DevOps pragmatically. This model will fulfill the unmet need of connecting all the stakeholders (development, operations, and security) to embed security into the software lifecycle.
The DevSecOps implementation guidance in this paper is organized into a menu of practical responsibilities and activities to enable digital security leaders to make pragmatic decisions when embarking on DevSecOps. DevSecOps adoption is typically organically established either by software development and platform engineering teams, or centrally by leadership. Regardless of the drivers and stakeholders, organizations should view their DevSecOps implementation as an iterative continuous improvement effort rather than a one-time waterfall project. The scope of this paper identifies and expands on the 4 key elements of a successful DevSecOps initiative–culture, people, process, and technology.
Key Takeaways
From the Security viewpoint, organizations seeking security improvements look to robust security programs that rely upon effective integration of security best practices into the organization’s software development paradigms. This is typically led by culture and processes, operation of security infrastructure and technology, and workforce awareness. Security at every software lifecycle stage will require some combination of people, culture, process, and technology:
People: The individuals and their roles within your organization and the delivery of secure and successful applications, platforms, and infrastructure. There is a focus on leadership, technical stakeholders, implementers, and decision-makers.
Culture: How an organization approaches and manages work and risk. Often the softer and difficult-to-measure area, culture is perception of software development work and security, which plays a direct role in performance and success.
Process: The common workflows, manual actions, and well-documented activities. People execute processes with the support of automation or some combination of the two.
Technology: Technology focuses on securely creating and operating infrastructure and applications using tooling and automation to help protect assets and detect vulnerabilities, events and incidents. The combination between these will vary depending upon the size and sophistication of an organization’s security program. Smaller organizations typically rely primarily on people filling multiple roles and managing application security, while larger organizations may leverage technology and automation. An organization’s culture may be influenced by compliance requirements that lead to significant oversight and audit, while others embed checks and balances into standard workflows.
