We recently explored why developers have begun to ship more frequently to production, as well the relationship between more frequent releases and AppSec teams more effectively prioritizing and remediating threats.
To further understand how AppSec teams evaluate tooling, we’ve recorded a collection of common questions that we’ve observed teams asking themselves. These questions reveal the true need for AppSec tooling to work to accelerate remediation of the most important threats to organizations, rather than trying to squash every bug.
To summarize our findings, we’ve compiled a visual that puts existing AppSec tooling to the test. More specifically, we’ve outlined “jobs to be done” by product category (in other words, the needs we’ve identified from AppSec teams) and have lined these up against some of the solutions that AppSec teams find themselves turning to.
Click image to enlarge
As you can see, there’s no perfect solution that addresses each of these questions that AppSec teams are posing. However, as AppSec teams continue to work with developers to quickly resolve threats, innovation coming out of the External Attack Surface Management (EASM) space is now addressing these questions.
Why does the AppSec tech stack fall short?
Today’s AppSec teams face several common challenges, which we’ll narrow down into the following three points: Developer experience, vulnerability debt, and cognitive overload due to changes in prioritization systems.
Developer experience influences how quickly an organization can resolve vulnerabilities
With the rise of modern tech architecture, the boundaries of applications have become much more blurry. Evolving technology, working methods, and access to hundreds of open-source and off-the-shelf software mean an organization’s attack surface is more dynamic than ever.
As modern tech stacks evolve, the value of traditional DAST diminishes. To effectively adapt to changes in the security landscape, AppSec teams need to equip themselves with tools that minimize risk across the entire attack surface.
Here are some questions for security teams to ask themselves when examining tools:
- Does this product integrate into existing SDLC workflows, enabling product teams to work lean and agilely?
- Does it interfere with developer experience?
- Does it identify and manage the attack surface?
- Does it identify risks in external code dependencies?
- Does it spot risk due to human error, like misconfigurations?
Security scoring systems don’t reflect modern AppSec workflows
The inner workings of certain security rating systems have been designed to retrofit systems rather than actually help with vulnerability prioritization. Combined with CVSS and CVEs, this gives AppSec teams an even more complicated view of prioritizing vulnerabilities.
AppSec teams also struggle to prioritize these vulnerabilities in a meaningful way. Previously, these teams could leverage scoring systems like CVE/CVSS, which proved useful when everything hosted was within the perimeter or network of your organization.
“These days, scoring systems are significantly less useful, as they don’t consider attack paths or even what’s required for a vulnerability to be exploitable.”
So how do AppSec teams prioritize what to remediate when the applications they build look a lot different than in the past? These days, scoring systems are significantly less useful, as they don’t consider attack paths or even what’s required for a vulnerability to be exploitable. They also don’t consider that today’s applications are built of various microservices, usually communicated through APIs.
The individuals building these applications and services will have significantly more insight into whether or not it’s worth considering a vulnerability in something they built. Scoring systems simply don’t capture this information – it’s not the fault of the scoring systems, but instead, the fact that how software is built today is fundamentally different from several years ago.
Obstacles standing in the way of AppSec teams achieving faster remediation times
One of the primary obstacles standing in the way of faster remediation time is the enormous amount of vulnerabilities that organizations must triage according to whatever prioritization logic they follow.
However, those prioritization methods are becoming significantly less applicable as AppSec teams respond to changes in how software is built, how developers work, and the speed at which new threats affect their systems.
“AppSec teams know that it’s not reasonable to expect zero vulnerabilities in their systems”
Because AppSec teams know that it’s not reasonable to expect zero vulnerabilities in their systems, they’ve begun shifting their attention to how quickly they can remediate issues that likely have the most impact on their systems. But this is easier said than done: In reality, several factors influence an organization’s desired remediation time, such as size of the attack surface or even industry-specific regulations.
The most successful implementations observed by Detectify have been when AppSec teams leverage remediation time reduction as a means to collaborate with their developer teams – this is done by uncovering what’s getting in their way of resolving threats faster.
The bottom line: EASM provides modern AppSec teams with more value
Today’s AppSec teams are taking a more holistic approach to identifying their unknown Internet-facing assets. This is where a comprehensive External Attack Surface Management solution comes in.
In our recent e-book, Deep dive: How EASM is outpacing DAST for AppSec teams, we’ll tell you more about how Detectify’s EASM tool focuses on meeting AppSec teams’ needs by making it possible to know what they’re exposing online and allowing them to tune out the noise.
Download the e-book here