Maximizing Security Outcomes: The Role of ASM in Bug Bounty Programs

MG:
Hey Shubs, so today we're going to talk about bug bounties. So, you know, a topic that everybody likes to hear about from us, right? So, particularly you. So, in particular, we're going to focus on bug bounties, but in the context of, you know, a company that's running a program and how they can think of ways that they can optimize their bug bounty program. And, you know, for AssetNote, you know, it was born out of the bug bounty space. So, a lot of the principles there and a lot of the philosophy of AssetNote and our product, you know, comes from comes from the principles and the ideals inside the bounty space. So things like, you know, wide breadth of coverage when it comes to looking at an attack surface, heavy focus on, you know, deep mapping and understanding of an attack surface, you know, continuous, right? I mean, we do things hourly because the faster the better. You don't get paid for being second. And, you know, really high signal and high impact findings. You know, that's another sort of key characteristic. And all of those have flowed through to our product. And And so, you know, we do often get asked about, you know, how do we think about, you know, bug bounties? How do we think about bug bounties in the context of ASM? And so that's, you know, what we're going to cover today in this episode. So, you know, maybe a good place to start, and I think this would be good for you, is thinking about, you know, let's cut through the noise a little bit on bug bounties and think about it from a hunter's perspective. That might be the good place to start, where we think about, you know, what are some of the realities of how you evaluate what to hack on and how you approach it, you know, in terms of choosing what programs and where to spend your time on bounties and what's some of the reality there and what's your perspective as a hunter looking at that?

Shubs: Yeah, I mean, it's changed over the years, but these days, given that there are so many great programs out there, they're all really competing for the same slice of talent, really. And even over the last 10 years or so, what I've found is that there's still the same 20 or 30 people that are exceeding expectations. in all these bug bounty programs. And yeah, I mean, it is really interesting in terms of what programs I pick. And a lot of people out there might think, oh, the only way to be successful at bug bounties is to do private programs. But I'll be honest with you, I've only been participating in public programs for the majority of the last 10 years. And it's not as if you need to get those private invites to be successful, for example. And I also know that most of the talented people in the bug bounty space that I'm aware of, they also are mostly focusing on public programs, because it is those programs that are the most mature and are offering the most amount of money from a bug bounty perspective.

MG: Don't get me wrong. Interesting perspective too, right? Because I go to, you know, live hacking events with you and things like that. And it's all the same people, right? It's the same 30, 40, 50 people. And if you think about it in the context of the crowd, right? You know, it's a very, very small percentage of the crowd that's at that kind of tier. The vast majority are not in that tier, right?

Shubs: Yeah, exactly. And you might see some additions here and there, like some new talent coming in. But for the most part, it is that same 30 or 40 people. And over time, with the diversification of bank bounty platforms as well, we're actually seeing this crowd even whittle away, even in existing bounty platforms as they've moved to another one, or they're focusing on a specific program that's on another platform. So Yeah, it is getting a bit more fragmented, I would say. Definitely, each platform is fighting for the same talent, which I find really interesting, because that means that whichever platform has the highest paying program is the one that's ultimately going to win at the end of the day, in terms of this talent acquisition, at the very least.

MG: So would it be fair to say that the hunters follow the program more so than the platform?

Shubs: the hunters follow the payouts more so than the more so than anything else. And yes, that's definitely related to the program.

MG: Yeah. So it's also creating this sort of splintering effect in the market from the from the hunter side, where we're now, you know, thinking about it from a company perspective a little bit, and we'll dive into it a little bit more later. But you've got this you've got this sort of splintering of the crowd amongst the different platforms because they're following specific programs. So now you can't really sort of, can you really sort of say that if you're going to pick a particular platform because of the crowd, it's not really the right way to think about it from a company perspective. Like you should be thinking about it more from, I guess, you'll pay out in your program and the parameters that you set there. Yeah, for sure. Thinking about it from the perspective of attracting talent. Obviously, there might be differences between the platforms and their services that might sway you one way or the other, right? But from a talent attraction perspective, there's not really a single platform that holds an advantage there, right?

Shubs: Yeah, and to be clear, I think that the primary thing these programs are fighting for is our time. It's not like they need people to be looking at their attack surfaces, their software, whatever else. And let's say there is a program, like I could have multiple programs. There may be a program on HackerOne, that's great. There may be a program on BugCrowd, that's great. But if I find that the one on BugCrowd is paying significantly more or vice versa, that's where most of my time is going to go, because that's naturally where I want to maximize the amount of, I guess, outcome I get for the effort that I'm putting in. And this is what I'm seeing, honestly, is like, at least between all of the top bug bounty hunters that I've worked with over the last couple of years, everyone is focusing on the programs that have the highest payouts. And that means that an entire platform can be forgotten about, like HackerOne or Bug Crowd, whatever it is, or the other platforms. They can just be forgotten about until they're done with that program. And that might not be for a long time. It might have to take that program reducing its payouts or them treating you unfairly or something happens. Only then you make that decision to then move off that platform and go to another program somewhere else. And yeah, that's, that's really what I'm seeing.

MG: Yeah. Yeah. And, you know, I think it would be fair to say as well, if you think about, you know, all of those points that, you know, the top tier, like when we're talking about, you know, that that top 30, 40, 50, you know, which is basically the top 1%, right? Or even potentially even the top 1% of the 1% in a way, you know, they're not necessarily hacking on hundreds of programs at a time, right? You know, there's, there's maybe two or three, you know, that they're focused on at any given point in time, right?

Shubs: Yeah, unless you're doing a lot of automation and even then at best, you're just getting through dupes in some scenarios where you beat the race. Most of the time, most people manual hacking, they're focusing on individual programs. And to be fair, I think you'll probably get into this later in this call. Um, you don't actually want to be paying for a lot of these automated issues in the first place. You want to be paying for that undivided attention from a hacker. from a manual hacking perspective, which actually leads to real security impact beyond just, oh, you know, you've got a misconfigured DNS record here or an open S3 bucket there.

MG: Yeah. So in terms of tracking the talent, right? So we've spoken about, you know, large scope and large payout, basically. So, you know, with the payouts for the individual bugs being high, you know, there's more potential reward for your time. And with a large enough scope, there's more potential to find more of those issues, right? So, but what about beyond the payouts? You know, there are other sort of, you know, elements of a program, like the terms of the program or, the, you know, anything else like that, that kind of influences the decision, whether you're going to invest time in it or not?

Shubs: There's one really big factor that influences that decision, and that's the speed of the payouts. Often what I find, especially for myself and other hackers included, if a program is going end to end, resolving a bug or paying it out at least within a week's time, and I would say a week being probably around the sweet spot for attracting this sort of crowd, people are much more likely to participate in that bug bounty program, especially be loyal to that program. If they treat them in a way that's okay, we've verified your issue, we've validated it, triaged it and paid you out within a week, then you're going to attract a lot of hunters.

MG: Yeah. What about other things? Right. So like, you know, one of the things that we've spoken about a little bit on, on previous calls and people, you know, who, who, follow the work that we do at AssetNote, we'll know that we spend a lot of time, you know, researching, you know, security vulnerabilities inside large, widely deployed enterprise software, right? We spoke about in the last episode on, you know, shadow exposure and why we focus on that kind of research. But this is also something that I think I see in that sort of really top tier of the bug hunting community. where they go deep on that and look for those more fundamental issues. And, you know, how does that play into, you know, other things that we've also discussed and touched on a little bit in the past? Things like, you know, disclosure policies and NDAs and, you know, even something like, you know, HACA1's new zero-day window. You know, how does that impact, you know, from a top bug hunter perspective, like what you're willing to do through these programs?

Shubs: Yeah, for the most part, any vendor software that's running a bug bounty program, if you ever report a vulnerability to them, you're not going to be able to speak about it publicly without explicit permission from them. And this is something that I think a lot of hackers have caught themselves in that sort of situation where they've reported something and they've wanted to talk about it, but they're unable to because they've agreed to the default terms and conditions of the platform. So that's definitely one to keep an eye out for. But I think the more interesting one, and definitely one that's really causing disparity between the platforms, is this new HackerOne policy around vulnerabilities in third-party software. Essentially, for those that don't know, HackerOne has published some detailed platform standards that they enforce across their platform, and one of them is around third-party vulnerabilities. Basically, what they state is that you're not supposed to take a third-party vulnerability and use it on other bug bounty programs before it's been communicated with the third-party owner and it's been patched by the third-party owner. And this is a really interesting area because, you know, HackerOne's the only platform that has this standard. And I think that, to be honest, my opinion on this is that there are a lot of customers that are sitting ducks now, which have many, many services on the internet that are affected by zero-day vulnerabilities. And bunk bounty hunters no longer feel comfortable reporting that on HackerOne's platform. At least I don't, certainly, from my perspective. But this is definitely a new standard, and I know that HACA 1 is trying hard to find a sweet spot here. But at the same time, this is really discouraging for a lot of researchers.

MG: Yeah, it's an interesting one, you know, and when we think about in the context of what we do, because on one hand, I think the standard of how you should be reporting this to the vendor first is the right is the right position to take. But then, you know, this kind of arbitrary limitation on the exploitation of that, you know, through these bug bounty programs, the reporting of that through these bug bounty programs, is, as you say, leaving a lot of people open and exposed. So anytime that we do research, we report it to the vendor first. That's the right thing to do. And we want the vendor to get started on a fix, basically. And, you know, but we also then put it in the platform for our customers, so they understand, you know, where they're exposed. And we provide, you know, the mitigations, we've spoken about the work that we do on the mitigation side for the zero-day research to these guys, so that they're well and truly ahead of the curve in terms of being protected. And, you know, the reality is that these sorts of vulnerabilities don't just come into existence or spring into existence when a researcher finds them, right? They exist in the software for however long they've existed in the software at that point. And so, especially once Word starts to get out, you know, there's advisories released, even, you know, things like that, you know, people start to research this stuff. It may already be actively exploited or known about, you know, and there's also There's also people, you know, reverse engineering, you know, issues, things leaking out, you know, all kinds of potential scenarios there. And then arbitrarily limiting the visibility that, you know, companies and customers ultimately get into that is not, I think, not really like a good position to take. And it's just exposing that, it's just creating a level of exposure that's unnecessary, but I also am sympathetic to the position that these sort of platforms are in, right? Having customers on both sides of that equation and how they manage it. So I do get that, but from our perspective, from a security perspective, I think arbitrarily limiting what you can do with that is not ideal. It doesn't produce ideal outcomes for the end customers at the end of the day.

Shubs: Sometimes these vendors aren't even really playing ball here with fixing these issues and for however long that these issues aren't fixed, you've got this exposure across the internet for whatever customer that's affected by this. I refuse to believe that only one single person can find that security issue. That issue exists. It's existed for a long time. It's not as if someone else can't find it. I don't understand why there's this level of secrecy. I mean, we've seen it over the last couple of years with ransomware groups exploiting zero days and managed file transfer software. Like, yeah, those zero days existed for a long time. I'm sure they were part of the arsenal of many different groups before the zero days were exploited by the ransomware group. So it's just one of those things where I feel like, you know, if we're genuine about this idea of securing the attack surfaces of, you know, customers, then this needs to be accounted for, this needs to be something that can be at least safely shared to these customers in a way that they can remediate these issues before someone like a ransomware group comes along, exploits them and encrypts them.

MG: So, I mean, I know we can talk about this sort of stuff at length, and I know we've discussed in some other episodes, but maybe coming back to this idea of, okay, so you're a company that runs a bulk bounty program. How do you get the most out of it? And what are some of the ways you can get the most out of it? And maybe starting at, what does all the stuff that we've discussed so far mean as a company running a program. I think the first thing that we've touched on is that it is a two-sided marketplace, right? Where you've got the bug hunters on one side and the companies on the other, and they're both in competition with each other on the side of the market, right? So obviously, a lot has been written and said about the hunters competing with each other and having to be first and thinking about speed and whatever in their processes. But perhaps what's less talked about, which we've discussed so far, which is that the customers, the ones running the program, they're also competing with every other program, one on that platform, but just in general, across multiple different platforms. And if we say that hunters, or at least the top hunters, are attracted to large scope and large payouts, if you don't have large scope and large payouts, how are you gonna compete with those that do? And what level of talent and what level of scrutiny are you actually getting at the end of the day you know, on your attack surface. And so, so that's, you know, that's one thing to consider. And I think, you know, if you're the reality is, if you don't have, you know, a high payout table, particularly for the, the upper end of town, you know, you're at a you're at a real disadvantage. And at the end of the day, you know, that's not necessarily something that's easy to solve, you know, because, you know, companies are different sizes, you know, different levels of budget, different levels of commitment from, say, executives into the security budget at the companies. And so that's going to vary widely and you might be constrained with your capability to be able to match that. And so what you really should be thinking about is really optimization. And we'll get to optimization in a little bit and what we mean and some of the things that we would recommend and how things like ASM can help with that. But the other thing I would say as well from a company perspective is most of what you're going to see when you open up a bug bounty program is scan traffic from open source scanners. That's just the reality. That's probably in my estimation, you know, and these are just rough, rough numbers, I would say that's 90% of the activity that you're going to see on on any given bug bounty program, right? It's not, it's not the the activity that you see from like these top tier bug hunters that present their research at conferences that everybody just is in awe of, you know, in terms of how they got there and what they did. That's the exception, that's not the rule, I think. As a company, you have to be prepared for that onslaught, the good and the bad. What that means, I think, is that you need to have a certain level of maturity before you can really, you know, optimize and get the most out of a bug bounty program. And I know Katie Mazuris like talks a lot about this. She's OG bug bounty, like well before any of the platforms came into existence. And she talks about this point all the time, you know, bug bounty is good. There's a lot of value in it. It's a, it is a, um, It is an important part of a mature security program, but it's not the only part. And it's not a silver bullet. It doesn't solve all the issues. And you do need to be at a certain level of maturity. If you struggle with process for identifying, you know, attributing issues to owners and fixing them and remediating them, you know, opening yourself up to a bug bounty, it's just going to multiply that problem by 10, by 100, you know, whatever, right. And so, you need to have that and she's 100% spot on with that point. So, yeah, I mean, like, do you have any other thoughts on, you know, thinking about it more from the company side of what this sort of stuff means, you know, for companies in reality?

Shubs: Yeah, I think that, um, I think that there's, there's a few elements. Um, firstly, like I've seen a lot of companies that have come into bug bounties as well, where they, they, they don't, they're not able to stay on top of the amount of things coming in. And as you mentioned earlier, with a lot of people using open source scanners, they're often submitting a lot of things that may look kind of real, but actually require some sort of investigation and turns out that it doesn't have any security impact and so on and so forth. So. What I've been seeing, especially from the spray and pray crowd, if I'd like to say, is, you know, they're basically chucking all these new checks directly at every new bug banning program. They're inundating them with so many submissions where, you know, and, you know, obviously HackerOne's triage and BugCrowd's triage deal with this on a day-to-day basis and the other platforms as well. But there's just so much of that noise, I guess. And, you know, like, Certainly, as someone who's trying to invest in the security of a company, you cannot have that much noise if you don't have your basics covered, which is what I think you're trying to get at generally, because you're trying to actually get some level of maturity before you can comfortably do a bug bounty program and have that comfort.

MG: Yeah, if you can't easily, you know, filter out that noise, then it's just gonna become a problem. And, you know, it's kind of interesting when you talk about like the, when we talk about this idea of the scan traffic, right? And everybody, the pray and spray, spray and pray crowd, right? Like, I like that, I like that term. But, you know, what's interesting about that is that it's really homogenous. And what I find even more interesting is that, you know, it's not just the security researchers and the bug hunters that are utilizing the exact same scanning of the exact same signatures for good or bad, right? Like, you know, whether there's good outcomes or, you know, the signatures have false positives or they're terrible or they're noisy or they're not identifying things and they're missing things, you know, whatever the good and bad of the output of that. it's all the same. And what I find really interesting is actually is the rise of the use of these open source scanners in products, right? In security tools. It's one thing for a company to say, okay, well, we'll use that internally so we can kind of get on top of this and preempt that output, right? That's very smart and that's a good idea, right? But you know, security products that charge money for it, they're not differentiated anymore, right? They've got the same scan engine, the same scan output that any company can go and get for free, which I just find hilarious, right? And it leads to a lot of homogenization across these security scanning tools. But maybe that's a separate point and something to dive into. But when we think about what companies can do, I think the key way to think about is like, how do you optimize this? How do you maximize the outcomes that you want? Which is you want the highest security outcomes for the least expense and layout. And so really what you wanna be doing is avoiding sucky payouts. And what do I mean by sucky payouts? These are things that, you could have found with some sort of open source scanner. This is stuff that you should have been aware of that is real and that is an actual issue. But because the payouts of a bug bounty program are tied to impact, it's still impactful. You're paying out a lot of money for something that you just don't really feel good about paying out. And, you know, I've had this, you know, I've had customer conversations, you know, where they've come to us and, you know, one of the things they say is like, I just want to stop losing to these kinds of, you know, shitty issues, basically. And, you know, I think, I think, you know, that's, that's really at the heart of, you know, how we optimize you know, a bug bounty program. So really, you know, if we start to sort of dive into that kind of concept a little bit more is, you know, you want to avoid, you know, paying out for stuff that really you should be able to find yourself more effectively, you know, in a way that's more economically effective, you know, where you know, maybe it's, you know, something where it's an open source scanner, at least, you know, at least you're getting the bar of what everybody else is just throwing at your assets. Or if you want to raise that a little bit, you know, something that's, you know, I cut above, but something that is on a fixed fee basis rather than variable. I mean, we've seen this happen where you know, you find enough criticals on an attack surface, you can kill a bug bounty budget in one night. I've seen it at events, dude, where they're huge companies that already know that they're going to pay out a lot of money for this event, you know, in the six and seven figures. And they still run out of budget and have to deal with that halfway through the event. You know, we've both experienced that, right? And so, you know, I think getting to a state where you can kind of preempt that and avoid paying out for those sorts of issues is a huge win, right? Because then that sets you up for being more competitive as a program in general, but also reduces the noise that comes out of your bug bounty program, or at least makes the noise easier to manage, right?

Shubs: Yeah, and just going back on that point about open source tooling and stuff, what I find really funny is almost every, all the best hackers I know don't use any automated tooling when they're looking for security issues. Like they're not spending time on that. And those are the hackers that you really want to be, you know, attracting to your program at the end of the day. And those are the, you know, the Franz Rosen's of the world, the Matias's of the world, where they're actually going to deeply look at the application and understand exactly what's going on in order to find these really deep, difficult to find issues. Anyone can run scanners. It doesn't really lead to the outcomes you're looking for from a security perspective because anyone serious about breaking into your organization is going to go a few steps further than just running a scanner.

MG: Yeah, you're not raising the bar that much if that's the level that you're going to. And yeah, it's kind of interesting, like even the automation that I see that sort of top-tier use, it's very bespoke. It's not this sort of mass market off-the-shelf kind of stuff, right? It's very targeted to specific techniques that they may have developed or or something that's kind of unique or, you know, even on the recon side, you know, kind of following on from what we spoke about in the previous episodes, you know, a few episodes back, you know, thinking about, you know, what they're actually trying to achieve and then automating that at scale rather than, rather than generic kind of techniques. And so that's kind of interesting. And when we think about the scanners, the other side of it as well is when you open up a bug bounty program, you're opening yourself up to continuous evaluation, right? So you do need to have processes and tooling in place that is also continuous. And ideally, you know, highly continuous, like faster than what you're going to be getting out of a bounty program. You know, if you can kind of beat the hackers at their game, particularly, and more specifically, the spray and pray crowd, right? If you can kind of beat them at their game and be faster than them, and more optimized than them, and ideally, with automation that's a level above them, then you're just basically shutting that off, right? In terms of paying economically for that output. Because if you beat them to these sorts of findings, it's a dupe, right? They don't get paid for dupes. You don't have to pay out dupes. If you if you beat them at the game in terms of the discovery, right, so you've got a full complete picture of your attack surface that is, you know, a bare minimum as good as what somebody else is going to have from a hunting side or better, right, then you're in a position where you can preempt those sorts of issues where you've got this asset that nobody knows about that, you know, still has real issues on it, impactful issues, that's just, you know, easy to exploit and easy to identify, just because, you know, they've found the asset and you haven't, you know, and if you can start to do this, and of course, you know, given modern environments, they're highly dynamic. So this is not a one off thing. You can't kind of like, uplift your maturity and look at your scope on a once-off basis and that's it. Because your attack surface is constantly changing. And so you need to be looking at this continuously and you need to be trying to beat them and be more proactive and more preemptive of the stuff that's coming there. And then what you'll start to see is that you don't have to pay out for these low-level, terrible findings that you don't feel comfortable about. And once you start to get to that point, that's where you can start to offer higher payouts because you've got confidence that you can manage this and you're managing this internally. that you can open it up and then you start to attract the top tier that's going to look for these deeper issues that are going to provide the level of scrutiny that even if it's 5 or 10k for a critical that they find that you really don't feel bad about paying for it because it's really worth it. What you want to avoid is feeling bad when you're paying these sorts of things. And some of the, yeah, go ahead.

Shubs: Sorry. Speaking about, um, you know, beating bug bounty hunters to findings. We've done that several times at AssetNote. And, you know, what's funny is sometimes some of these people will reach out to me being like, how did you do that? How did you beat me? So this is just cause we're going at that speed and we're at that scale. And we have that much knowledge of an attack surface that we're able to beat bug bounty hunters consistently. So this is something that, you know, I've, I've spoken to several bug bounty hunters about like, yes, like we, we beat you. Um, but there's, yeah.

MG: And we have a team of highly talented engineers and security researchers that are pushing this stuff to the limit, right? To be as fast as possible, you know, for this exact reason at the end of the day. But it is always funny when we get those messages from bug hunters, like kind of annoyed that they didn't get a nice bug because we beat them to it, you know, with the platform and the customer. And so, the other side of it, actually, we touched on it a little bit, is scope, like optimizing your scope. Now, a lot of the bug bounty platforms will advise you that you should be progressively opening up your scope, right? Rather than going full scope, whole hog, whole attack surface, star dot, whatever, you wanna be kind of progressive with that, which is good advice, right? But if you don't have a good handle on what that is, and again, a continuous understanding of what that is, then you're still not being as optimized as possible. Because if you don't have a good understanding of what makes up your attack surface at any given time, and then tracking that as it evolves over time, and the level of maturity and exposure that exists in those points, how are you gonna be able to make informed decisions around what you progressively open up? You might go too hard too soon. You might have stuff in your scope that you think is a good scope to open up, but is kind of like actually terrible because you've missed half of the stuff that does fall under that scope. And so, having a good, and up-to-date understanding of your attack surface is really critical, I think, in terms of being more optimized in the outcomes that you're going to get out of your bug banning program. And so yeah, the final point, you know, probably I think in terms of optimization, and this is just sort of coming back to the same theme, right, is you're really avoiding that low-hanging fruit. And, you know, we've spoken about it in a couple of different ways in terms of you know, being continuous, having scan capabilities that are cut above, you know, what the bug hunters are throwing at you, and also, you know, having processes that are in place that support that and are mature and effective in terms of supporting that, you know, visibility and continuous assessment. But ultimately it all comes down to the same point that when you start to filter that out through these sort of more proactive measures and these more consistent measures, you're then raising the bar in terms of what you need to pay out. you're then taking away the stuff that is not value for money at the end of the day, right? If you're getting something that's critical on an asset that's in scope, that could easily have been found through some level of automation or some level of process internally, or whatever the case may be, for a much lower price, then you're just wasting money at that point. And what that means is if you're spending too much on those sorts of outcomes and those sorts of issues, it does limit what you can do budgetarily in terms of offering larger payouts and incentivizing and attracting the higher tier hackers to your program. And I think that really comes down to that point of like, you need to just raise the bar. And then once you can do that, you start attracting the higher the higher tier hackers and with the higher payouts and you're still getting optimized results because the outcome from those guys, the guys at your level and the level of the guys that you mentioned like France and whatever, that's what you want, right? But you need to pay for it and if you don't have the money because you're wasting it and you're not optimized, then you're not going to be able to offer that realistically. you know, that's, you know, probably the overarching kind of like message or way that you can optimize this. And I think, you know, ASM is, you know, is a good way that like a good ASM, at least a true ASM will cover off all those areas for you. So that will be a way that you can, you know, utilize that. And, you know, we have many customers that run you know, bug bounty programs and, you know, we've touched on some of the feedback that we've received on that. But that is, you know, one of the interesting and core use cases that, you know, those customers in particular, you know, have with AssetNote is that they are utilizing it to optimize their bug bounty program. And, you know, you probably, you know, and it also helps as well, we've got integrations with with the major bug bounty platforms as well. And it kind of just, you know, helps to seamlessly sort of work within these processes. But ultimately, it's these more fundamental, you know, principles and ideas that they're going for, you know, that's being enabled through that level of thinking.

MG: Cool. So, any other points to wrap up on the bug bounty side? Anything you want to add?

Shubs: Yeah, I guess there are some bug bounty programs out there that are really hard to compete with. seeing this convergence of some of the best hackers focusing on the same bug bounty program just because it's so hard to compete with. I think that in this market, you have to really be competitive either in speed or in payouts in order to attract the same bug bounty crowd that you're looking for from a security analysis perspective. That's just my opinion coming as a bug bounty hunter and also as someone that helps build an ASM. Um, you know, we, we, uh, can definitely help with a lot of the fundamental issues that are, you know, solved through automation. And we have many techniques that no other ASM or tooling has, which really, frankly, um, some of them are more akin to some of the more advanced techniques that some of these hackers are using in the first place.

MG: Yeah, I mean, that's what we hear a lot from these, you know, particularly these customers that, you know, this is a core use case for them is that, you know, what comes out of our platform is a lot more like what they're getting out of their bug bounty program instead of, you know, what they would get out of any kind of traditional scanner. You know, which is, you know, just again comes from what we discussed earlier, like we're from this space and we get it, right? And we're pushing to be at that standard and that level. And yeah, I mean, it's kind of interesting, you know, it's an interesting topic at the end of the day. you know, conceptually, it's kind of easy. It's like, yeah, okay, well, you want better output from your program, you know, pay more, right? But like, if only, you know, pay more was easy. You know, there's a lot that's packed into pay more. And I think Hopefully what we've been able to cover is how you can think about some of the tooling and the processes internally and ways that you can start to approach how to optimize your existing spend so you can push your existing budget further. I'm sure there's a bunch of CISOs and managers and whatever that would just love to like, yeah, I'd love to just be able to pay more. It's just not that easy in reality. So, you know, hopefully this gives some kind of, you know, thought to that and, you know, gets that sort of thinking, you know, if you're in that position, you know, think of some of these approaches that you can take. And so, yeah, I think we can call that there and wrap that up, you know, another good episode. Thanks to everybody who's been listening and watching this and providing feedback. We really appreciate it. And yeah, if you're interested, always, you know, check out Asinote, asinote.io. Too easy. Thanks, Chubbs.

‍