Research-backed perspectives on the state of DevSecOps


Automation of static application security testing tools drives efficiency, consistency, and early detection while also enabling organisations to shift left.

Synopsys recently commissioned 451 Research to conduct a study to better understand the benefits of DevOps models. The study examined challenges and opportunities DevOps teams face in adapting and applying application security tools and best practices to their CI/CD workflows—an emerging trend known as DevSecOps.

Security activities throughout the SDLC

I'd first like to emphasise that software security activities can be added throughout the phases of the software development life cycle (SDLC). These activities are methodology-agnostic and can be applied to both standard SDLC methodologies and waterfall, agile, and DevOps methods.

No single application security assurance programme 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, which is a laborious 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, other than a manual architecture risk analysis. The list goes on and on.

Most critical security testing activities

According to the report, when respondents were asked which elements of application security testing were most critical, 61 percent identified software composition analysis (SCA) and CVE scanning. Dynamic application security testing (DAST) was noted as the next most critical testing element, identified by 59 percent of respondents. Penetration testing was also deemed critical by 57 percent of survey respondents.

This is in direct contrast to what respondents said was the ideal time to integrate application security testing into CI/CD workflows. The percentages of “When developers commit code” and “On the fly while coding” were both higher (67 percent and 44 percent) than what participants reported actually doing in their organisations (50 percent and 38 percent).

DAST and penetration testing are important activities, and yet both take place very late in the SDLC. Organisations can perform SCA and CVE scanning at commit and on the fly as developers code—and they are doing just that, according to survey findings. However, it is also key to perform static application security testing (SAST) early in the SDLC.

Continue to shift left in the SDLC

SAST is the process of examining source code for security defects. It is one of many checks in an application security assurance programme designed to identify and mitigate security vulnerabilities in source code early in the DevSecOps process, helping organisations shift left in the SDLC. Automation of SAST tools is another important component of adoption, as it drives efficiency, consistency, and early detection while also enabling organisations to shift left.

Keep in mind that well-intentioned developers can make mistakes. Additionally, teams may take shortcuts to hit milestones or stay within budget constraints. To help steer developers away from mistakes and risky 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 where risk may be introduced.

When and how to break the build effectively

In addition to performing SAST early in the SDLC, it is also important that quality and security issues break the build. When the build breaks, the continuous integration/delivery pipeline also breaks, and the appropriate teams are notified. If the build broke because of a critical or high-risk finding (eg deintifying SQL injection), the development team can immediately resolve the issue with assistance 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.

Increasing production velocity

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 ever-changing landscape of DevSecOps.

The 451 Research report commissioned by Synopsys, DevSecOps Realities and Opportunities, analyses survey results from 350 enterprise decision-makers at large enterprises across a variety of industries.

Contributed by Meera Rao, senior principal consultant at Synopsys Inc

*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media UK or Haymarket Media.


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events