Six Pillars of DevSecOps Series

Last updated: January 21, 2024

While DevOps practices can help improve the management and operations of information security processes in an organization, the execution of these practices has to be secured.

Security vulnerabilities can be inadvertently created due to lack of consideration of all aspects surrounding the infrastructure, for example, lax firewall rulesets, default credentials or an increased attack surface.

The field of “DevSecOps” applies DevOps concepts to enhance the efficiency and effectiveness of information security processes. On a tactical level, DevSecOps represents the integration and automation of security controls through DevOps using automated toolchains.

CSA’s DevSecOps Series Provides Much Needed Guidance

The six pillars of DevSecOps papers provide more specific guidance on how to start implementing DevSecOps in your organization. You can read a quick summary of each paper in the series below.

For more information on the DevSecOps methodology, and the differences between DevSecOps, DevOpsSec and SecDevOps practices you can read this publication first.

Overview: Six Pillars of DevSecOps

This document explains what DevSecOps is, why it is needed in an organization, who needs to be involved, and common areas that are challenging to organizations. It provides an overview of each of the six pillars of DevSecOps and how they are relevant. This document could be used to get stakeholder buy-in.

Pillar 1: Collective Responsibility

One of the greatest challenges to embedding security in DevOps is changing the organization’s mindset, its ideas, its customs and behaviors regarding software security. Everyone is responsible for the security stance of the organization. The CSO (Cloud Security Officer) plays a leadership and shepherding role for information security within an organization, but each person has their own security responsibility and must be aware of their own contribution to the organization’s security stance. Edge users and developers are not just “security-aware” but are the first line of defense.

Pillar 2: Collaboration and Integration

There is an enormous skill (knowledge) and talent (resources) gap in the software landscape across Development, Operations and Security. Without pan-organization collaboration around implementing security, success is going to be limited. Security can only be achieved through collaboration, not confrontation. A security aware and collaborative culture is necessary for the members of all functional teams to report potential anomalies. The human factor is often the weakest link and remember that most security incidents are caused by simple human error.

Pillar 3: Pragmatic Implementation

Since every software lifecycle is different in terms of structure, processes and overall maturity, there is no one-size-fits-all set of tools to implement DevSecOps. Organizations often end up procuring tools and point solutions that are hard to deploy, harder to operationalize and eventually do not provide actionable insights that can help mitigate the true security risks.

By using a framework agnostic “Digital Security and Privacy Model” focused on Application Development to ensure safety, privacy and trust in the digital society, organizations will be able to approach security in DevOps in a pragmatic manner. This model will fulfill the unmet need of connecting all the stakeholders (development, operations, and security) in a manner such that security is built into applications and the software lifecycle that produces applications.

Pillar 4: Bridging Compliance and Development

Risk-related requirements are difficult to translate into security requirements that can be easily measured over time. While security teams create requirements to support their risk-based methodology, compliance requirements are poorly translated to DevOps and product requirements. Conversely, it is not easy to obtain evidence that security requirements have been met even if technical controls are implemented.

The key to addressing this gap between compliance and development is to identify applicable controls, translating them to appropriate software measures and identifying inflection points within the software lifecycle where these controls can be automated and measured to improve the quality of risk mitigation and therefore compliance.

Pillar 5: Automation

Some of the issues preventing software development practices from taking an idea to secure deployment quickly (with minimal cost) are manual and haphazard coding, testing, deployment and patching practices. Without automated quality checks, manual coding can easily result in poor performing and insecure software that needs rework.

Automated security practices are the core of process efficiency because they can reduce manual processes, increasing efficiency and reducing rework. Software quality can be enhanced by improving the thoroughness, timeliness and frequency of testing/feedback. Processes that can be automated should be automated, and those that can’t should be automated as much as possible or be considered for elimination. Automated security checks may create new issues, such as build delays or failures, though these typically can be addressed by workflow improvements or semi-automated approaches.

Pillar 6: Measure, Monitor, Report and Action

The saying “you can’t manage what you can’t measure” has never been more true than in the implementation and maintenance of DevSecOps. Typical DevSecOps initiatives can take anywhere from months to years to implement depending on scope and complexity. Without actionable metrics, progress cannot be measured and failures cannot be detected in a timely manner.

Some of the most critical metrics to monitor in a DevSecOps environment are deployment frequency, vulnerability patch time, percentage code automatically tested, and automated tests per application. The results during software development as well as post-delivery must be measured, monitored, reported and acted upon by the right people at the right time (continuously) for DevSecOps to succeed.