Six Pillars of DevSecOps

Introduction

• The six pillars of DevSecOps papers provide more specific guidance on how to start implementing DevSecOps in your organization.
• Below are the six pillars:

Pillar 1: Collective Responsibility Pillar 2: Collaboration and Integration Pillar 3: Pragmatic Implementation Pillar 4: Bridging Compliance and Development Pillar 5: Automation Pillar 6: Measure, Monitor, Report, and Action

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.