The real state of DevSecOps: Checking on automation, speed, and accuracy
Synopsys commissioned 451 Research to conduct a study on the state of DevSecOps. As described in the report “DevSecOps Realities and Opportunities,” it was found that only half of DevOps teams include application security testing (AST) in their continuous integretion and continuous deploypment (CI/CD) workflows. DevOps teams face both challenges and opportunities as they apply application security tools and best practices in their CI/CD workflows. Automation, speed, accuracy, and CI/CD integration are critical to making DevSecOps successful.
Integrating security throughout the SDLC
Software security can and should be added throughout the software development life cycle (SDLC). As organisations adopt newer and faster development cycles, automation is instrumental in increasing both the velocity of deployment and streamlining the delivery process. As development and operations roles merge into a cross-functional DevOps team, organisations have the opportunity to build security in at every stage.
When survey respondents were asked the ideal time to integrate application security testing into CI/CD workflows, 67% of them indicated “When developers commit code” and 44% said “On the fly while coding.” However, this is not what participants reported actually doing in their organisations – just 50% integrate AST when developers commit code and only 38% do so on the fly while coding.
The importance of shifting left in the SDLC
Static Analysis, also known as Static Application Security Testing (SAST), examines source code for security and coding defects. SAST provides one of many checks in an application security assurance program, designed to identify and mitigate security vulnerabilities in source code early in the development process, helping organisations “shift left” in the SDLC. Automation of SAST tools is another important component of DevSecOps adoption, as it drives code efficiency and consistency, as well as early detection of defects.
Developers make mistakes. Development teams take shortcuts to hit milestones or stay within budget constraints. To help developers avoid mistakes and eliminate risk from taking shortcuts, SAST IDE plugins provide just-in-time security guidance by scanning code as it is written, rather than after code is committed to version control. In this way, SAST IDE plugins act as desktop security experts: they provide guidance automatically when developers create code that may introduce risk.
When and how to break the build effectively
In the past, breaking the build might have caused consternation to development teams, when in fact it’s essential to break the build when critical, high risk issues and vulnerabilities are discovered at any point during the SDLC. When the build breaks, the continuous integration/delivery pipeline also breaks, notifying the appropriate teams. If the build broke because of a critical or high-risk finding (such as identifying SQL injection), the development team can immediately resolve the issue with guidance from the SAST IDE plugin, verify the fix, and check in the code. Once a developer checks code into version control, SAST commit-time checks verify the fix again.
Running SAST in the IDE, performing SAST at commit, and breaking the build are essential activities in DevSecOps. They enable organisations to shift left, find security-related vulnerabilities early in the SDLC, and increase their production velocity to keep pace with the evolving landscape of DevSecOps.
Don’t stop at the beginning
Of course, application security testing doesn’t only include SAST. Organisations can perform software composition analysis (SCA) and CVE scanning at commit and on the fly as developers write code—and they are doing just that, according to survey findings. In fact, 61% of respondents identified SCA and CVE scanning as the most critical elements of AST. Survey responses indicated dynamic application security testing (DAST) as the next most critical testing element, identified by 59% of respondents, while 57% deemed penetration testing critical. These are both important activities, and yet both take place very late in the SDLC.
No single application security assurance program can find all the vulnerabilities in an application. For instance, static analysis tools cannot understand business logic. But a manual secure code review can discover violations of secure coding standards and best practices by examining the application’s source code line by line, although this is a laborious and error-prone process.
Likewise, penetration testing involves the review of an application as it is running to identify potential security vulnerabilities. But no automated security tool (or even penetration testing) is effective in discovering architecture and design flaws in deployed applications. The only effective way for an organisation to discover these types of flaws is to perform a manual architecture risk analysis.
Automate as much as possible
All vulnerabilities identified using your SAST, DAST, IAST, and fuzz testing activities during your development pipeline should be automated into the build process and have the ability to break the build as necessary. These tools should also collect metrics on vulnerabilities and immediately create a task in the bug tracking system. Building secure, high-quality software is not easy, and the enterprises in this survey clearly highlighted the value of building security and quality into the build process as a key step to moving forward with DevSecOps. As development and operations teams work more closely together throughout the software development life cycle, building security in at every stage, automating as much as possible, and integrating tools into the CI/CD pipeline will help organisations achieve DevSecOps rapidly and successfully.
- » Most employees believe their CIOs aren’t receptive to their technology needs
- » For enterprise cyber defence, there should be more than one solution
- » Why CIOs are looking towards a different – not disappearing – role
- » The Dresner 2018 business intelligence verdict: Highlights and opportunities
- » Enterprise mobility and security: How to build a BYOD policy