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
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
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.