10 Steps to Simplify Your DevSecOps
While the software industry celebrates a decade of DevOps, there’s an increasing drive toward adopting DevSecOps and making security a part of software from early on. Companies often face a common set of challenges when moving from DevOps to DevSecOps, which can be addressed by employing the following DevSecOps best practices.
1. Promote a DevSecOps Culture
There are several definitions of DevSecOps, but the one that stands out universally is collaboration, automation, learning, measurements and sharing (CALMS), coined by Jez Humble and adopted further by Synopsys’s Meera Rao. At its core, DevSecOps thrives on a culture and a mindset in which various cross-functional teams share a single goal of continuous software security.
To embed a culture of DevSecOps, it’s best to start with a few self-motivated and committed teams. Your strategic initiatives act as guide rails for these teams while they work to ingrain DevSecOps culture into day-to-day functions, balancing security, speed and scale. From there, other teams can follow in their footsteps.
The key to promoting a DevSecOps culture and mindset is to operate in iterations.
2. Empower Teams to Build Security into the SDLC
While it sounds perfectly logical to “build security in,” it’s easier said than done. One of the key challenges that teams face is a lack of understanding, tooling and processes that help build security into their software.
Ensuring that software is secure starts even before you write code. Security activities such as threat modeling and architecture reviews can help set the course for the security requirements and controls to be implemented during the software development life cycle (SDLC). When implementing the requirements and controls, giving development teams enough training on how to write secure code and fix security issues is of utmost importance.
Ensuring visibility into security vulnerabilities also helps create awareness. For example, one way to give immediate feedback on the code is to use IDE-based scanners to identify insecure code right in the developer’s workstation. Such tooling enables developers to code securely and fix vulnerabilities early.
3. Plan Security Activities
Every organization that wants to integrate security into its DevOps workflows is likely to be torn between decisions about which security activities are needed and which type of tooling to buy. The key is to think first about when a security activity is performed in an SDLC. Each organization works in its own unique way when adopting DevSecOps, driven by its industry, maturity and culture. The placement of security checkpoints will be unique as well.
For example, when developers have adequate training about coding securely, they often find it useful to perform security testing before code commits happen. That prevents developers from checking in unsecured code. For other organizations, the earliest starting point for security scanning could be in their central integration pipelines, which are normally triggered right after source code gets merged from developer branches to the main branch.
After determining when to perform security activities, each checkpoint can be used to indicate which security activity and tool is most applicable. In the example above, a pre-commit security scan or an IDE-based scan could be implemented to shift security testing further left in the development stage. Additionally, the central integration pipelines could have more security checkpoints implemented, with activities such as deeper static application security testing (SAST), software composition analysis (SCA), dynamic application security testing (DAST)/interactive application security testing (IAST) or penetration testing.
4. Improve Speed and Scale with Automation
Automation is key when balancing security integrations with speed and scale. DevOps adoption already focuses on automation, and the same holds true for DevSecOp. Automating security tools and processes ensures teams are following DevSecOps best practices.
Automation ensures that tools and processes are used in a consistent, repeatable and reliable manner. It’s important to identify which security activities and processes can be completely automated and which require some manual intervention. For example, running a SAST tool in a pipeline can be automated entirely; however, threat modeling and penetration testing require manual efforts. The same is true for processes.
A successful automation strategy also depends on the tools and technology used. One important automation consideration is whether a tool has enough interfaces to allow its integration with other subsystems. For example, to enable developers to do IDE scans, look for a SAST tool that has support for common IDE software. Similarly, to integrate a tool into a pipeline, review whether he tool offers APIs or webhooks or CLI interfaces that can be used to trigger scans and request reports. Another consideration is a tool’s ability to be used “as code,” including configuration-as-code or pipeline-as-code, which can determine the level of automation that can be achieved throughout the SDLC. As an example, a containerized AST tool can be deployed and run easily in an automated environment, due to its infrastructure-as-code capability. Similarly, continuous integration (CI) systems, like Jenkins CI, allow defining global libraries to provide pipelines-as-code features, which enables global AST integrations across a large number of CI jobs.
5. Start Early with Small Changes
Often, when organizations or teams start integrating security activities and scanners in a DevSecOps pipeline, they tend to enable an overwhelming scope of rule sets and scan configurations. This hampers DevSecOps adoption in two ways: First, development teams suddenly see many security findings in their queues, which makes it impossible for them to address them all over a short sprint, and that causes reluctance to fix security findings. Second, the subsequent loss of dev support and acceptance threatens the entire DevSecOps culture.
It is key, therefore, to start early with small changes. Security testing should begin as early in the SDLC as possible and should be done with a gradually increasing scope. For example, instead of enabling full scans or scans with the entire rule set for a pre-commit security checkpoint, teams should consider keeping the rule set limited to its top five vulnerabilities and running deeper scans later.
6. Tie in the Out-of-Band Activities
While automation plays an important role in adopting DevSecOps, there are certain types of security activities that must be done out of band and manually. Usually these activities are performed on a predefined schedule, perhaps quarterly. This can result in either overdoing or underdoing those activities.
Triggering out-of-band activities based on events in an automated pipeline helps balance the requirement. For example, results of SAST scans that are anomalous or cross a threshold could trigger a deeper manual source code review. Similarly, if a critical vulnerability is detected in a third-party component, a penetration test could be scheduled to assess its exploitability.
7. Manage Security Vulnerabilities as Software Defects
Security vulnerabilities are commonly reported differently than quality and functional defects. Often, organizations maintain the two types of findings — security and quality — in two different locations. This reduces the visibility each team and role has when they look at the overall security posture of their project.
Maintaining security and quality findings in one place helps teams treat both types of issues in the same manner and with the same importance. In reality, security findings, especially ones from automated scanning tools, can be a false positive. It becomes challenging, in such cases, to ask developers to review and fix those problems. One solution is to tune the security tooling over time by analyzing historical findings and application information, and by applying filters and custom rule sets to report only critical issues.
8. Collect and Analyze Data at Every Stage
You can measure success and failure by collecting data about the various factors and attributes contributing to DevSecOps and retrieving useful metrics from them. A comprehensive metrics program is one that includes people, process and technology components holistically. For instance, metrics should shed light into failures stemming from a lack of well-defined processes as well as inefficient tool use. To achieve this, measuring and collecting relevant data at every stage of the pipeline and security activities is of paramount importance. Automation should also be used where possible to continuously and consistently gather the data points required for metrics.
There are numerous factors that can be measured and used to build metrics, such as the number and type of security scans performed throughout SDLC, the number of reported critical security and quality issues, the pipeline execution time and more.
This data helps teams create metrics to move toward an overall reduction in defect density, preproduction security defects and mean time to deployment.
9. Learn from Your Failures
DevSecOps adoptions are always iterative. During continuous integration and measurement, failures are bound to happen from time to time. Ideally, failure should be used to help teams learn and improve. Any DevSecOps pipeline that doesn’t report a failure or take an action on one is not truly embracing DevSecOps.
The “Three Ways” principle of DevOps is also directly applicable to DevSecOps:
- First Way: Never passing a known failure or a known critical security defect into downstream work, thereby ensuring success of the end-to-end system.
- Second way: Shorten the feedback loops by reporting any failure, including security, as soon as it happens.
- Third way: Build a more secure development culture by learning from past failures, iterating and tackling new failures/defects just as outlined in the first and second ways.
10. Improve Velocity with Scalable Governance
Traditional governance models significantly impede delivery velocity and are incompatible with the fundamental goal of DevSecOps: to ensure fast, safe and secure delivery of software. As a result, along with security testing, governance activities should also be automated where possible.
Governance-as-code should be used to implement checks across the software delivery pipeline, and it should include required triggers for manual intervention to handle escalations, exceptions and implementing compensating controls. As an example of governance, consider signoff gates that an organization typically has before their releases.
Collaborating, obtaining buy-in and enabling development and operations teams is key to ensuring that the governance model is inclusive and fully adopted. Such enablement can be achieved using various feedback mechanisms, which include, but are not limited to:
- Pausing the pipeline builds
- Sending notifications
- Creating defects and tracking them centrally
- Breaking/stopping the pipeline build completely
Put These Practices into Action
Transforming your organization to DevSecOps is a huge undertaking with many known and unknown challenges. It’s important to keep in mind that DevSecOps is not an off-the-shelf tool or a golden pipeline. It will take a roadmap to become a reality for any organization. Follow these best practices to lay the foundation. After all, Rome wasn’t built in a day.
To learn more about DevSecOps and application security best practices, visit the Synopsys course catalog.