Confusion in the Attack Surface Management Market

There’s a lot of confusion in the ASM (Attack Surface Management) market. Today we discuss the core principles of ASM, the challenges of building and maintaining an effective ASM system, and the importance of safety and accuracy in external attack surface scanning. We share insights on the differences between various ASM approaches and the key factors that distinguish a truly effective ASM solution.

MG: I guess what I wanted to talk about this week is diving into this idea of attack surface management and ASM, because, you know, it's been interesting, you know, we've been doing this for a long time now, we're like six years in to the business. And we were doing this well before attack surface management was a thing, you know, we were one of the first in that space. And it's been interesting to see how it's kind of evolved, you know, and how it differs from, you know, how we've thought about it. It's interesting, because for us, at least, you know, ASM has been about the core principles that we started with, you know, coming from the bug bounty space a little bit, right? It needs to be holistic, continuous and focused on finding security exposures. The core principle that we had was asset discovery was never the end in and of itself, right? Like we used to say that all the time. It was like, what do you want to do with that? And it feels like the market's kind of focused a little bit more purely on discovery and less on the exposure management side. And it's been kind of interesting to see how that has evolved and the kinds of different tools and products that have spawned up in this space and how people both from a company perspective, but also from an engineering perspective, think about ASM. You know, I remember, I'm much older than you Shubs, but I remember like in the early days, you know, back when I started my career, I was working for pen test companies, and every pen test company would have this service called, you know, footprint or digital footprint or external footprint or something like that. And it was basically like a one two week engagement of mapping out your external attack surface and providing a list of assets effectively at the end of it. You know, that's been around for like 20 odd years almost. And now like every single security testing company that does that exact same service calls it attack surface management, which is very different to the kind of in-depth engineering that we do to build a continuous and automated product. And so I wanted to dive into that kind of idea a little bit more in terms of how that has evolved. And also, you know, thinking about what is ASM at its core? And can you utilize these sorts of off-the-shelf tools and these open source tools to be effective or not? So that's sort of where I wanted to start. Do you have any kind of thoughts from your perspective on how that term has sort of evolved since we started?

Shubs: Yeah, I do think that it's — like when I look back at it, I am a little bit proud that I think we really made a movement in ASM when we started and we were focused really on vulnerabilities and exposures generally. I do feel that a lot of companies have kind of converged into this idea that we do need to find exposures, not just find the assets. But I agree with you. I mean, there's so much variance in the term. I mean, there's companies that are kind of like dashboard companies, there's companies that just collect assets, there's companies that focus on graphs, there's companies that are just focusing on connectors and things. So it's wild. And they all call themselves ASMs.

MG: There's companies that don't even do what I would consider ASM that call themselves ASM. I was reading a TechCrunch article not too long ago and it was like a typical, hey, you know, PR, obviously PR sponsored kind of thing — such and such company took X in a series A and it was like, attack surface management takes X series A round. And I'm like, okay, like, let's check this out. I look into it. And the article is talking about attack surface management, how important attack surface management is. And so I'm like, okay, who's this company? So I click onto their website. And there's not a single mention of the words attack surface management. It's a container security company. It was a company that was, you know, kind of automatically removing like unused dependencies and other things like that installed in these containers. And, I guess from some level you could call that like reducing your attack surface. But to call that attack surface management is a huge leap. And it had nothing to do with their product. And, you know, nothing to do with what, as varied as it is, the rest of the market considers ASM in any way — not even like asset discovery, right? Yet this article, and these VCs, I assume, were really using it as this kind of buzzword term, which is kind of interesting.

Shubs: Yeah. And, you know, I think the amount of variance that we have in this field with the term ASM is actually causing kind of a disservice to the general people who are looking to get into this field or buy a product in this field, because they often don't actually know what a real ASM is or what a true ASM is until they see one. And that's — sometimes they may not even see one, and they might just resign and say, okay, this dashboard company or whatever is giving me all my assets, that means I'm able to manage my attack surface. But that's not really what ASM means, at least not to us. And, you know, one of the things that I often find is — I feel like in the last couple years, there's been like this emergence in this open source space. And generally, with people trying to claim that you don't need an ASM from a vendor, you can build it yourself with off the shelf open source tools. And I also think that's a little bit of a disservice because it really, really doesn't go towards what we believe the core pillars of ASM are and what you need to be able to actually manage your attack surface. And, you know, it's difficult because there are a lot of people in the industry that may not come from an engineering background or may not come from an offensive security background that may not understand what is really required to manage your attack surface from a workflow perspective, from an exposure discovery perspective, from an asset discovery perspective. And even just from the raw engineering of making that happen as well. And I think, yeah, I mean, I often find that people — I don't know if this is just based on a few experiences I've had — but people often don't understand what goes on behind the scenes to build an ASM that's actually capable of doing what it says and what it's supposed to do.

MG: We get that a lot. I mean, like in the very early days, we got, why, you know, you're building out asset discovery, why are you building your own exposure monitoring engine? Why don't you just white label some scanner? And it's like, it doesn't work for what we need it to do. And like, we have a very specific vision of basically real time monitoring of your external attack surface. And that's a huge, as you said, behind the scenes engineering effort to meet that standard. And we're very focused on that standard. And we do that only because there's so much value that comes from it. But I agree with your point that the market — this sort of rhetoric out there in the market has led to a lot of confusion for buyers, right? Not just from the commercial sense, but also in this concept, like you're sort of saying, of the build versus buy element. I don't think they really understand what it is, or they don't have a good picture of what it is to sort of build and maintain this, to get a certain standard. And, you know, it's kind of interesting — we hear it very often with the people that we speak to, the companies that we speak to, where they'll say, like, we've looked at 4, 5, 6 vendors in the market, and then they heard about us. And they said, you know, we were ready to give up on this project, the state of the market is terrible. And then they sort of see us and they have comments like, oh, this is what I was thinking of when I thought of ASM, this is what I was looking for. And so this is the element where ASM is kind of really loosely defined by various marketing groups, as well as analyst firms, I guess, and it's creating this confusion. But like, there is still a sense of what they were hoping to get — there is something more fundamental to it, right? What they're looking for is that kind of complete visibility into the attack surface, not just what the attack surface is, but what are the exposures and the problems inside the attack surface and what do they need to do about it. And so you know, once you have that kind of understanding, obviously, they can evaluate different vendors and look at the pros and cons and do POCs. But I think an interesting kind of element of that is how it influences the kind of build versus buy decision making that's typical of a lot of companies, right? Particularly those that maybe have a stronger engineering culture. And, you know, they'll look at — like you said, there's a bunch of open source tools doing various components of what you might consider ASM. And they think, oh, well, that's easy. I'll just run these tools. I'll just string them together. But it doesn't really work effectively, right?

Shubs: Yeah, and the reason it doesn't work is because if you want to hit any of the same levels of continuous scanning, or the scale that you may need to hit in most cases, as well as quality and output and workflows, that stuff doesn't exist. So I mean, unless you go with an actual vendor, I feel like these days you're not going to be able to get those additional benefits. And even then, some of these vendors at the end of the day are just gluing things together anyway. It's like, you know, how many vendors do we speak to? And they're like, oh, we just glued this tool and this tool. And that's how we get this. And it's like, yeah, you're not gonna actually get the quality from that. So there is definitely an element of that. But, you know, I think one of the things that people can really often do when it comes to ASM — which is what I've seen — is grossly underestimate the difficulty of reliable scanning and quality output. Because that's the two things that I think — reliable scanning and discovery and quality output — these things are probably the most difficult things when it comes to building an ASM.

MG: I see this all the time. Right. Like, so let's dive into like the scale side of it, you know, thinking of scale, both from a discovery perspective and exposure scanning perspective and, you know, what it takes to engineer that. You know, I think what's kind of interesting as well is, you know, there's so many different people that get into this space and sort of, you know, like you said, glue tools together and think, hey, like, I've got a product that I can sell. But you know, there's often not a lot of core value there. When you think about our history, right? You know, a lot of the ideas around this came well before Assetnote was even formed six years ago. And it came from actually doing this, right? Actually looking at large attack surfaces and trying to find exposures from a bug bounty perspective, right? And so there's a lot of really nuanced elements to that that you only really get from experience that we've had from the beginning that, you know, you sometimes see people talking about. And it's just like, you know, three years into them starting a company, and they still haven't solved that problem that we had sort of solved from day dot, because we knew it was a problem from day dot. And that's kind of interesting. But on the engineering side, talk me through how you think about the scale and the challenges with scalability, because you're right, I hear it as well — oh, well, I guess it's easy to build this, you just take this tool, and then you just pipe it to this tool, and then you just put some pretty interface on it, and there you go, Bob's your uncle, you've got an ASM. But it's really not as simple if you're trying to get effective value for the end user. Talk me through some of the scale challenges.

Shubs: Yeah. Um, and I guess one of the things I will quickly clarify is look — like if you're just some random bug bounty hunter, probably using some of these off the shelf tools is not a bad start. But if you're an enterprise that's looking to actually build an ASM that's going to hit some of the things you need to do internally and actually be reliable, then you really need to think about this a bit more. And I guess when it comes to engineering, one of the things that's probably most important is the accuracy of the results. And what we find, and what we've found over the last six years, is getting to that level of accuracy on a very continuous basis comes with a lot of challenges that aren't necessarily related directly to the code that you've written or you're running. Sometimes it's often to do with the networking layer. Sometimes it requires you to really reconsider how you architect something or how you do a certain process. And, you know, the accuracy side of things is not a trivial problem to solve. Actually, like even just in terms of scale, right — the faster you're going and the bigger the scale, the more likely that your accuracy is just not going to be as good as what it is at a small scale. And that's due to various reasons, obviously due to things like timeouts, due to things like networking issues, whatever it may be. But I think that, you know, when a company says to me they're going to be building and they're not going to be buying, I feel that like they may not consider how much time it's going to take to actually build something that's reliable and performs in the same way as someone like a vendor like us that's been doing this for six years, that has kind of pretty much run into all of these issues along the way. And we've had to solve them — we can't not solve these issues. And they've been incredibly difficult to solve in many cases, but we've solved them. And this is where I find this whole argument of, you know, internally we're just going to glue some of these tools together, we're going to pipe it to some Jira tickets or whatever, and we're done. I don't actually think that they're recognizing what is happening under the hood, when it comes to what they're missing out on in terms of reliability and quality, as well as sometimes I feel like they can trivialize the problem.

MG: Yeah, a hundred percent. And, and, you know, I think it comes — I mean, there's two elements to it, right? If you don't really care about the value and the output at the end of the day, well, what does it matter? Right. And to your point earlier, if you're a bug bounty hunter, you have a different output, right? You have a different perspective. But, you know, one of the big things that we've focused on has always been about, okay, there's value in that approach, right? There's value in large-scale discovery and scanning and doing that quickly. But how do you make that consumable to the end user, right? To the customers who have to fix this. And I think that's a real part — it's kind of the management part, right, of attack surface management. And it's a part that's sort of forgotten, but it does come from the basis of having accurate and timely results. And, you know, I think there's some interesting points to that, right? If you look at it across the board, whether it's the asset discovery or enrichment side of it, or whether it's the exposure scanning side, there's a lot of challenges there, right? So like, for example, a lot of tools will just spit out any kind of assets, say subdomain assets that they get from whatever sources they're checking, right? That doesn't necessarily mean that that's real. Like there's lots of challenges there, whether it's like wildcard DNS wildcards, whether it's, you know, assets that don't resolve — like if a subdomain doesn't resolve, right, how relevant is it? Is that really an asset at this stage? And how relevant is that from an exposure monitoring perspective? And so I think there's that side of it. There's also really nuanced stuff. So if you're looking at doing something like port scanning, as an example, and you're a company using a cloud provider, if you're trying to do anything at any kind of scale, you run into heaps of problems. So the biggest one is accuracy if you're going too hard — we've experienced that on AWS and you can talk to that. But even just things like abuse requests around things as simple as port scanning.

Shubs: And you know, I think that some distinguished engineers might look at the bug bounty space as a bit of inspiration and see all these bug bounty hunters who are automating some of this stuff and say, hey, I can do this too. This isn't that hard. Right. Yeah. But let me tell you, there's a huge difference between what these bug bounty hunters are doing for automation versus what you need as an ASM. Right. Like for example, I have a very good friend of mine who's probably one of the best bug bounty hunters ranked top three on almost every platform. And I know for a fact that some of his methodologies, they work really well for bug bounties. But when it comes to something like an ASM that you need to use for your internal organization, they're not really ideal. Like, for example, just one example — I think one of the things I heard of some time ago was the way he deals with DNS wildcards, which obviously at Assetnote, we have a very specific way of dealing with that which we've refined over the last six years. But his way is, oh, if I see more than 50 or a hundred records under a single subdomain, I just discard all of them. Because who cares? And we'll just keep going, we'll just keep chugging along kind of thing — which, from a bug bounty perspective, he's just making quick decisions to get to the outcomes he wants. That doesn't necessarily mean that that's the best way to do it. It means that it's the fastest way to just kind of deal with that problem without too much annoyance. And, you know, I guess the other thing is, um, in the bug bounty space and generally with ASM — we do have a lot of open source tools on the market now. We do have a lot of signatures or templates that are written by the community. I don't really think that these templates and signatures have that much quality control, just based on my experience. And yes, there is definitely some quality control, like there's a PR process and a review process and so on. But it really doesn't feel the same as how we do it, to be honest, and how much rigor we put into it. So some of the things I'll often see is requests that don't need to happen or are irrelevant entirely, testing software that's never going to exist on the internet, or sometimes worse — when it's testing it in a way that's disruptive, sometimes testing it in a way that doesn't actually lead to the results that you're looking for, sometimes relying on out of band infrastructure that you're not in control of in any way or form, and it's just some third party you got to trust. Which I understand. I mean, it's the same as those vendors, but it's not the same in the sense that it's some open source tool.

MG: That's just some random service.

Shubs: You've got no contract with them. You got no nothing. It's just — yeah, you're going to just use their out of band infrastructure. Yeah. But, but anyways, there's definitely a huge variance between what bug bounty hunters are building for their tooling versus what you probably need as an enterprise.

MG: Yeah, and then the other side of it as well is just, you know, forgetting some of these elements — putting aside some of these elements, right? Like, you know, the accuracy, the speed and scale — where do you want to spend your time, right? Like, do you want to be there dealing with these challenges, right? And maintaining this sort of infrastructure? Or do you want, you know, as a security engineering team or as a security team, to be focused on the actual output of that? And, you know, what do you want to build? Do you want to build custom things on top of a platform that's handling all the scaling, the infrastructure management, dealing with AWS's extreme networking stack restrictions, all that kind of stuff? And then you can just build your sort of logic and your custom stuff on top of it. You know, or do you want to really be maintaining this kind of infrastructure on a day to day basis? Like what's worth your time. And, you know, I think what we've seen is that there's a lot of people that have tried that, that come to that realization eventually, you know, usually like a year or two in. You know, we were working with a tech company out of California, and it was one of those stories like I mentioned earlier where they were looking around for various products. And, you know, basically the gist of his result of that analysis was, you know, the ASM market is terrible. It's crap was the term that he used. Right. And he sort of put it out to social media. It's like, before I build my own, because there's literally nothing that serves my needs, is there anybody else? Right. And, you know, somebody in the comments on that post mentioned us. And, you know, that's where he had this sort of epiphany. It's like, this is what I was looking for. And so they're coming at it with a very specific expectation of what they want. And this company, like I mentioned, they're a tech company. They have a strong engineering culture. They could build something, right? It's not like they're completely averse to building something. But they recognized, obviously, that there is a maintenance cost to doing so. And so they were looking at the market. But they just weren't seeing anything that made sense. And so I think there is a bit of this interplay between this idea that the market is so fragmented and so confusing for these customers, that that drives, well, maybe I should build it myself, maybe we might get a better outcome if I take some of these open source tools or take some of this stuff and kind of just hobble it together to try and tick the boxes that I'm trying to get. But then, you know, I think our experience has been that they eventually realize that that's not an effective or sustainable solution at the end of the day.

Shubs: Yeah. And, you know, I think that it can be really tempting to build something instead of buy something. I just realistically — seeing some of these security teams that we work with, and a lot of companies in general — I feel like they're really hard strapped for time. And I really don't feel like managing an ASM is something that can be done kind of like as a side project or as a part time thing. It is a pretty full-on thing, even if it's just for a single company. Because as I mentioned earlier, all the same scaling problems that we deal with at Assetnote, or have dealt with already, are still going to hit every other company that tries to deal with this. And look, there are more and more ASMs out there now. And because of that variance, you don't know if you're going to be able to find something that fits your needs. I don't know if this is inspired by us, but I am finding that there is this convergence — that at least exposure scanning is becoming kind of a more common thing in ASMs today, which is really, really interesting, because we've been doing that for six years, right?

MG: So that's not like a new thing. That was the idea from the get go for AssetNote. And what was interesting is chatting to some of the other big players at the time — their perspective was like, oh, well, why don't you just build an integration with like, you know, a vulnerability scanner, and like, you know, just pass it over. Or, you know, isn't it enough just to tell you that you've got this technology running on your attack surface? Isn't that enough, right? That was their mentality. And, you know, I was talking to the CEOs and the product leaders at these companies. And we were like, no, that's not good enough. It's not good enough from a signal perspective. It's not good enough in the sense that nobody just wants asset discovery, right? Like what's the point? Just so you've got a list of assets — what they want to do with it is foundational and very important, but it's foundational in the sense that it enables other things, right? So if you just think about exposure scanning as a use case — the idea of why would you want asset discovery to pipe into a vulnerability scanner via an integration? Well, so you've got coverage of everything. So you're not missing anything. Because what's the point of scanning for security exposures if you're not looking at everything in the first place? You know, cause you're going to miss out on it, right. So, so, you know, it's for something else and it's to enable something else. And back in the early days, that was a very radical kind of shift that, to your point, people have been starting to catch up to. People have been starting to come around, I think it's driven by a lot of different things. It's driven by just generally customers sort of seeing that in various vendors that are doing that. And again, this is what I want. So it's driven by customers, but it's also driven by a lot of acquisitions in this space. You know, if you look at a lot of the acquisitions that have happened in the ASM space, it's been of those pure play discovery products, right, that are just doing discovery. And then they're building it into like a larger platform or integrating with other products that already exist for that exact same purpose, right? So it's like, well, these use cases — exposure scanning, threat intelligence, whatever — it's going to be made better by this, right. And so they're doing the same thing. They're looking at the same problem but solving it from different perspectives. So whereas we build it from the ground up, deeply integrated from the get go, they're coming at it through acquisition. Kind of top down — they've already got all these other products. I think that's kind of changed their thinking. For better or for worse, that's kind of gotten people on to sort of our thinking — that attack surface management is not asset discovery, it's what you do with that. And it's enabling these core processes with real time asset awareness and building that into these core processes. That's the key value point. And you can't do that if the core processes — exposure monitoring, threat intelligence, incident response, all those things that you want to do — you can't do that if they're not built with that asset awareness in mind. It's just really a subpar experience. And so that's the approach that we've taken. And it has been interesting to see that development. But again, the quality of that is across the board, right? So when we take a concept like that — when we talk about asset discovery and exposure monitoring and the various forms of exposure monitoring that can take — it's so deeply intertwined. When we think about it from an engineering perspective, a product perspective, just our philosophy, they're not just standalone things. One feeds into the other and vice versa. But what I'm also seeing — just to your point — it's not just end users that are like, oh, yeah, maybe I can just run this off the shelf stuff very easily. It's companies, right? Often they're pen test companies or companies of that sort of nature that are more services based, that are trying to build something that's I guess a bit more of a product. And they're doing that, right? Like they're taking like some really basic asset discovery and they're just providing scanning with these open source tools. I saw one the other day — and they don't even hide it. Like most people try to hide it. Like when we find out about it, it's kind of like, oh yeah, like behind the scenes it's just X tool, right? But these guys were like, no — it's based on their pricing. So on your cheapest tier, you get OpenBAS, and on your more expensive tier, you get Nuclei. It's like, why would you pay for that? Right? I don't understand the value that you're actually getting on top of that, especially given that the output of both of those tools is not great when you start to do things like scale it up, right? Like, when you know, if you've got an asset and there's a couple of false positives, right? On its own, that's not a huge issue to deal with, right? You can just sort of weed them out and ignore them. But what happens when you've got 1,000 assets or 5,000 assets, 10,000 assets, and there's a few false positives on all of them? That's like thousands of results that are just irrelevant. Right. And so what, do you want to weed through all of that? Right. And then, you know, it takes you forever to run those tools against 10,000 assets. Is it really that good of an experience? And it's just surprising that people would pay for that, right? Because there's not really much that they're offering on top of that. It just shocked me.

Shubs: You know, I still think some of my favorite feedback when it comes to what we've built is that when we raise something, they know that it's important. So they're going to actually look at it and they're actually going to spend the time on it, compared to other tools which are raising thousands of things. And look, you're not wrong. Like a lot of these tools do have thousands and thousands of things they check and look for and raise and things like that. But I do think that they take this approach where they kind of ask you to filter things out in terms of, oh, only scan for these things, only filter these things out or wherever it may be. And I think one of the big things — just to go back a little bit on the build vs. buy and a lot of these competitors that we're seeing that are trying to glue together these open source tools and whatever it may be — is, I'm actually not sure if they've dealt with some of the issues we have yet, or if they have, they're going to have potentially some customers that do experience a lot of difficulty — all the safety side of things that we've had to build. And I know we've got some real war stories there when it comes to that sort of stuff. And we've done a lot of work in terms of building that into everything we do from the scanning perspective, from everything else. Like for example, let's just say you've got these open source tools and you've got some asset discovery or whatever it may be. It discovers a thousand new subdomains today and all of them are pointing to the same place or whatever. And then you just pipe it to your scanning and slam everything that's in those thousand assets — suddenly you've got some sort of outage happening on your internal network or whatever it may be. And I really don't think these are well thought out in our competitors' products. And that's something that I've honestly noticed — these safety elements that are really important to large enterprises, or any enterprise really — they're things that we've had to work out and systematically build in our platform. We have multiple different mechanisms of this that we've had to build in the last six years. But I don't know if you agree with that — I just generally feel that a lot of these competitors don't really understand these things and they may not understand them until it's too late, to be honest.

MG: Yeah. I mean, it is kind of interesting when you look at the landscape and the kind of care and attention that we put into it. And like to your point earlier where you're speaking about the feedback that we get — where it's very satisfying when they say that, right? They're like, if something comes out of Assetnote, I jump on it, because I know that it's real. Or in many cases, they just pipe it straight to the engineers to fix — the security team doesn't even have to look at it. And like, that sounds really good and really positive. But behind the scenes of that is a ton of work, right? And it's a standard that we're trying to hold ourselves to. So whether it's the signal element or the safety element, there's a lot of work that goes into it. And so it's very validating and very rewarding, because it's the combination of that. But yeah, I mean, to your point — safety is a very important thing, particularly if you're looking at it from an external attack surface perspective. I mean, we recognized that from the start, you know, in terms of, again, the safety systems that we built to sort of handle different kinds of attack surfaces and different kinds of edge cases and different configurations of an attack surface that could potentially lead to disruption if it was scanned at any kind of scale. I mean, these are the oldest systems in our platform, right? These were right from the get go. And I mean, these are the things that sort of shook out in the first sort of few months of building AssetNote. So they're the oldest systems in our platform. But the one area — I mean, you touched on a few things — but I think the one area that also gets overlooked in this kind of conversation that we're having is the design and the approach of the actual checks themselves. Right? You have to think about safety and disruption in that as well. And so, you know, when you look at what we do, it's very curated, right? It's very curated in the sense that this is all built by us. It's using technology that's built by us. All of the checks are built and maintained by us. So we take that very seriously. And so, not only — we've spoken about on other episodes in the past about how we think about exploitability and how we think about the quality of that from a security outcome perspective. But to your point around safety, a lot of it is the design of that and how you approach that from a safe perspective. Whereas a lot of tools that are just aggregating open source submissions, there's not really that standard there. And there's stuff that can slip through. And that can be a real problem if you're just relying on that, because the draw of those tools is, oh, yeah, well, we've got thousands and thousands of submissions, and we've got thousands and thousands of checks. And so this idea that more equals better is not necessarily true, in a practical sense, if you care about these things. And if you are looking at scanning your external attack surface, you have to care about these things. Bug bounty hunters, I'll be honest, I think there's quite a few that are pretty blasé and gung-ho when it comes to scanning these programs' attack surfaces. So they don't care. That's fine. That's on the program. But these companies, they do have to worry about this. This is their production internet-facing attack surface. Things going down can be quite impactful. That can lead to significant loss of business and reduction of business and disruption to operations and things like that. And so it's actually a really critical and important factor, which is why we spend so much time on it and have from the get go. But, you know, when you're just getting something off the shelf, you've got to be a bit careful about that. Because often you're not getting that same kind of quality and rigor, because the people who are contributing to it — they don't care about that. It doesn't matter to them. It matters to us, but it doesn't matter to them.

Shubs: And it's funny because given what's happening right now with CrowdStrike and everything, the fact is that these checks that are built in a lot of these open source tools, especially by the community, can definitely lead to problems. Maybe not a blue screen of death, but definitely problems in terms of their attack surface. There's a lot of techniques that are coming out as well these days that focus on things like cache poisoning and other things like that. And I've definitely seen where this can go wrong, where you actually just completely disable access to a website for a long period of time. So these are things that are definitely happening.

MG: It's tricky to get right. It's worthwhile doing it, right? But you've got to do it the right way.

Shubs: Yeah, for sure. And I guess, let's just say that you're an organization that's decided to build your own ASM, and you do all of this, right, and you get through all this monstrous effort that you have to do. Then you're still going to have to deal with some of the most weird shit you'll see on the internet ever. Like Mike, like I know we dealt with this and we're going to be speaking about it at B-Sides Canberra later this year — where one day we just discovered that if you have any domains that point to a Chinese hosted name server, then there's some real DNS poisoning happening there. And that just completely messes your results. And look, I'm not saying every organization has a presence in China, but any domain that even has a name server in China — even if it's Cloudflare — it's still completely screwed in this case. So there's all sorts of things like this. And, you know, we've obviously done a lot of engineering around all of this stuff, but this is the sort of experience that we have in this space that we bring into our product compared to others.

MG: Yeah, I mean, but I guess to some extent that's expected, right? Like there is a difference between a vendor product that you pay for versus just, you know, open source tooling that you get off the internet.

Shubs: And I guess there are a lot of vendors that are masquerading — like, yeah, just — that's the interesting part where they are just gluing things together.

MG: So yeah, that's been kind of surprising to me. Because, you know, if you're a company and you're like, okay, well, look, I'm just going to take some open source tooling — maybe they understand all the things that we're saying. It's like, look, it's not going to be as effective, it's not gonna be that great, but like, it's good enough for what I want to get off the ground. And it's cheap, right? That's one thing, right? But if they go in the opposite direction, say, well, hang on, I want somebody else to maintain this, I want somebody else to provide this sort of value that can do a better than me, right? That can do better than just running open source tools. And then they go and pay money for a product. And like, it's just that behind the scenes — it's kind of nuts. What extra are you really getting? And that's kind of disappointing to see. And like, I want to be clear that this is not the totality of the ASM market, right? You know, there are good products out there that do try to approach things from a better perspective than just gluing tools together. And there's other different approaches as well. Some focus very heavily on manual work, which we've obviously are all in on automation as a more scalable and effective solution. But it's not to say that it's everybody but us. But like, it's just so prevalent in ASM — there's so many me-too companies that have just spun up, and they're just a thin veil over a bunch of open source tools. And why would you — there's no value in that. You're honestly wasting your money. And it's just wild to me how prevalent that is. But you know, that's just me, I guess — we obviously build this stuff, and we obviously care very deeply about it. So I guess we're maybe a bit biased there. But yeah, cool. No, I think it's a good discussion. And on the DNS issues — the insecurity through censorship — we are presenting that at BSides Canberra here in Australia in August. So we won't give too much away. It's a pretty interesting issue. But yeah, is it August that we're presenting or is it September?

Shubs: It's the end of September. And I guess just for people who are watching, it's possible to exploit almost over 30 million domains on the internet through some client side attacks. And it's all really possible due to, we believe, some censorship protocols that are in place in China.

MG: Yeah. So, obviously BSides Canberra, if you're in Australia, it's a great conference, check it out. But I'm pretty sure they record things, but maybe it's worthwhile after we do that presentation, we might do another session here and deep dive into it. That'd be maybe pretty interesting. But cool. I think we can wrap it up there and, uh, yeah, chat soon.