After a decade of DevOps, the era of DevSecOps adopting is here. Find out how to make the difficult transition work.
DevSecOps can actually be a paradox for modern IT teams that are already struggling to keep up with the speed and scale requirements of the fast-evolving market.
However, the common challenges when moving from DevOps to DevSecOps can be addressed through the following 10 DevSecOps best practices.
- Foster a DevSecOps culture and mindset
There are several definitions of DevSecOps, but the one that stands out universally is collaboration, automation, learning, measurements, and sharing (CALMS). 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 is best to start with a few self-motivated and committed teams that are aligned to the goals of strategic DevSecOps initiatives. The strategic initiatives act as guiderails for these teams while they work to ingrain DevSecOps culture into day-to-day functions, balancing security, speed, and scale. Once the pilot teams adopt DevSecOps and start showing visible benefits, they become examples to other teams that could follow their footsteps.
The key to fostering a DevSecOps culture and mindset is to operate in iterations and work upward from individual project teams to the entire organization. - Enable teams to build security in
While it sounds perfectly logical to “build security in”, it is easier said than done. One of the key challenges that teams face is a lack of understanding and tooling or processes to help build security into their software. Enabling teams to achieve this goal is vital to ensuring that they are able to build secure software.
Ensuring that software is secure starts even before writing code for it. Security activities such as threat modeling and architecture risk 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 and much-needed feedback loops in identifying and fixing those vulnerabilities. For example, one way to give immediate feedback on the code is to use IDE-based scanners to identify unsecure code right in developer’s workstation. Such tooling enables developers to code securely and fix vulnerabilities early. - Choose When first, not Which
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.
After determining when to perform security activities, each checkpoint can be used to indicate which security activity and tool is most applicable. For example, 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. - Automate tools and processes
Automation is key when balancing security integrations with speed and scale. The adoption of DevOps already focuses on automation, and the same holds true for DevSecOps. 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 is important to identify which security activities and processes can be completely automated and which require some manual intervention.
A successful automation strategy also depends on the tools and technology being used. One of the considerations in automation is whether a tool has enough interfaces to allow its integration with other subsystems.
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. - Start early and start small
Often when organizations or teams start integrating security activities and scanners in a DevSecOps pipeline, they tend to enable an overwhelming scope of rulesets 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, that loss of support and acceptance from development teams can threaten the entire DevSecOps culture.
It is key, therefore, to start small and early. Security testing should begin as far left 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 ruleset for a pre-commit security checkpoint, teams should consider keeping the ruleset limited to its top five vulnerabilities. The security activities that occur later in the SDLC can include deeper scans and reviews for pre-release security assurance. - Tie in the out-of-band
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. But 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. - Treat 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 potentially 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 rulesets to report only critical issues. - Measure every step
Adhering to DevSecOps best practices means measuring success or failure. This is done 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, and provides insight into success and failures.
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 critical security and quality issues reported by an application, the time taken for pipeline execution, and more.
This data helps teams create metrics to help move toward an overall reduction in defect density, preproduction security defects, and mean time to deployment. - Learn from failures
DevSecOps adoptions are always iterative. During continuous integration and measurement, failures are bound to happen from time to time. Ideally these should be used to help teams learn and improve. Any DevSecOps pipeline that does not 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. - Pursue 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.
Collaborating, obtaining buy-ins, and enabling development and operations teams is key to ensuring that the governance model is inclusive and has the required adoption. 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
Transforming your organization to DevSecOps is a huge undertaking with many known and unknown challenges. 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.
