DevSecOps: Application security tool use between development and information security nears parity

Introduction

Verizon's 2020 Data Breach Investigation Report, which is augmented with public sector incident response information, suggested that approximately 43% of data breaches could be traced back to the compromise of a web application. The tools to combat this – from identifying vulnerabilities directly in source code to fuzzing web and mobile applications for weak input controls – have long been available, and the final piece of the puzzle, the process of applying application security, is starting to fall into place. Developers and information security personnel are entering a heretofore unseen level of collaborative use of application security testing (AST) tools.

The 451 Take

The 'shift left' concept is not new in application security – for example, plug-ins for integrated development environments (IDEs) for popular AST tools like static AST (SAST) have been around for more than a decade. The reasons for addressing security vulnerabilities within software development lifecycles (SDLCs) are straightforward – fixing a defect while a developer is actively working on a section of code is a lot cheaper than trying to reopen something to fix it later, and a lot less damaging than a vulnerability being exploited by a bad actor in production. However, expectations for production web applications to be largely free of security defects and the pressures of keeping up with release cycles that deploy more frequently than in the past have forced a greater share of day-to-day application security testing to be federated to application developers. Per 451 Research's Voice of the Enterprise: Information Security end-user research, a steady multi-year trend toward greater collaboration has reached near parity in tool usage between the two teams.