Rickard Carlsson, CEO of Detectify, recently joined as a guest speaker on the Application Security Weekly Podcast hosted by Mike Shema, Matt Alderman, and John Kisella.They discuss how Detectify’s solution is a game changer by combining the speed of automation and hacker expertise, why you should trust developers with security, and how the modern digital landscape requires even devs to look at the asset inventory.

We’ve highlighted some interesting points in the interview. Note that this transcription has been edited for brevity, and you can enjoy the full episode and commentary in the following video:

How to scale human ingenuity 

Mike Shema:

I want to dive in, right from the beginning, about this combination of human ingenuity and automation for web application scanning, or perhaps DAST. We’d love to hear more of how to take the smartness of a human looking in detail at one web application, like in manual bug bounty hunting, and then trying to figure out how to do that with not just 10, but maybe 100 or 1,000 more applications.

Rickard Carlsson:

My co-founders’ strengths are in the responsible disclosure and bug hunting scene. And they all started to see how automation was simplifying their own lives and security research abilities.

They asked, “What happens if we stay on this approach [with bug hunting] and add a few more hackers to it and build an automation engine powered by the freelance hackers ..?“

Mike Shema:

An organization, a company, might not even have an application security team, or their application security team might be two or three people.

So, you bring in a bug bounty program, and you perhaps get that two or three is now augmented by 200 or 300 or 2000 or 3000 [looking at app security]. Why can’t we just keep throwing people at this problem and actually have 10,000 hackers [manually] looking at this web application and say that’s enough?

Rickard Carlsson:

There are things that a machine should do and is good at, and there are things a human should do and is good at. And I think machines are good at solving things and doing things in a consistent, repetitive way. Whereas humans are good at finding new approaches and new angles to things.

Our approach is if something is repetitive, why should a human do it? Leaving such a task for a machine allows for humans to focus on the more ingenious things instead.

“Detectify is 100% payload based. So if we cannot execute a payload and weaponize it, we generally don’t accept the Crowdsource hacker’s POC.” – R. Carlsson

Detectify takes things that a human has figured out, scales it up with automation, and puts it into the hands of people that need it. The idea is if you can take things from a human, automate it, and then make the knowledge available to millions of others, then I think we can reach a different level on solving the problem.

In the real world, a few hundred or a few thousand people in the world are extraordinary at application security. Still, you have 30-40 million developers out there [building the apps]. How do you scale the knowledge of a few thousand to the range of 30-40 million?

Mike Shema:

If you look at any of the numbers that the bounty platforms have published, you tend to find that the smaller group of researchers uncover the majority of the vulnerabilities. And so, it’s not just that we can scale out with humans, which if we’re going to talk about DevOps, one of the tenets there is also just let’s scale as much as we can through automation.

The bug bounty-automation hybrid

Mike Shema:

What does it mean to automate what you’re doing? In other words, walk us through a little bit of this process to say, you’re collaborating with a handful of these researchers; what are you doing to turn their brains into code?

Rickard Carlsson:

The ethical hackers we work with (Detectify Crowdsource) find a new attack vector, a new attack pattern, that can be repeated with automation. So we aren’t looking for submission of in detail privilege escalation or an IDOR attack, preferably something that’s replicable by the machine.

We accept code snippets and attack vectors from Crowdsource hackers. We verify and then build a module out of it. If it finds a vulnerability in one of our customers, the hacker gets a bounty back. If their module finds a hit on 10,000 customers, then they’re paid 10,000x. The more customers we have, the better it is for the hackers, but not with added work on top for the hacker.

The better hackers we can attract, the more security tests we can build, and the more bugs we detect for our customers. We are building a platform that can benefit both sides.

Mike Shema:

The both-sides aspect definitely appeals to me. You’ve got two audiences: one, application owners that want to find the vulnerabilities/flaws in their applications and fix them, but you’ve also got the people creating, applying their ingenuity for developing these tests, but also getting benefit out of them. I really like that way of embracing the community so they can benefit from that work. 

Are there certain types of vulnerabilities that lend themselves more easily to the modules Detectify builds vs. the ones you find yourselves saying that “Ah, we still need humans for this particular category of the problem?”

Richard Carlsson:

I would say vendor-patchable vulnerabilities aren’t well suited for our kind of automation. That refers to issues such as in AWS where they can just flip it and patch it for everyone, and the lifespan of that vulnerability is very short.

What serves Detectify’s automation is, for example, misconfiguration issues that aren’t impacted by a new patch where you clicked the wrong boxes. Then you (accidentally) make yourself vulnerable.

Another vulnerability that isn’t well-suited requires a human to interpret the results, which is, as I mentioned earlier, IDOR attacks or privilege escalation. It’s relatively hard for a machine – in a scalable way – to see if this is a basic account or a privileged user account. Detectify is 100% payload based. So if we cannot execute a payload and weaponize it, we generally don’t accept the Crowdsource hacker’s POC. 

Mike Shema:

So it’s very much that single request-single response is one of the easiest ways. And honestly, it can be some of the most consequential if you’re talking about RCEs, SQL injection, other types of injection attacks. 

“If you take a fully integrated DevOps team… the 10X difference does not really exist because the difference between staging and production is 10 minutes.” – R. Carlsson

Get a hold of the asset inventory

Mike Shema:

Let’s switch to the fundamental aspect of finding all the apps you need to protect. It’s not only about the developers working on one app and deploying it; organizations also procure and deploy other apps. They spin up cloud resources and sometimes leave them there as well.

How does Detectify approach finding the applications and doing that application inventory before going after the vulnerabilities?

Rickard Carlsson:

When we started to receive submissions and started to automate them, we realized that there are many things to detect. This includes what your company builds itself versus things that your company hosts like a Grafana or a Confluence server. They can be equally vulnerable, but you would never put them through your static code analysis, but they are there, and they are a security risk.

My co-founders learned this through their bug hunting: the digital footprint that organizations are exposing is much more than the things you build; it’s also things that you host and ones you configure. And if you don’t test all of this with a modern web application, numerous things go undetected.

And for this, which we do something that we call Detectify Asset Monitoring and Asset Inventory. These are the modern versions of port scanning and IP port scanning, where we use DNS brute-forcing and DNS dictionary attacks to layout an external footprint. The automated modules powering these come from the hackers.

Mike Shema:

One thing that also appeals to me about this type of approach is subsidizing many researchers to be running subdir or lots of different brute-force DNS tools. In fact, as an organization, you should be running yourself and paying to have run. So you can have the tool run once rather than 10 people running the same tool is what I’m going after there.

Rickard Carlsson:

On the first topic related to this brute-forcing – to some extent, we do brute-forcing – but you can only get so far with brute-forcing and DNS dictionary attacks. In some cases, we integrate directly into companies’ DNS servers and just tell them, “it says that you’re actually hosting these things, but they don’t know what these actually are hosting.”

These direct integrations allow us to show a much bigger footprint, and we see more than a bug hunter because we get the truth directly from the source, such as the Route 53 server. 

Mike Shema:

Great answer because one of the things you just highlighted is that if you have the information, why not leverage that information to make the scanning or analysis more effective than making people guess? Give them that map of the terrain.

Trusting your developers with security insights

Mike Shema:

When you talk to companies, are you talking to a security team, or are you talking to developers from a security-minded perspective? What is the adoption experience

Rickard Carlsson:

We want to make security accessible for any size of the company. If we’re talking to big organizations, they tend to start to roll in the different development teams one-by-one, which lets us prove our value. And if you like it, then roll it out. Don’t overcomplicate things.

Mike Shema:

On the pen testing side, there’s this concept of doing a vulnerability scan before you have a full-blown external pentest or before you sign up for a bug bounty program. There’s a set of steps; there’s a maturity you go through. How do you enable that same kind of journey for your customers? 

I assume that size and maturity have something to do with it, but how should they engage with a solution like this? Where should they start, and how do they get to that kind of end state of, hey, I’ve got this kind of outsourcing, almost bug bounty program?

Rickard Carlsson:

Here’s a typical dialogue we get into:

Vendor: “we would like to test our staging and pre-production environments.” 

Detectify: “How often do you test your production? And how fast do the engineers and developers get the results from production?”

Vendor: “No, but we cannot do it on production because that’s unstable, and we don’t dare to do that.”

Detectify: “Okay. But there is a world out there…”

If you don’t run recurring testing on your production environment and aren’t able to feed that information directly to the engineering and developer team – potentially through a quick triaging process – then why do the complexity of testing the staging environment? Finding vulnerabilities in staging doesn’t matter; what matters is what’s live.

I also hear of dialogues asking about outdated beliefs such as testing and finding things later in the development stages will have a 10X extra cost variance – if you find it – for each step later. If you take a fully integrated DevOps team that specifies, tests, builds, codes, ships, and owns it, this 10X difference does not really exist because the difference between staging and production is 10 minutes

John Kinsella:

I don’t get this. That story which you just said, we’ve had this for at least a decade, if not two or three. “Oh my God. Don’t test production.” Why does this still exist? Do people take that, the hackers are going to, “Oh, let me go and hack their development site instead.” I’m sort of floored by that one.

Rickard Carlsson:

A company like ours, we build safe tools that are designed to run on production. Another comment I hear is, “But we don’t dare to forward this information directly to the developers because they may take advantage of it or use it against us.” And if you don’t trust your developers to handle security, then I think you have bigger fundamental flaws.

Matt Alderman:

Yeah. I mean, that whole trust discussion just floors me. Of course, you’ve got to give it to development; they’re the ones who have to fix it. How’s it ever going to get fixed if you don’t provide them with the information? 

Rickard Carlsson:

When I talked to modern tech company customers that use Detectify to monitor hundreds of applications, they put all the information available for all developers. Here everyone can look at anyone’s scores, and they go at it with full transparency. And then the question is, who’s going to be the safest?

Matt Alderman:

Exactly right. So, when you think about that onboarding for a second. Obviously, the first thing is asset discovery – what’s in production – and then test output. That’s a simple two-step process just to start, right?

Rickard Carlsson:

And do it weekly at least, or maybe even as soon as you update production. That could be a good start.

Mike Shema:

What are some other ways that you’ve seen developers get value out of seeing these types of scans or get developers more comfortable or the security team more comfortable with the idea that “yeah, let’s just scan production?”

Rickard Carlsson:

The best thing I think we find is when we get a comment back, “I learned something new today. Because I learned about an attack method, an attack pattern, or a way that made my application vulnerable and I didn’t know about it.”

We would like to get security contagious in a positive way so that people would like to learn and get more value out of it and figure out new things. I think that’s the most significant benefit you can get if you give people information and access to information. Hopefully, you’ve been able to hire curious minds that want to learn more.

Matt Alderman:

We’ve heard the stories of the challenges around training developers to be better developers and understand security. What better way than to give that data back to them so that it’s like this instant learning loop? They’re getting it right from their own code. They understand the context, making it a lot easier than they would just through some course material.

Giving security feedback at speed to researchers and vendors

Rickard Carlsson:

Quick and fast feedback is so important. I can take another different example: the record we have from receiving a new critical vulnerability submitted to our Crowdsource until we had it live and running against our customers is now 15 minutes.

Right then, it’s a fully weaponized version of the test and payload. In this case, this is one RCE is found in a big blue-chip tech companies’ platform. For the hacker, just seeing that feedback in 15 minutes after submitting it to see it live made such an impact on that person’s engagement. And I think it’s a side story, but just the fast feedback loops are so important in this.

Mike Shema:

That’s really cool to hear that, 15-minutes to develop and deploy a module and then start seeing it work in the wild. What else do you have in the future for either the modules themselves or the way that you’d be rolling out this type of capability?

Rickard Carlsson:

We do a lot of things just today, and it’s about speed optimization and scale. Because we want to get this faster and at a better velocity without giving up direct details. We are applying a combination of a bug bounty program, a DAST scanner, and a modern type of vulnerability management asset discovery type.

“…staging doesn’t matter; what matters is what’s live.” – R. Carlsson

For the cloud-native type of setup, you don’t have an IP range; the only thing you have is your DNS and DNS service. Just getting this to scale is the main thing that we’re working on at the moment.

Mike Shema:

Do you see something different between applications or how you are used against legacy apps versus cloud-native applications?

Rickard Carlsson:

Many companies we work with are seeing the benefit when they do testing on vendors. One of our customers continuously security tests all their vendors with our solution. They’re leveraging these discovery tools, and they have written into the contract that they can leverage and run attacks on vendors. We’re not a passive security solution. We don’t just look at headers; we actually send payloads. They’ve been able to leverage the Detectify discovery tools and all the payloads to beef up their vendor security. They send over a lot of reports to them based on what we have been able to find.

It’s a different approach to where you don’t have the full map of what you’re looking at.

Mike Shema:

I love that approach. I would love to be part of those conversations because it also opens up the idea of, “we’re not going to test our production, but we’re going to test your production” from that vendor security perspective.

Daytime developers have a knack for automated hacking

Mike Shema:

What’s been your experience in talking with security researchers, how they’ve interacted with either legacy apps, cloud-native apps? 

Rickard Carlsson:

I think what we have seen is that many the best security researchers are actually the people who are daytime developers and security addicts by night. In the daytime, they know how to build things, and in the nighttime, they learn how to break things

They’re often good at finding things related to automation because they typically would know how to exploit the different libraries well and find the back doors into things. They think, “I would have built something similar, and yesterday I made a small mistake here… so maybe I can use the same approach on this app because this developer likely did the same or didn’t know about it.”

Mike Shema:

One other question, anything else we should be really looking forward to over the next couple of months from Detectify? Are you going to be cloning and putting more brains into code, or is there something else we can expect from these modules or how you’re building out this type of capability?

Rickard Carlsson:

We are trying to move in the same way as the technology landscape moves. Our challenge is to keep up our automation platform in the same way that new attack vectors and new attack patterns emerge. Continue developing with flexibility. We don’t know what will come next because it depends on what happens on the security scene.

Mike Shema:

That’s a great point. Rather than create the tests for what you want, it sounds like you create the test for what developers are building and the directions they’re going towards, which I guess actually does make quite a bit of sense. 

“…if you don’t trust your developers to handle security, then I think you have bigger fundamental flaws.” – R. Carlsson

Rickard Carlsson:

We have built-in quite a few hundred modules this year from our community because we don’t know. They’re unknown, and we need to figure out whether we can automate them or not. A question we ask is, should we automate them? And if so, how do we responsibly handle them?

We need to be honest. We’re building a security tool that is a game changer for both the security experts and for the people who aren’t. We also need to be humble about what we need to learn and educate people about what we find and verify in the right way.

Thank you to the Application Security Weekly podcast and host Mike Shema for bringing Rick onto the show to talk more about automation and human ingenuity. View the Application Security Weekly show notes here.

---

Let Detectify scan your web applications for the latest vulnerabilities, while you build the next big thing. Our security team brings vulnerability research from hacker-to-scanner in as fast as 15-minutes.

Join 1500+ security teams trusting Detectify to stay on top of threats and continue building safer web apps. Discover how this can bring clarity and scale to your application security with a free 2-week trial today.