Report Identifies 6 DevSecOps Pillars
At the Black Hat USA conference, the DevSecOps Working Group of the Cloud Security Alliance (CSA) announced it has published a report identifying the six pillars on which any set of best DevSecOps processes should be based.
John Yeoh, global vice president of research for the CSA, said that although DevSecOps represents a major opportunity to improve the current state of cybersecurity, not many organizations have a deep understanding of how to start bringing together developer and cybersecurity teams, which have not always trusted one another.
To help organizations get started down that path, the CSA has identified the following six pillars that any DevSecOps process should be based on:
Pillar 1: Collective Responsibility
Security can no longer be viewed as someone else’s responsibility. It must not be considered an afterthought to be addressed only when everyone else’s work has been completed. Additionally, security cannot be seen as separate and distinct from business objectives. Finally, security is not something ephemeral whose progress and contribution cannot be measured.
Pillar 2: Collaboration and Integration
There is an enormous skill and talent gap in the software landscape. Without pan-organization collaboration around implementing security, success is going to be limited. Security can only be achieved only through collaboration, not confrontation. A security-aware and collaborative culture is necessary for the members of all functional teams to report potential anomalies.
Pillar 3: Pragmatic Implementation
Organizations have a wide array of tools and solutions from which to choose to implement application security within their software life cycles. Because every software life cycle 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 difficult to deploy and operationalize and do not provide actionable insights that can help mitigate the true security risks. Organizations need to take a holistic view of the software life cycle and their security needs and approach DevSecOps in a pragmatic manner.
Pillar 4: Bridging Compliance and Development
Risk-related requirements are difficult to translate into security requirements that can be measured easily over time. The key to addressing this gap between compliance and development is to identify applicable controls and then translate them to appropriate software measures, including identifying inflection points where these controls can be automated and measured to improve the quality.
Pillar 5: Automation
Manual coding easily can result in poor-performing and insecure software that needs rework, which then results in insecure software being released to production. Processes that can be automated should be automated, and those that can’t should be eliminated whenever possible. Automated security checks may create new issues, such as build delays or failures, but these issues typically can be addressed by workflow improvements or semi-automated approaches.
Pillar 6: Measure, Monitor, Report and Action
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 must be continuously measured, monitored, reported and acted upon by the right people at the right time.
Yeoh said it will be up to each organization to determine the level of collaboration between developers and cybersecurity teams. As a rule, however, the more cybersecurity professionals participate in the development process, the more sophisticated the controls that are put in place will be. That, in turn, eventually will lead to more secure code being developed faster. These six DevSecOps pillars are designed to help organizations move down the path with more alacrity. The challenge right now, of course, is finding enough cybersecurity professionals with the time and expertise required to participate in the application development and deployment process.
