CSA Bridging Development and Compliance
Given the rapid evolution of software development paradigms and practices, it has become a challenge to align monolithic security compliance activities with software development. Compliance teams have a vested interest in proving that a process and controls are in place. However, most DevOps aligned engineers believe that the proof should be in the code, not in the process or in its documentation. This document by the DevSecOps Working Group provides guidance to ensure the gap between compliance and development is addressed by recognizing compliance objectives, translating them to appropriate security measures, and identifying inflection points within the software development lifecycle where these controls can be embedded, automated, measured, and tested in a transparent and easily understood way.
Introduction
The DevSecOps practice is designed to bridge compliance and development, which requires a collaborative (collective responsibility4) effort between security teams and software developers. The goal of compliance in a DevSecOps model is to improve the overall security of an application or environment while reducing the effort taken to validate compliance with security objectives. The methods explored in this paper allow DevSecOps teams to translate security and compliance requirements into the development cycle such that they are:
Actionable for software developers.
Objectively measurable.
Pragmatic to the reduction of risks.
This paper also explores the requirements, methods, and recommendations for systematic collaboration to security and development teams and is sectioned into three parts, illustrated in Figure 1. Compliance and Development functions should consider the following components:
Assessment: An approach to compartmentalize and assess with minimal operating impact.
Mindset: The shift in thought and practice for how compliance can be designed and implemented into applications.
Tooling: The different practices in security tooling that can provide assurance to compliance requirements
Key Takeaways
Before DevSecOps, risk-related requirements were difficult to translate into security activities; these were often introduced at security gates with development and security teams working in separate silos. These silos created managerial and communication issues, resulting in security requirements poorly translated in the design, build and testing phases; security was often an afterthought in the entire process. The increasing speed and frequency of deployments in application development today mandated a solution that was efficient and more automated without compromising security and quality. DevSecOps emerged as “the modern approach” to secure applications and embed compliance throughout the secure software development lifecycle (SSDL), allowing security to “shift-left.” This approach involves applying during the five SSDL stages (design and architecture, coding, continuous build, integration and testing, continuous delivery and deployment, and runtime defense and monitoring) the following principles and practices help to bridge the gap between compliance and development:
Leverage methods for performing assessments continuously while amalgamating with point-in-time reviews.
Introduce value stream mapping to identify existing practices that can be automated to improve velocity.
Identify and translate compliance objectives to security user stories for developers to consume.
Embrace compliance as code/policy as code to codify security requirements in cloud and infrastructure builds.
Test frequently across the various methods of security testing (Smoke Testing, SAST, DAST, Fault Injection, Penetration Testing).
Track and control open source through identifying, vetting and measuring risk and using SCA tooling.
Define and create security guardrails to monitor deployments and find deviations from desired baselines autonomously.
Leverage the use of patterns and templates to scale security consistently.
Understand methods for monitoring potentially malicious events at the CI/CD pipeline.
Improve the quality of source code and IaC in IDE’s using linters, scanners and plugins.
Addressing the compliance and development gap requires stakeholder commitment to the practices recommended within this paper. Organizations that follow DevSecOps correctly will realize that tooling and automation, with the support of effective process, culture and governance, will improve the quality of risk management and speed of applying security controls at scale.
