Thank you so much, Zack. And thanks TechCrunch, early stage for hosting me and this event. So let's just dive right into it. What do startups need to know about bug bounties? And how to run them safely? What they even are and differentiate them from vulnerability disclosure programs and penetration testing. But you know, first a little bit about lootah security. You know, as Zack mentioned, we're just about a five year old company. And I launched this company right after launching the very first bug bounty program of the entire United States government. It was called hack the Pentagon. And as the name implies, we invited hackers to hack the Pentagon. Well, that seems impossible. And certainly from a retired hacker like me, it sounded absolutely impossible that we would be able to get the Pentagon to agree to this, not only has it caught on in the last, you know, half decade or more of introducing these programs, to invite hackers to test your security controls. But you know, it's caught on across different governments and different large organizations. Now, you may be wondering, as a startup, whether or not this fits into your security program, and there are ways in which you can safely do so. But there are also a lot of really important security investments that as a startup, you should not overlook, as you're preparing for this. So as we move into the slides, and hopefully there will be a lot of questions, you will be much more enlightened and educated as to the ways in which you can do this safely, appropriately, or at all. So first and foremost, I mentioned a few different terms, it's important here to get these straight. And I've heard seasoned security professionals use these terms interchangeably, and that is inaccurate. So in order to know what we're talking about, what's the difference between vulnerability disclosure as a process versus penetration testing versus bug bounty programs? Well, vulnerability disclosure is the process by which you hear about vulnerability from the outside, you digest to that vulnerability somehow internally in your organization and figure out what to do with it whether to create a patch, how to prioritize that patch, and then what to release to the public. If anything, you know, if they have to take action, that entire end to end process is governed by two international standards, for which I'm the co author and co editor. If you had asked me as a hacker, you know, a decade and a half ago, that I would be writing ISO standards on volm disclosure, I would have I would have probably laughed you out out of the room at that point. But you know, what it comes down to is that organizations do need guidelines in how to handle these issues appropriately. So that's the process of non disclosure. Next, we've got penetration testing, I was a professional hacker for hire aka penetration tester for a number of years in my over 20 year history in cybersecurity, you know it professionally. And what this is, is basically hiring professional hackers under contract they have a specific set of skills that match your problem set and you pay them they're under a nondisclosure agreement NDA, to keep your vulnerability secret for as long as you need them to perhaps forever and you are at your leisure as to whether or not you fix those vulnerabilities. The reason I bring that up as to you know what the timing is, it matters when it comes to differentiating how you respond to these different vulnerability discovery activities or ways to find out about bugs in your software with security implications. And then finally, we've got bug bounties the topic of this presentation. Bug bounties are simply adding a cash reward to the process of vulnerability disclosure. programs. So you may have heard of bug bounty platform companies that will facilitate running these programs for you. You know, I used to be part of one of these bug bounty platform companies myself. And you know, they do help a little bit, but we will get into the limitations of how far these platforms can help you versus what you are still left to handle on your own. So if that makes sense difference between vulnerability disclosure versus bug bounty is that both of them require a working digestive system for bugs, that means people process and technology to enable this process where bug bounties can often accelerate the the rhythm or the speed by which you hear about bugs, because there's a cash reward tied to it. It can also unfortunately, increase your spam, and people trying to do what I call beg bounty, where they're hoping for a payout. And they will send you literally everything, every scanner result they've ever heard of, and the kitchen sink in an attempt to essentially wear you down and get you to pay them out. So how common are these processes? Honestly, even the top organizations and you see here, there's a stat 88% of the Forbes Global 2000 don't even have a front door where they would welcome vulnerability reports from the public. So if you see something, say something 88% of the Forbes Global 2000 do not make that process easy for you. That being said, let's talk about ISO standards. Now. Luckily, I have hot pink hair, or as my friend was saying, it is called Black to the fuchsia is my hair color. Otherwise, I'm pretty sure you'd be asleep during this part of the presentation. But effectively, these two ISO standards are illustrated in these two columns. So you've got ISO 29 147. Remember that is the external reporting interface and what you output to the world if a bug is reported from the outside. And then you've got the digestive system, which is governed by ISO 30111. And what you can see here in color coding is what do bug bounty platforms take care of for you, right, and that's in yellow, they can take care of the front door element, they can take care of the initial triage, but what they can't do is fix the bugs for you, you've got to decide what relative priority those bugs have internal to your organization. And it's not based on cbss score, for example, it is that's a very poor, it's a very poor metric attempt at gauging risk in a very generalized way. And it's not really going to help you prioritize what's most important to you in the context of your business. So that being said, not everybody is is really ready to implement both of these ISO standards. But if you intend to fix vulnerabilities at all, whether you find them yourself, or somebody from the outside reports them to you, you need at least the digestive system. So you need to follow ISO 30111 no matter what, but not everybody is ready for the trouble that can be brought with ISO 29 147 I keep joking that I should have knuckle tattoos have these these ISO standards on here? Because I swear, you know, they've been part of my life for the better part of the last decade and a half. So you're thinking to yourself, I'm just going to invite these friendly hackers, how bad could it be? Well, I don't know about you. But these, if you can see the animation here, even if they're friendly bunnies, gray, white hat, black hat, what name you know, whatever you got a swarm of bunnies is still pretty scary. So in reality, it's a lot closer to this, you can't tell friend from foe, in terms of your incident response of investigating all of these hacking attempts that are suddenly you know, authorized by you when you start a vulnerability disclosure program or bug bounty program. And if you don't have a strong incident response or investigation, capability, and as a startup, you absolutely will not have these capabilities, let's be real, you're going to have a really hard time telling whether this is a nation state actor coming at you, or a friendly helpful hacker who just wants to bug bounty. data privacy is a huge area that honestly, the Department of Justice took on, took upon itself to help try to define some guidelines. And DOJ released these guidelines for how do you scope what's in scope versus what's out of scope for data privacy? When it comes to setting up policies for volm disclosure programs or bug bounty programs? They essentially said you have to think this through you the organization have to think through what you know, what are the requirements for your obligations to protect users, PII, your own employees personally identifiable information? What regulatory requirements do you have for data breach notifications? Well, if you're thinking that as long as you put some sort of legally safe harbor in your own disclosure program or bug bounty scope, that you'll be fine. Well, I've got to tell you that, you know, as a professional penetration tester, you know, certainly we had we were under professional obligation to destroy any data that We encountered during a pen test and we were under NDA with not just the customer, but also with our employer. So we were, you know, we had procedures and it was expected of us to destroy all that data. Not so much with Svetlana over doing the bug bounties, you know, and submitting reports and and whatnot that may contain PII. There's no general requirement, you know, of that person, the bug bounty hunter out there in the world to actually destroy your data. And then one of the most famous cases of data privacy overreach via a bug bounty was the Uber data breach in 2017, for which I testified before Congress about how they use their bug bounty program to pay off extortionists who had actually downloaded 57 million records. And certainly that would have qualified as a data breach, even though they tried to sort of pay off some hush money and have the have the attackers signed an NDA in order to keep this off of the FTC radar and out of the public's purview. So there are many legal requirements, many data privacy requirements that you have to think through before you begin to open that front door, and ask helpful hackers to help you identify security holes.