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.

At Detectify, we proudly maintain an AppSec perspective when it comes to how we handle security. But what does this mean exactly? In short, we think a lot about how both AppSec teams and developers will experience our platform and products. We know that today’s developers are feeling the pressure to get new code out to production to meet the demands of the business. These business demands have increased the need for AppSec tooling to leverage automation whenever possible.

We know that most security teams today handle a backlog of thousands of vulnerabilities. We also know that not all of these vulnerabilities pose a significant risk to your organization, whether or not they have a high severity score or are present on a business-critical asset. We’ve spoken with dozens of security teams over the last few months and have learned that filtering vulnerabilities across several factors is critical to accelerating remediation.

Today’s organizations have a plethora of tools and technologies to protect their systems and assets. While this is certainly a privilege, it can sometimes be tough to keep up with the ever-expanding lists of acronyms and tools out there.

Below, we’ll take a look at how both DAST as a methodology and DAST as a tool relate to what we do at Detectify. More specifically, we’ll explain how Detectify’s solution applies DAST methodology with an External Attack Surface Management (EASM) mindset to deliver the most value to AppSec and ProdSec teams.

TL;DR: There is a common belief that when it comes to uncovering bugs in the DevSecOps cycle, catching things early on is often better. While this approach certainly works well for Software Composition Analysis (SCA) and Static Application Security Testing (SAST), it doesn’t really apply to Dynamic Application Security Testing (DAST) in modern environments.

Many security teams have thousands – if not hundreds of thousands! – of known assets and unknown assets that they continuously monitor for vulnerabilities and risks. Viewing large volumes of assets can be cumbersome, particularly when observing a specific characteristic of an asset, such as the technologies it’s hosting or its DNS record type. That’s why we’re adding additional customization to the All Asset view.

Security teams know, bug bounty hunters, and ethical hackers know it: Large attack surfaces are hard to manage. In this day and age, if you’re a medium-large organization without a comprehensive External Attack Surface Management (EASM) program in place, there’s a pretty good chance that you have some hosts on the Internet that you’re not aware of. Despite this, the concept of EASM is still new to many.

Conversations about basic cybersecurity hygiene often start with a lecture on effective patch management. While proper patch management is certainly recommended, much more can be done. Say you’ve locked the doors of your house before leaving for vacation – an opportunist might only check to see if the doors are locked, but a persistent thief might try the windows or look for other ways in. Similarly, CVEs and CVSS serve a purpose, but they still leave you with many untreated risks. Why?

Gunnar Andrews discusses how ethical hackers can look to EASM techniques to help increase their ethical hacking skills. For organizations, this article gives insight into the methods and types of information that ethical hackers or even malicious attackers will collect to increase knowledge about an organization’s assets.