The Untold Story of Assetnote: Origins and Evolution - Surfacing Security Ep 3

MG:
Probably a good place to start is a little bit about the background of AssetNote. For better or for worse, not everybody knows a lot of the history of it. It's pretty much our fault in terms of marketing. We're not really marketers, but maybe a good place to start, Shubbs, is the precursor to AssetNote, which was a tool that you wrote for bounties, right?

Shubs: Yeah, wrote it for bounties. You know, initially released it at B-Sides Canberra, but the real genesis of all of it was just, you know, I was tired of getting beaten by competitors in the space, in the bug bounty space for reconnaissance data. I mean, people had access to all sorts of different data that I didn't have access to. And one of the things I realized quite quickly when doing bounties was the earlier that you got notified about new subdomains and new assets, the more likely you were able to find really critical issues. And I mean, this is something that we've kind of proven year over year with what we've done with AssetNote, with finding these ephemeral vulnerabilities and things like that. But initially, that wasn't even the primary use case of AssetNote, of finding exposures and stuff. It was just to discover new assets before other people had them. And that's kind of where the name came from, right? AssetNote, or whatever it is. And yeah, I was getting notifications all the time for new assets. And there was one particular bug bounty program that paid like $8,000 for a subdomain takeover, which is pretty crazy. Even right now, that's considered pretty crazy. So knowing which subdomains they had and if it was pointing to anywhere that you could take it over, eight grand at the time, which is, this is like, you know, seven, eight years ago. That's kind of unheard of that they were paying so much money for a subdomain takeover. Even today, you barely get bug bounty programs that pay that much for subdomain takeovers. But anyways, yeah, it was, it started off like that. And then eventually there was this whole element of finding, um, you know, vulnerabilities, exposures on these assets as soon as they appear. But I mean, as you know, Mike, like, you know, things have changed a lot. That was a bug bounty version. And that's a completely different ballgame to what we do now selling to enterprises.

MG: Yeah. So, so, you know, I remember like you had this tool, right? Using it for bounties. And it was really good. A lot of the DNA of what AssetNote is today, like you're saying, was baked into that tool. I mean, it's obviously completely separate. But the fact of finding assets quickly and finding issues on them immediately, there's value for you in the bounty context, right? Because that's a competitive nature. You don't get paid for second place. But When you think about it from a company's perspective, there's also value in not only that visibility and being able to understand what assets you've got, but also the speed, just given how quickly modern attack surfaces operate. So yeah, you had that. And then if I remember, there were a bunch of bounties that are just rinsing with this tool. And then a bunch of them came in and said, hey, how do you keep doing this? And we explained the approach, all that kind of stuff. And then, you know, a whole bunch of them basically said, if you were selling this, we'd probably buy it. And that's really kind of where things started to pick up from a corporate or enterprise AssetNote perspective, right?

Shubs: Yeah, yeah, I guess. And, you know, like, it's funny, because I, you know, when I built AssetNote initially, and thought that it could potentially be a business because of these disinterest from these companies, You know, it was, it was really tough, like building a business out of some random tool that you've created. And as, as you know, like as a developer, you only really have like a quarter of the story when it comes to the actual business. Like the technical side is not a successful business necessarily. Um, and that's, that's kind of where you came in. Um, and, and that's kind of what we built together. But, but back then I can remember, um, when I had this software and there was interest from companies, like I would tell people that I'm really interested in making this a business. And, um, you know, I'd have my parents be like, you know, what are you doing? Why don't you go work at Microsoft or something and have a stable job, you know, wake up, you know, fine in the morning, have your wife and kids and things like that. Why do you want to build a business? And actually there was a lot of uncertainty and doubt at that time. Not just from myself, like I had to believe that something would work eventually, but really from everyone else. And, um, you know, from my parents, from other people, they didn't really understand what I was building at the time. Um, they didn't really have much idea of whether or not it would even be something that you could sell, um, or there was actually a market for it. And, you know, as we found out together, like we were literally the first company to build an attack surface management platform before it was even called attack surface management at the end of the day. So, um, it's, it's really funny. Like those same people now, um, they're like, wow, you've done such a good job. You know, I knew it was always going to succeed kind of things like, well, they never had any doubt. You know what I mean? So it is funny because I do remember like, uh, early on, like just really not doing well from a business perspective in any way or form and making this a business, I guess, um, from just the software until you came on board.

MG: Yeah. I mean, it's an interesting, I remember the time that we were having all those sort of discussions, right. You know you'd had this sort of interest in thinking about like asset note. And there was that, there was that moment, right. I think you described to me with the Slack bug, which we can talk about. We presented it years ago when we're talking about ephemeral vulnerabilities, but that was really like a light bulb moment of, Hey, this might actually be useful for companies. Right.

Shubs: Yeah, that was a great bug. And I guess for the people watching that may not know this, we did present about this. What conference was that at, Mike?

MG: It was a 44Con in the UK. Yeah, exactly. We presented about this, but essentially we had

Shubs: We had discovered a number of subdomains under a Slack development domain that just kind of came online overnight. And because we had the exposure scanning going on at the same time, we discovered a number of Git repos. Pulling them down, it had all of Slack's source code, including literally every hard-coded secret. And I guess for a lot of the people watching that may not know, Slack is like pretty much entirely written in PHP, or at least was back then. I don't know if that's still the case, but this was like the core app source code for Slack and had every secret. Now, something that was also really interesting is, you know, the secrets, after a year, some of them still work. So, I was able to report it again and be like, hey, you got to fix this. Well, there's so many, right?

MG: Just the process of going through and rotating all of that must have been annoying.

Shubs: Look, after like six years of doing Asanote, I do not envy anyone having to rotate secrets at that scale. That would be a very difficult thing to do without any downtime, without any problems. But yeah, it was a really cool bug. You know, I think, you know, I think Mike, you had a quote from the Slack CISO at the time.

MG: At the time, the, you know, the Slack CISO said that that was like the biggest bug that anybody had found, like that was outside of Slack. Um, and it really did prove, prove the point, right. That was one, it was a bit of a turning point in terms of understanding how useful this is because it was all the elements coming together, right. It was, uh, you know, a bunch of, you know, staging boxes that were being spun up every now and again. Right. So they weren't just like permanently spun up and, you know, as they were doing it, um, you know, it would be exposing this Git repo just on the web route on these on these assets. And so there was the discovery side, there was the security scanning side, but also the fact that it was continuous and quick, because like these were short lived, right, but they were very impactful. And, and so, you know, the initial reaction is, oh, you know, somebody's spun it up, and now it's fixed, right, but then it kept coming up again. And so, you know, then, you know, you can dive deeper into the root cause and realize, you know, they realized that it was, you know, something to do with the automation that they were doing when they were deploying staging boxes and things like that. It was a mistake. And, you know, if you think about, you know, modern attack surfaces, which, you know, Slack is, they are that dynamic and they do have a lot of these automated processes. And I think that was really the thing that solidified it, which is, yeah, the kind of end-to-end concept works, right? So obviously there's a bunch of details in there, but overall the end-to-end concept works. And I think that's sort of solidified it. Plus it got us thinking about pretty unique sort of bug class, I guess, or type of issue of bugs called ephemeral vulnerabilities, which was what that research was based on. But You know, I remember, you know, going back to sort of starting Asana, right, you know, prior to prior to us sort of officially launching the company, you were in Poland, right, working on this for a few months, and then you had plans to go to Thailand, I think, you know, for a while and, and, but in between, you stopped over in Brisbane. And we're having a lot of conversations about it. And I remember You know, I thought it was really interesting and, you know, the Slack thing definitely kind of solidified it. And so, you know, there's a lot of discussions, but the kicker for me was the fact that, you know, I have, you know, at the time I had two kids, right? Got a third now, you know, the idea of, of you going to Thailand for a while. It just wasn't going to work. So I pretty much put that to point blank. And then a couple of days later, you messaged me and said, yeah, I'm not going to go to Thailand anymore. I want to work on Asset Note. And I think I just texted like, I'm in, you know, basically, let's, let's do this. And then just kind of started from there, you know, essentially. And then, and then we got together and we're like, okay, well, what does an enterprise version of this look like? There was a lot of the core concepts that are still core concepts to this day that, like you mentioned, like there was nobody else doing this, but there's now a lot of people doing this. and a lot of these concepts that were just hashed out back then in your open source tool are now propagated through the market, which is crazy to see. But I remember we were at your apartment in Brisbane trying to hash out, okay, what does this look like? It was really a start from scratch kind of thing from a technical perspective. And I remember we're writing in notebooks, we were writing on whiteboard markers all over your windows at your apartment and figuring it out. And after all of that, we kind of hashed out like a sense of what we thought like a sort of initial saleable product would be. And I asked you, I said, you know, should we, should we maybe like hit up some VCs and, and hire a dev or something like that? And you're like, no, no, no, we could, we could do this in like six weeks tops or something like that. And you wrote down like a, a date in your notebook. I remember, I think we still got the photo of it. Um, and, uh, yeah, we definitely, it definitely wasn't that, but, um, that's sort of, that was sort of the beginning. Right.

Shubs: But, but, but dude, you, you do need to be strong willed to be a bootstrap. And sometimes that does mean like believing, um, believing that you can get something done, even though, you know, it might take a bit longer because you don't, you don't want to, like, sometimes you want to be able to have that faith that, okay, we're going to build this. We're going to do it ourselves. We're not going to have that VC funding, but we're going to be able to do it ourselves. And, you know, admittedly, both you and I ended up, you know, struggling quite a bit, um, to fund asset node in the beginning. I know that, you know, obviously you have kids and you had a pretty decent salary at your previous job. Going from that to literally earning zero overnight is a pretty big deal. So I understand all of that, but, you know, it's, it's, it's really funny because I also remember, you know, the open source version is the open source version and those several iterations that were private and whatever else. But when we were building Asinote as a product, officially, there was a lot of things that I had never considered as a developer. And like, I'll be frank with you. I'm not, I was never a engineer. Like I never studied and finished computer science. I never became an engineer. I was a hacker first that learned how to do engineering because I needed to do engineering to, to, to, to achieve what I wanted to achieve. And, um, what I learned working with you in the first year was basically like designing a product is not just writing code. It's mapping out literally every user interaction. It's understanding every way that the product might be used. It's understanding the needs of these customers. Sometimes anticipating things that you may not even know until you sell it into a company, but you've anticipated them. So you've designed it that way. And, you know, I mean, for me, that was a big eye opener because everything I'd worked on until that point was purely from a hacker perspective. What's useful to me as a bug bounty hunter. But when we built the enterprise product, the initial version, which, you know, I think general availability was 2018, I would say late 2018. Yeah.

MG: So, I mean, we started in 2018 and then we started getting this into customers hands. So late 2018, and then we had our first customer, you know, just in the new year and in 2019. Yeah. Yeah.

Shubs: Yeah, and I'm pretty sure that everything we had written after I'd started working with you was pretty much all written from scratch. I don't think we took any parts.

MG: Yeah, no, it was a complete rewrite and a complete architectural change as well. And it was interesting because, you know, you talk about, you know, you have to be strong-willed. I think the other side of that coin, some people might argue is you have to be naive, which I think is a little bit true. But it centers on the fact that both of us, like you mentioned, came from that hacking background, right? Where you kind of have that, to be successful, you kind of need to have that mentality, right? Where, you know, you just push through those barriers on this sort of naive belief that, yeah, I'll be able to hack this, or I'll be able to do this. And that's what it was. But, you know, when you start to think back in hindsight, you know, a lot of, a lot of what that forced is actually, you know, my opinion, at least like really good, I guess, business advice in a lot of ways for a startup, you know, it was, you know, when you when we're building the focus was, One, you know, like you mentioned, we had to think about this from how do we make this technology, which is interesting, and we get a sense of value from it as the hacker, right? But how do you make this consumable to companies that might pay for this, right? That was a big big difference. We can talk about the technology, we understand the technology, we understand what we need to do, we understand how it works, but then taking that and presenting that in a consumable way was really, I think, the key thing for AssetNote. It's not like the idea in and of itself is like anything kind of that crazy or, or out there. It's just, you know, the execution of that and making, making it such that these companies can realize the same value that we were seeing as bug hunters using it. And so that, you know, there's, there's that side of it. But then also, you know, things like, we have to build this and get this into a paying customers hands. because we've got no money, right? You know, like we can't spend months trying to figure this out. We have to have something that, you know, is the core of that value and then get into customers' hands and then, you know, sell a bit of roadmap, whatever you need to do to get it in there and then continue to build on it because we just, you know, you need revenue at that point. But then, you know, it forces a lot of things like we were straight out, you know, the door, you know, a few months into the business with talking, showing this to customers. But, you know, I think the key difference that we had being a bootstrap company versus what I see out of a lot of VC backed companies is like there was no thinking of Oh, this is, this is market testing. Or this is like us trying to figure out product market fits. Like, no, it was still predicated around a sale. We were still selling this, but we were getting that feedback and we're iterating very quickly. And we were putting it in front of users. Um, and, but that feedback was not just around the, you know, what their impressions were of the, of the, uh, product, but also, um, But also from a sale perspective, you know, pricing, like, would they buy it? You know, what are the challenges for implementing this inside their organization and things like that. And that was a very short feedback loop that we're iterating on very quickly. And, you know, it culminated when we got our first customer. a large tech company in early 2019. I think that was really it. And going to the point of being strong-willed slash naive, really what our focus was at that time was just all on building this and selling it to a customer. And then once we got that, that was the first turning point. Then it was like, okay, well, all we need to do is do this more, right? Get into more customers. And, and we did that. And then, you know, kind of just, you know, it goes from there, but, but yeah, I mean, that was really like the early days. It was kind of a crazy time. You know, one of the interesting things as well, just around the point of like funding, this is obviously, you know, We are working, you know, ourselves in the business and whatever, you know, going from, you know, earning a lot of money, whether it was through bounties or through my previous job to having nothing, right? But I remember in the early days, you know, some of our infrastructure choices were based purely on where we, where we had credits. Um, so I think we were with GCP first because, uh, cause you had some credits on there. It was like a few grand of credits. Right. Um, but we had heaps of problems with GCP, uh, in the early days. You want to talk about that for a little bit?

Shubs: Yeah. Yeah. I mean, you know, just quickly to note that naiveness needs to be paired with at least some level of positivity if you're going to make it anywhere through, but I won't disagree with you. There was a lot of naiveness with, with my initial technical background choices and, you know, execution initially, but, um, you know, it worked at the end, but it was, it was right. Like you need it. Yeah. You need it to some extent. Um, I would definitely do things a lot different, uh, these days after six years of doing this from a technical side, but I think there's a lot of things anyone would do different in that position. But anyways, the, the GCP story. Yeah. Anywhere that had credits, I think GCP had the startup thing where they gave us like three grand or something like that. You know, I was generally really keen on GCP because they have this Kubernetes layout that you can pretty much use for free. It's like a managed Kubernetes cluster, GKE, which doesn't cost anything extra, really, compared to AWS, which does cost extra. But yeah, I mean, the nature of our business is that we are going to be port scanning. We're going to be sending requests out to the internet. We're going to most likely be receiving some level of abuse requests over time due to all sorts of different reasons. And, you know, GCP just didn't treat us well in that respect.

MG: Yeah, it was really interesting. This was before we had our first customer. And, you know, as you're building the product, right, I think the key turning point was when we did start implementing port scanning, which was something that we did obviously early on. And, and, you know, it started flagging, particularly for, for SMB, I think it was around the same time. Was it WannaCry?

Shubs: That was… Yeah, it would have been around a similar time.

MG: And so like everybody was concerned about that, I guess. And so, of course, with all these abuse requests, like the nature of… the nature of the stuff coming from GCP was just, Hey, it looks like you're compromised. You know, you should probably, you know, and, and the, you know, attackers may be launching attacks using your infrastructure. You should, you know, check that out and like fix it. Um, and we're like, no, this, this is us, this, this is our thing. And we, we went back and forth, but the way that GCP did, it was really kind of tricky from a business perspective because they basically said, Hey, um, you need to rectify this or in 24 hours we're going to we're going to suspend your account. And so we went through that back and forth with GCP explained it and they're like yeah that's great you know security company all good. So we're like hey can so can you make a note on our account or something like that to so we can we can not deal with this. And they're like, no, no, you just need to respond to this automated message, you know, within 24 hours. Um, and so that was what we were doing for a while. And I remember, you know, we were speaking about it where this is a real problem because, you know, we were doing a lot of travel at the time. This was pre COVID. So, so we're doing like, you know, presentations and different events and things like that. And we're like, what if we're on a plane and we can't respond to this or, or for whatever reason, we just, you know, didn't see it. that could be a real issue. And that came to a head at the end of 2018, early 2019, where you were, it was over the Christmas, New Year's period. I was like on the Gold Coast with my family. I think you were at CCC in Germany. And then without this sort of warning email, they just suspended our accounts. And we were like a few weeks away or about a month away from, you know, signing our first customer. at that point. So we were just like, what are we going to do? This is crazy. So we started looking around. But of course, because we're bootstrapped, we basically went and tried to fish for credits for different providers. And obviously, we looked at AWS. And, you know, they had, you know, different tiers. They're like, Hey, we're, we're, you know, you get a couple of grand credits all the way up to a hundred thousand. And I remember you called them and, and they were like, yeah, we can give you a few grand. You're like, no, no, no. I want a hundred grand. I want, I want the big one.

Shubs: Actually, it was a friend of mine that knew someone at AWS.

MG: Well, before that though, right. Yeah. Right. They were like, no, because you're not a VC backed. That's correct. And they they kind of outsource that, you know, underwriting to to the VCs. But I mean, and this is sort of the kind of the point of like talking about being naive and just pushing it by we didn't stop there, right? Like, you know, we weren't going to just say, Yeah, sure, I guess, right? You as a bootstrap company, you kind of got to figure it out. And you knew you knew somebody that had connections in an AWS, right?

Shubs: Yeah, fortunately. And he put me in touch with, I think, I think he was an engineer at AWS that was aware of this program. And then we just got into his email chain with this lady that was managing the program in Australia. And I remember, you know, you and I got on a call with her. And I think you were explaining to her all the prospects we had.

MG: And yeah, basically, she was sort of explaining that this is for VC backed companies and whatever. And I just kind of, you know, spun it. I said, like, you know, look, you know, these are, you know, we're with GCP now, we're having these problems, we're kind of, we're in the early stages, but we want to, you know, really dedicate to a cloud platform, you know, like all that kind of nonsense. But then yeah, I went through like all the demos that we were doing, and all the customers that we're speaking to. And of course, you know, that there's just a litany of huge brands, right? And, you know, as soon as I name dropped that, and that wasn't like exaggeration. That was the truth. We actually, you know, at the time, you know, many of them are customers now, but we were doing all these demos with these huge brands and these huge security teams. And, um, and that really helped because I think she was like, okay, there's something here, whatever. Um, and then two days later, we, we got the email, um, to, to say, yeah, that that approved us for the a hundred K credits. Um, and then we got into the mode of. basically porting everything and re-architecting things for AWS in like one, two months before we sold our first deal. And the interesting thing is at the end of the day, AWS have very much got their return on investment. I mean, our run rate is seven figures a year. for AWS. So, they've made their 100 grand back. But in the early days, I mean, we made that 100 grand last. I think we got like 10, 11 months out of it.

Shubs: Yeah. And just to note, they expire in a year. So, they do kind of make you use that if you want to keep it and use it, you've got to use it within a year.

MG: We got it basically almost perfect, right?

Shubs: Almost perfect.

MG: But that also instilled a sense of just, like, leanness as well, right? That's true.

Shubs: I mean, I am really grateful, though, that we did make really good architectural choices early on, thanks to some of the early engineers at AssetNote and just thinking about this a bit more deeply, where, you know, like, all of our infrastructure is as code. Like, we don't just randomly deploy things anywhere. I think given the nature of our business and what we do, we did, even though we were very naive at the time, I think we made some really good choices. Some good choices we made, we ditched having the engine run in Python to Golang. You know what's really funny? I didn't even know how to write Golang when I made that decision. I was learning a whole new language when making that decision, which is pretty crazy, to be honest. Then infrastructure as code, Kubernetes, all that sort of stuff. And we're still using the same fundamentals today. And Postgres, for example, like, you know, a lot of I feel like a lot of people who are getting into engineering, they'll often think, oh, you know, let me just swap out this technology, we'll make everything better, or whatever it may be. And, you know, we haven't really done that that much in the large in the grand scheme of things. And we've kind of just figured it out. We're like, okay, like, there's a problem here, we're gonna have to just work through it.

MG: And I know Mike, you and I were talking about that. Yeah, I think there's something to be said about picking something and sticking with it. And because the reality is that you know, every technology has its drawbacks. Like if you, if you're focusing on one, one or two benefits, that's great. You might, you might realize those benefits, but there's, there's a lot of costs as well. And it's, there's no like one, I mean, it's like security, like there's no one silver bullet technology that you can choose. And so, so you have to kind of be prepared to, um, kind of make your choice and run with it to a certain extent. Obviously, like if it's really bad, you should change it up. But, you know, I think other than on the front end where we moved from Angular to React, you know, our technology stack is basically, you know, stayed the same in terms of the languages and frameworks and sort of, you know, databases and things like that that we've used. And yeah, I mean, you run into challenges, right? You run into challenges with scale or speed or some level of optimization or whatever. And you think, oh, this new shiny thing over here, it's solving this one thing that I'm thinking about right now. But it, you know, comes with a whole host of other baggage. And so, you're better off just like working through the problem in most cases. That's just what we've done. Again, I don't know. It's interesting talking about the history of Asinote because a lot of it doesn't feel like we were that conscious of some of these sorts of things. We were just figuring it out and doing it. I think talking to other founders and other teams and whatever, there can be a bit of a tendency in in the startup world to really overthink things a little bit, you know? And I think that was one of the things that we didn't really suffer from in the early days. And I think that, you know, maybe that's bootstrapping, right? Like it causes you to focus on what really matters at the end of the day for a business, which is, you know, generating revenue and keeping your costs low, basically. And so we did that, and the strategy has been very simple. Year one was sell a bunch of customers. Year two, sell more customers, but keep the ones that we've already sold. And then year three and beyond was just do more of that, basically. And so it was very simple. But, uh, you know, so moving into, into maybe a bit more about kind of the product and, and, and sort of how we started defining that. Um, it was kind of interesting in the early days, like you mentioned earlier that, um, you know, at the time, you know, we hadn't really come up with the term ASM yet. Um, there was nobody else really doing kind of what we were doing, which was really melding, you know, asset discovery. Um, with that sort of high signal security analysis and really understanding like the exposure in real time in an attack surface that kind of continues monitoring. So a lot of the early discussions that were out there, it wasn't very marketing centric where it's like, hey, here's what ASM is and here's all the benefits and here's why you should adopt ASM and whatever. There was a lot of, so like, where do you fit? Where do you compare against all these different different, not just not just products, but like, categories of products. And the interesting thing for our product is that we we kind of covered a lot of different areas, right? You know, there was the asset discovering, there were a bunch of asset discovery tools. But we also did, you know, deep security analysis. So obviously, a bunch of tools that do security analysis in different contexts, but you know, they didn't have the asset awareness. You know, then there were others that had both, but they didn't really focus on the end user, you know, they're looking at third parties or they're very simplistic. And so we kind of, you know, really found, you know, a kind of a unique area to sit. And, and, but we were figuring it out as we as we sold it, right, in terms of, you know, that messaging, and then it culminated in, in you know, eventually coming up with the term, you know, tax surface management to kind of encapsulate the fact that this felt different, I think, to other stuff or, you know, different from an approach perspective, I think, more so than, you know, just trying to arbitrarily differentiate a product. It did feel like a different way of looking at the problem and solving the problem of managing exposure. And so, yeah, we kind of went from there and it's kind of evolved. The ASM market's kind of a bit crazy. Everybody and their dog claims to do ASM. I see a lot of pen test companies that say they do ASM now. I remember when I started, because I'm much older than you, right? Started sort of like in the mid 2000s. Every security testing company had like an engagement. It was like a one, two week engagement to fingerprint. That's what they would call it. It's like fingerprinting, you know, your, your attack surface or your assets, you know. And now, nowadays, every pen test company calls that attack surface management. And, and it's just the same consulting engagement that they've been doing for like almost 20 odd years. And so, so there's a lot of that kind of confusion in that term. But, you know, it is what it is. And, you know, you kind of just roll with the punches a little bit. But, you know, maybe, you know, maybe another thing to talk about is sort of the thinking that goes into the product, right? And kind of the, you know, on that sort of topic is like, how we think about this sort of stuff and how we think about ASM and the product. I mean, it's, it's, it's really, like I said earlier, right. There was a lot of the DNA from, from the original Asano tool. So, so a lot to do with speed and scale and signal, I think, you know, just underpin all of it. Right. Um, and, and I think, you know,

Shubs: I think we're probably one of the only vendors that does it at the speed and scale that we do it at. And actually, I feel that, you know, after assessing pretty much every other solution out there and what they're capable of, they can't do what we do.

MG: Yeah, I mean, we do everything hourly, right? And it's been that way from the start. You know, there's been a bit of a trend over time where they're trying to speed things up. often at more expense to the customer and their recent sort of developments. It's like, we've been doing that since 2018. Right.

Shubs: And you take a look architecturally at some of these companies and you look at some of them open source as well. You look at the code and you're like, there's no way you could handle an attack surface of the scales that we handle it at, at the cadence that we handle it at. And, you know, like, often I get really frustrated, because, you know, I think there might be a tiny perception somewhere where people think that we've just glued things together and built a platform or whatever. But that's, that's not the case. Like, we've actually built everything carefully, and very meticulously for the use cases that we wanted for our customers.

MG: And that's completely different to gluing together a bunch of things. We didn't evaluate that stuff, right?

Shubs: Like, we always looked at it. We always looked at it. But to be frank, a lot of this stuff didn't even exist when we built a lot of our stuff. Like, there was nothing out there that did. And you know, it's funny because you'll talk to attack surface management vendors these days. And they'll be like, oh, you know, like, We just use so-and-so and we do this and this. It's kind of like what people think in ASM is just things glued together, but we're not that. We're completely different to that. Almost everything we've built is due to the engineering work of our engineers, myself, and things that we've logically thought through from the perspective of being a attack surface management vendor and discovering things as quickly as possible and finding exposures as quickly as possible. And, you know, frankly, we find a lot of exposures that are completely unique to us as well. Like no other open source tool looks for them because they just don't have that capability and they have never built it. They don't understand it. Like, so it's.

MG: I mean, there's, there's reason for it as well. Like, it's not just, it's not just like, Oh, it's not glued together and we engineered it. It wasn't engineering for engineering sake. Yeah. It was still outcome driven. The outcomes of that kind of glue everything together approach just didn't work, particularly at the time, but even still to this day. So, a lot of it would be, you guys are great with recon and asset discovery. So, why are you building out this exposure monitoring engine? Why don't you just pass it to this open source framework or just white label like a commercial vulnerability assessment offering and things like that. The outcome was terrible. First of all, the asset discovery needed to be done you know, our way, you know, and we have a very different approach to doing that, that I think has a lot of benefits. But, but, you know, from an exposure monitoring perspective, you know, we wanted to hit that hourly cadence, right? That's real time, basically, is, is the goal that we wanted to go to, because we knew that that had value. That's where we were coming from, from a bounty perspective. But we knew that that had value from an enterprise customer perspective, because, you know, they're able to become more reactive, more proactive as well in how they manage exposure in their attack surface and what they see. And whether it was open source or commercial, the vulnerability scanners just weren't built for that. They were IP-centric. which is not a modern way of thinking about attack surfaces. Like with cloud, IPs are basically disposable things in most organizations now. They're not this sort of key pillar of a modern attack surface as it used to be. And they're so false positive heavy. They look for CVE matching is a technique that they'll use to like a patch level or they'll do like really basic stuff. And when you're thinking about scale, you know, like if you're just doing like one app or one asset, and there's a few false positives, right, in that output, it's like, that's okay, right? Like, you can just, yeah, these aren't real, you cross them off, you ignore them, whatever. But if you're doing it across thousands and thousands of assets, suddenly that noise becomes a real big problem. And so, you know, those were the things that we were finding. Like, you know, we did explore these options. It just wasn't good enough. It just didn't match our vision. So we just had, we went to build it, you know, and with that, you know, we've built, our scanning capability is kind of insane when, you know, when I look at it, right? Just the scale, and the speed and then the high signal output, which is a little bit to do with the engineering, but a lot to do with the security research as well. You know, it just blows me away. And it's just head and shoulders above anything that I've seen on the market when it comes to doing this kind of work at scale. And yeah, I mean, this kind of, again, a little bit of you know, that that's the the crowd thinking, right? Or the, the herd mentality is like, why, why would you build it? Right? Why would you build it as opposed to use something that's already built. But you know, we had something that we were really pushing for and driving for. And we really had that idea and that vision, that we wanted it to have be of a certain standard and be of a certain quality and achieve the outcomes for for customers. And, and that's why we had to do it, basically.

Shubs: Another big reason is scale. To be completely honest, you take any of these solutions out of the box and you try and do it at the scale that we're trying to do it, and it will all fall apart. You'll either have complete inconsistency in the time that these scans take, or no real optimizations that have been made in a very conscious sense to get it to that scale that we need it to be. And I mean, we've obviously had to work really hard to get there. It's not been easy to shave off those milliseconds off each of our scans, you know what I mean? So there is a lot of work that's been put in to get to that point. But that is a really big reason why we have to do things the way that we do them. it's not just kind of like a vanity reason. Oh, look, we're so clever, we can build our own code or whatever. It's like, no, like, we are servicing really large enterprise clients, they have an expectation. And we provide that service that we're going to be scanning them on such a frequent basis to discover things like ephemeral security vulnerabilities, which we obviously spoke about at 44 con and wherever else. But yeah, that's kind of the vision. That's kind of where we wanted to take it. That wasn't just some random thing we decided to do. That was a very conscious decision that I think you and I both spoke about in detail. How are we going to build this out as a product and what are we offering to our customers? And it's still a key differentiation now in the market.

MG: I mean, nobody does it out. Yeah. And we've enabled that. And another key part of this as well is the security research side. And it kind of underpins a lot of that, obviously, from the point of view, not just even on the exposure side, where we've got, whether it's novel zero days, whether it's bugs that are known, new techniques that come out, But even on the asset discovery side, like that kind of hacker-based or more offensive-minded view to discovery and reconnaissance, I think is also very, very important to us. But it is an interesting point when it comes to this idea of automation, because you need to have a certain level of thinking to achieve that speed and scale as well as the signal. I was chatting to some other folks, a company that was looking into this space and was you're talking with various vendors. And basically, you know, they were saying, you know, oh, the only way to get high signal sort of security exposure results is really with manual analysis, right? With manual review of like basic scan output, like that sort of first stage, and then it's manual refinement. And obviously, the challenges with that is that it doesn't scale. It's difficult to scale. It's difficult to achieve consistency. And it's just more costly to scale that out. And we've never had that. I mean, and I just responded to them. It's like, no, it's entirely possible to do this in an automated way. In fact, an automated way is the right way to go because you can unlock scale and speed and all these things that create real value from a customer perspective. You just have to be smart about it, right? You have to really understand the problem space. And I think that's really coming from our background and even much of the team's background in offensive security, I think really just underpins everything that we do there. And so it's not just the engineering side of of, you know, the scale and speed and all the things that we spoke about. It's really the thinking and that sort of offensive mindset and that security research that I think, you know, is on a different level, you know, particularly with you. I mean, like, you're known for it, right? But, you know, the whole team, you know, has really gotten on board with that thinking. And I think, you know, that's a really important part, right?

Shubs: Yeah, I agree with you. I mean, You know, it's funny you mention all of that, because I think one of the things we did do right with all of our engineering and whatever else and security research is we did focus on that automation piece. We did focus on making everything that we do self-service to customers and having that high signal in that automation piece. You know, I'm aware of some companies in our space that, you know, they have like a team of hackers that just, you know, are mobilized for every prospective customer or whatever else. Like we don't do that. Like we just like the platform literally does the work and they see the output and that's how it works.

MG: Yeah, but there's a reason. There's a reason why. And we've had, you know, we've had customers that come from there and there's some surprising sort of feedback, right? Is that, um, it's still more false positive heavy, right? They're surprised by that because it's supposed to be a human looking at this, right? And, you know, they miss a lot of stuff, right? Again, why? Because a human's looking at it. It's because it's hard to actually implement that at any kind of scale that matters for ASM, right? Because, you know, One, it's more costly to scale out humans, right? And so you then have to think about different regions, cost arbitrage and things like that to make that work. But then now you've got a management overhead where you've got typically the company headquartered someplace and then the team of hackers that are doing this evaluation now located in another country. So that creates inefficiencies there as well. And then you run into problems where they can't, especially if you are reasonably successful about selling this, they can't really see everything, right? They can't really get a sense of all the things that could possibly be going on because you'd need so many people. And then how do they try and solve it? automation, right? Like more automation for these guys. And at the end of the day, it's like, that's the that's where you should have started, right? And if you build it, right, and you build it, with a good understanding of the problem space, and a good understanding the value, you can go a long way, like you can do a lot with a single HTTP request, if you're a smart hacker, basically, right? And you really understand what you're doing. And so, um, you know, and this is not even getting into, you know, AI or machine learning or any of that kind of stuff. It's just smart hacking, right? Creative thinking when it comes to, you know, applying that offensive mindset to this problem and Yeah, I think it's the right way to go. That was another discussion early on. It's like the kind of automated approach versus the manual approach. What's the right approach? And we've firmly sat in the camp of automation and it's worked out well and I think it's the right move. I think it's where the value is for sure. So, yeah, so I think, you know, that's a little bit about the history, right? So, you know, where are we at now? Obviously, we've grown a lot. We're still bootstrapped. So, we still haven't taken any funding. I do get emails from VCs, you know, every day, basically, hitting up, hitting up asset node. But, but yeah, we haven't, we haven't done that. We've obviously got a large, larger team, larger customer base, we've realized a lot of the ideas. And, and, you know, we're continuing to grow. You know, I think if we think about where the product has evolved, you It's really a lot broader now, right? In the sense that when we were thinking about this initially, the core idea was taking the asset discovery and the attack surface mapping, that sort of visibility, and providing a layer of exposure analysis that was very tightly integrated into that. It was the asset awareness was feeding into that. The output of the exposure analysis was feeding back into the asset discovery. and having those use cases and those outcomes, you know, built from, you know, that base of, you know, foundational base of assets awareness, rather than being tacked on, which we kind of spoke a little bit about. And so, like, that was the core. And where we started was obviously in the offensive side, right? Looking for vulnerabilities, looking for things like that, because that was sort of, you know, our initial background and what we were best at. But it's expanded a lot now. And I think when I think about where AssetNote was and where it is now, you know, there's a lot more capability, but really a lot of the core is the same, right? It's about providing visibility into the exposure and your attack surface in a real-time consumable way. And so it's now expanded into other areas, right? You know, looking at you know, third parties looking at indicators of compromise, bringing in threat intelligence into it, you know, adding, you know, even more enrichment to the assets, you know, across the board, you know, API discovery, all kinds of things that we do, you know, that's sort of very deep now, but it's in this sort of unified kind of platform. And I think, you know, it's always been about, you know, bringing those different elements together. So it's kind of evolved but not really, right? Like it's still there's that foundational conceptual base that I think is the same, even as you explore new areas of the attack surface, right?

Shubs: Yeah. And I guess, I guess another thing that I'm really proud of that we've done very successfully over the last five, six years is, you know, we've built one of the world's leading security research teams that contributes to, you know, um, the community at large does pretty much world-class research. And we probably have one of the cleanest disclosure models there are in the security industry for something like this. You know, it's quite surprising. When we built our security research team, I would argue that we were one of the first that were focusing on web application security. As a security research team, obviously you've seen many security research firms that focus on iOS exploitation and so forth and whatever else and sell to the highest bidder in that sense. But for us, our model has been really, really cool where we are doing our research in a way that feeds right back into our product and provides so much value to our customers directly. And then not only that, we give back to the community, we write about what we've done. And we write about it in a very careful but deliberate way to teach people what we're not just capable of, but what they can do as well with the information that we have and what we can provide to the community. So it has been very interesting, like, you know, our security research team, I do think, work extremely hard, but we also produce some of the best results for the size that we have for that security research team, I think, on the grand scheme of things.

MG: I mean, like how quickly they can they can sort of tear apart, like really sophisticated, very difficult kind of enterprise software. I mean, we, that's what we focus on, right? Because that's what all these companies are using. We're not, we're not, you know, doing research into my first FTP server or some home, home NAS or something like that.

Shubs: Nobody cares about it. And you know, we're focusing on very particular bugs. we're focusing on pre authentication, you know, issues that are, you know, high to critical severity, basically. And, and yeah, I mean, like, you know, it's, it's funny, because we kind of built that whole playbook for security research, and how we do that as an attack service management company. And now, now, it's funny to see, you know, other companies trying to trying to replicate that. But yeah, but you know, that they're quite a bit quite a bit, they have quite a bit to go, because we've learned a lot in that process. And we've also learned that, you know, there's no product that we're afraid to look at, to be honest, doesn't matter how big it is, doesn't matter how popular it is. And look, we're not here. We're not we're not here to find issues that aren't going to be valuable to our customers. We're very, very conscious about what we're looking for.

MG: Yeah. I mean, we blog about it. Right. But it's not marketing for us. And I think that's the key, right? It's like all of all of the stuff that people might read about on our blog is coming from the fact that our customers and not just our customers, but many other organizations are relying on this software. It's critical software. Right. But they've got no visibility into it. into the real exposure that's sort of there, right? And so that's what drives the research at the end of the day. That's why we're picking these sorts of targets and going after that. It's because there's value on the other side of it. It's not marketing. That's why we don't choose random You look at our product, our research, it's all big, widely deployed products. It's all pre-auth, RCE, SSRF. It's not like post-auth bugs. It's not software that's barely used. It's not software that's exploitable with a precondition that is never going to exist, right? And so we focus on that real impact. Um, and, and we don't do it for marketing. And I think that's where, you know, referring to, to, to folks that are sort of working through this is like, they're still in the phase of like, this is marketing. Right. Um, and that's, I mean, that's cool, but like, I mean, it's not us, you know, and, and I think it's not that.

Shubs: Yeah. You know, there's also something else to be said, like, um, one of the things that I, I, you know, I'm pretty proud of just for what we've done is, you know, I still participate in live hacking events. I still do a lot of bug bounty work and stuff. But there's so much that you learn in that process and so much you need to stay on top of. It's the techniques. It's the different things that we just randomly come up with. Like, I'll give you a call at like 10 p.m. or something and we'll talk about it for two hours being like, hey, like I noticed that this happened here and this, this, and this, and this is a potential idea that we could do. And then we'll go back and forth and we'll riff out an idea that will end up becoming like an open source tool that will end up getting like 600 stars because everyone had the same problem. And they had no idea what to do in that scenario. But we did. And we only know that from experience, from learnings, from the work that we do together.

MG: And that's really, that's a great like, yeah, another level with this stuff, dude, like I learned so much, because like, just the way that you think about it, it's not like in, it's not individual, but you work, you think in a scale, and a more fundamental level than most other researches that I know. And like, it's great, because I mean, you mentioned open source tools, but like, that all goes into our product, right?

Shubs: Yes, yes. You know, But, but the dude, like a lot of people don't actually understand that some of these techniques are things we work on internally and they might just see our research. It's like, oh yeah, we own this vendor software or whatever. It's like, that's great. But like what we're actually doing internally is a lot more than just the stuff that we blog about, you know? So that's, that's something else that I just, I'm really proud of that we've done for our customers because they see value from this literally every day. Um, and yeah, it is these broader techniques and there are some people in the bounty space that are just exceptional at this. And, you know, I look up to these people, I, you know, I work with these people, I try and talk to them all the time, because I, you know, really, really appreciate the scale that they're thinking at. And that's, that's something that we're also instilling into our security researchers at AssetCode. And it's this, it's this mentality, which I think is completely different to someone who's been a pen tester for a while, or someone that's just, you know, comes from an offensive security background, but doesn't have that background in the wide scale reconnaissance and exploitation of issues.

MG: There's a creative mindset that's really surprising, right? That, you know, given how technical it is, but I mean, we could talk about this stuff for ages. I mean, there's plenty more that we can kind of maybe follow on with and do some more discussions about Asinode, about hacking, about research. I mean, there's so many different things. But yeah, I think we can wrap it up and probably do some follow-on for some other sessions, right? But yeah, we can call it there. Good chat.

Shubs: Yeah, good chat, man. Chat again.

‍