Why We Need "Developer-First" Application Security

A recent survey that we conducted shows that, despite increasing pressure for accelerated release cycles, developers actually are interested in security. The main challenge, however, is that the current application security testing (AST) tools in place at most organizations are not developer-centric. Getting accurate AST results from these tools depends on human security experts for triage and analysis before making recommendations to developers. This workflow slows down pipelines and cannot scale to support the demands of today's software development life cycle (SDLC).

Modern software development prioritizes delivering value through software into production applications and application programming interfaces (APIs). This is out of necessity — the companies that are best at this will dominate in their categories. Businesses in every industry today have an insatiable hunger for new or improved applications that accelerate production, solve problems, or enhance business agility. As a result, most organizations (79%) report that developers are under increasing pressure to shorten release cycles, our survey found.

But while software developers need to push things faster, the legacy tools for AST used in most organizations were not designed to keep pace with the intense demands of modern development cycles. This incompatibility has reached a breaking point where developers are often forced to choose meeting release deadlines over performing security scans.

Speed is the new normal for application developers. And so we need security tools that allow developers to do their job normally.

Security Designed for Modern Development
If speed is table stakes for security to become an asset to developers, then we need to understand why today's system is broken. Current testing depends on security experts to run scans on each application. Scans take a long time to run and they generate high volumes of false-positive alerts. Once the security team sorts through the noisy report results and sends back remediation recommendations, developers must stop their forward progress and go back to what they were working on days, weeks, or months before to make the necessary changes. This disjointed workflow has a huge impact on operational efficiency and the organization's ability to meet delivery deadlines.

Harmonizing the efforts of development and security teams depends on embracing a developer-first approach to application security. A transformative solution must provide three essential capabilities:

Speed: Fast, Contextual Results
Developers need almost instant feedback on the code they're writing. So, as a starting point, modern application security must be fast. Timely results empower developers to fix issues without context switching and without having to involve security experts to triage results. Providing developers the full context from within the application about each vulnerability, including user input, exact line(s) of code, verbatim queries, library usage, etc., enables "just-in-time" training based on the specific vulnerability to further accelerate a developer's ability to quickly address issues in real time.

Accuracy: Eliminate Alert Noise
Modern application security must also be accurate. False positives are a huge burden on development teams. If a testing tool generates reports with as many as 85% false positives, then application security specialists and developers waste a huge amount of time triaging, correlating, deduplicating, risk rating, and remediating issues that pose no risk at all. This, in turn, bogs down development workflows and the broader delivery cycle.

Scalability: Continuous, Comprehensive Testing
Finally, application security must be scalable. To make scanning effective, experts recommend running full scans every day on every application and API. That is simply unfeasible when the average scan takes at least three hours per application for 91% of organizations (and 35% report that their scans may take eight or more hours) not including triage time, according to our report. To meet demand, an effective solution cannot be a tool that runs periodically or that can only perform one-at-a-time serial tests. Application security must run continuously in the background across an organization's entire portfolio of applications.

Better Security: By Developers, for Developers
We can't have separate processes, separate silos, separate checklists, separate everything for security. It's not realistic for security teams to think that there's going to be a whole separate system just for them. The only way that we can truly improve the security of the modern SDLC and drastically reduce the growing number of application-based breaches every year is to re-center application security around the needs of developers. This is what "developer-first" application security means.

Learn about the Contrast Security Platform here.

About the Author

Jeff Williams brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects.

Results for “"securitythe"”

Why We Need "Developer-First" Application Security