 On this day-tube, AppSight Village, I am your queen, Leora Herman. You might notice that I am Sans Tiara this year. That bling is saved for in-person occasions. I hope you enjoyed yesterday and are geared up for another great day of fun and AppSight. Speaking of gear, I am inserting a shameless plug for AppSight gear. If you go to AppSightVillage.com and click on shop, you can get your own Village Merch, which helps support our volunteer run village. Okay, plug for merch over. No village is without its challenges. And I'm still not quite sure how lockpicking village is managing in safe mode. So, no village is without its challenges. A near-tube AppSight Village brought with it its own set. With DefCon going virtual, all of our combined superpowers were needed to pull this off. We really appreciate your patience and the cooperation of our speakers and volunteers as we worked things out. It has not been smooth sailing, but we made it. If you were with us last year, you heard how much we value the diversity of our community. I'm not just talking about race, religion or political views, but diversity and sexuality and gender identity, level of formal education and security experience. Talking about diversity is just worse. And what are words without actions? We must actively embody our ideals every day. And as you can see from this year's leadership, our keynotes and the speaker lineup, we have put our words into actions. And our first talk for today is certainly action-packed. Kicking off day two is Frederick Flea Lee. Flea is the CISO at Gusto, the people platform that enables 100,000-plus small businesses nationwide to pay, ensure and provide benefits for their teams. Flea previously headed up Information Security at Square and held senior security roles at Bank of America, Twilio and NetSuite. His keynote is Be Like Water, what Bruce Lee can teach us about APSEC. Please join me in welcoming Flea to the virtual stage. As of the recording of this talk, the killers of Breonna Taylor have not been charged. Hey everybody, welcome to my keynote and welcome to DEF CON day two APSEC village. I'm super excited to be here. I noticed definitely, definitely, definitely unusual circumstances, Bruce Lee and how I believe he relates to application security and some of the things that we can actually learn from him. Obviously there's a couple of things, kind of get out of the way, which is introductions. As I said, my name is Frederick Lee. Most people call me Flea. And I wanna talk to you about what I do. I'm currently the CISO of a company called Gusto. We're actually focused on building a people platform that enables small and medium-sized businesses to kind of give their employees all those things that one would want to have a delightful work experience. Gusto's not the only place I've worked at them. Also led Security at Square, a fintech company. I led Security at NetSuite, yet I'm in the SaaS company. I was at Twilio, I was also at Bentfair. So for those of you that are fricking gamblers, et cetera, you might remember that name. Four to five, many, many moons ago and even Bank of America. Those are all just like random companies, all random and all really, really different. And I've had numerous different roles over the years. Like I started my career as a software developer. I'm just writing code like a lot of you, but I've also spent time being a sysad man, including like crawling through spaces and running cables, et cetera. It's a really, really fulfilling job. Took that and then I decided, hey, you know what, I want to actually spend more time going back to my roots as a security researcher, practicing security in various different places. And I've been fortunate enough to actually be on several different world-class security teams. And I've also been fortunate enough to become a security leader. Both as just a direct line manager, director, and ultimately, you know, a couple of stents as being a syso. With all those things said, you know, similar to my previous experience at other companies, all those roles are all so different. But really, none of that should matter, right? We always do these things in slides, in particular in keynotes, et cetera. Like, oh, let me tell you a little bit about my history with the idea that somehow me having experience being more mature, we just put it that way, and having several, you know, decades under my belt is somehow meaning that I have something to teach you or that you should be paying attention to me, that you should view people such as myself as quote unquote thought leaders. But really, you don't care about my background. Hopefully you don't. Hopefully you really hear, because like me, you can hear more about Bruce. Bruce Lee is one of my idols and somebody I look up to, both as just a good human being and some of the phenomenal things that he's actually done throughout his life, and also as a philosopher and some of the things that we can take away from that. So for those of you that aren't familiar with Bruce Lee, he's a native San Franciscan. A lot of people actually don't know that. You know, probably his big claim to fame is all of the martial arts movies that he's been in, you know, Big Boss, Enter the Dragon, which I think, you know, obviously everybody knows. But some of the other things I think people forget about, it's like a lot of the work that he's done just in general to make the world a better place. He was instrumental in breaking down lots and lots of stereotypes. So like stereotypes around like Asians in Hollywood and just Asians in society in general, like he made it okay, slash essentially effectively broke through to have strong leading roles for Asians and strong leading roles, particular for Asian men. But he did even more outside of his Hollywood career because he was a world-class martial artist and he was a big proponent, not only of practicing martial arts, but making martial arts available to everybody, regardless of your race, gender, body style, et cetera. He pushed back on the belief that there was only one type of person and he also pushed back on the belief that there's only one style of martial arts that was suitable for all things. He really was a Renaissance man. He believed in constantly learning and constantly growing, studying everything from boxing to ballet, even philosophy. He's also known for beating up Wong Jack Mann, a kung fu practitioner in Oakland. And what was interesting about this situation was that it was related to Bruce Lee's desire to make sure that his learnings and his philosophy and just the advantages of martial arts were available to all people at a time when a lot of people felt that martial arts and particular kung fu should only be taught to Chinese people and it should not be available to other races. I love this quote that actually recounts Bruce Lee's perspective on the fight, not just read it for you. I got into a fight in San Francisco with a kung fu cat and after a brief encounter, the son of a bitch started to run. I chased him and like a fool, kept plunging him behind his head and back. Soon my fist began to swell from hitting his hard head. Right then, I realized Wing Chun was not too practical and began to alter my way of fighting. This really was kind of like the birth and the inspiration of Bruce Lee to start seeking out better ways to practice martial arts. And ultimately, Lin lent his way towards creating jit kundou, a form and his philosophy of martial arts, which essentially means the way of an intercepting fist. Bruce Lee is probably the first true quote unquote mixed martial artist. He described his style as hybrid fighting. So jit kundou, what exactly is it, what is it about, et cetera? Like one of the key principles of jit kundou is that it's focused on the outcome of a fight, not just the kata, not just practices, not just forms, but really the ultimate goal which is to essentially stop the fight. He wanted to make sure that his form of martial arts and his philosophy got rid of the dogma, that it allowed you to leverage all the techniques across a wide gamut of martial arts. He also wanted to make sure that when he was training and that his students were training, that they were actually training for realistic scenarios, not just sparring matches and not just kung fu competitions. He felt that you needed to be constantly preparing yourself and constantly conditioning yourself and that with that combination of letting go of dogma and constant preparation, you could ultimately get to a fluid state so you were always prepared without being stressed. He was a permanent student and he believes that all people should always be learning. I love this quote by him and I think there's so much for us to take away from it which is absorb what is useful, reject what is useless, add what is essentially your own. I have not invented a new style, composite modified or otherwise that is set within distinct form as a part from this method or that method. On the contrary, I hope to free my followers from clinging to styles, patterns or molds. So what does this have to do with AppSec? I understand you, this seems like a really, really drawn out analogy. I promise you that there is something here. I believe that AppSec has actually fallen into a lot of the same traps that previous martial arts practitioners had. There was always this idea that, oh, my style, the superiority of your style, I'm gonna go to your dojo and challenge your master, and we have a lot of those same tendencies inside of security. Instead of Sensei's, we have thought leaders. I'm okay with that actually being an insult. I've been called that myself and I probably have been guilty of perpetuating some of the same problems that these thought leaders are doing. We are heavily reliant upon dogma. There are some people who are like, oh, if you're not practicing DevSecOps, then you're not really practicing AppSec. Your security program isn't gonna work. There are others that believe like, oh, you need to be following something that's from NIST and that's how application security is supposed to be approached. Often we've kind of forgotten what the real point of application security is. When Jeet Kune Do, Bruce Lee thinks about this concept of, hey, the true purpose is to end the fight. Inside of application security, our true purpose is to actually create and have secure outcomes. Another issue that we have in application security is that we often get distracted, right? We're distracted by whatever the latest zero day is. Instead of actually really thinking about the common threads like in Jeet Kune Do, Bruce Lee wanted people to focus on realistic fighting, not just these outliers and things like that, the things you're gonna come across on a day-to-day basis. Also, we have similar problems with gatekeeping. There's a lot more we're gonna actually be doing that could bring more people into application security, but we've always kind of perpetuated this myth either intentionally or unintentionally that AppSec is only for these blessed few and they have to look a certain way. They had to belong to certain crews and cliques or they had to have gone to a certain school. Ultimately, we've latched onto these ideas so hard and we've been so inflexible that we're really like a rock. Instead, we must be like water. So, let's actually talk about Jeet Kune Do for AppSec. I want to start a little bit actually talking about the styles of AppSec, right? There is the traditional style. And I think in particularly some of you that are older or maybe actually work in a large organization, you might actually be familiar with this. Generally, the traditional style is guided by compliance. Hey, what are the regulations? What are the things we have to do to check the box? It's heavily focused on testing and auditing. It works really, really well with more traditional SDLCs, like companies that are releasing software once or twice a year and probably still practicing a waterfall-type methodology. Like I said, it's really, really common in large corporations. And because of that, they're often just focused on buying tools. Like, hey, let me go get a license for Fortify. Let me go get a really expensive license for some dynamic testing suite, et cetera. But there actually are a lot of good things about this style. Like, one, it actually is predictable and repeatable, right? And it's great because nobody is surprised by what is expected and what is going to happen when the application security team engages with them. You produce a lot of artifacts and a lot of evidence. That sounds like a lot of paperwork, but in particular, in heavily regulated industries, that is great when you have to deal with auditors because auditors actually understand it and it makes them happy. It allows for a lot of control over development and over the developers. And it makes executives at these large corporations really, really comfortable because they can always go back and say, look, we followed the best practices. We're doing what all the other large corporations are doing. Look at how rigid and in control we are. And that gives them a lot of comfort. It also is kind of a good way to have some deniability. One other good thing about it is because of this really, really aggressive, maybe oppressive, top-down style is that it makes it really easy to have mandatory developer training. And I think everybody believes that when developers know more about security and developing good secure software, they generally have fewer security vulnerabilities. Obviously, this isn't perfect. There's a reason why tons of people no longer use this methodology. But it slows down developers. And that can definitely have an impact on your competitive advantage. It over, over, over indexes on compliance and process, et cetera. And oftentimes people and companies forget about addressing true risk because they're so worried about checking boxes. These are the kind of situations where you have to have a large app sec team. There's no way that you can actually do these many reviews, do this much process with a four, five, 10, even a 15-person app sec team. The other big thing is that that part that the execs like, that deniability aspect, it's not the same as actually being secure. Yes, just because you won't get carded away to jail when you're in front of Congress, et cetera, after your breach, it doesn't mean that you actually did the right thing by your customers and by the rest of the ecosystem that relies upon you. Another thing is that it also kind of separates the security team from the developers. And oftentimes the security team doesn't really understand the code base or the product, because they're really focused on trying to just find holes and go through a process. And that can also lead towards a lot of conflict with developers. And finally, at least personally, I find this style to be soul crushing. This is part of my job when I was a bank of America and it really can be confining and also having that antagonistic relationship as somebody who identifies as an engineer, just isn't fun. What a lot of people actually practice now is kind of like this dev sec ops, dev ops, whatever acronyms you want to use, security engineering, et cetera, this more agile application security type practice. It's a great thing in that aspect because it really is heavily guided by engineering. And that's really, really good at having an application security team that is our engineers and correlate to engineers, just pays dividends. The security team is there to actually just, kind of like you write code and design systems. They really are about building golden paths, building safe defaults, other things that actually just make a developer's life much easier because a developer doesn't have to worry about security as much. And it's often also focused heavily on this idea that if you can build the right golden path, then the developers can actually have a lot more freedom to exercise their creativity and actually launch interesting and good products. You see this style very much in startups or probably the best way to actually describe it is Silicon Valley style technology companies. But I love the fact that it does have this engineering first focus. It's like I said, it's a lot of good that comes out of this because code scales. And what that means is you can also have a really, really lean security team and they can move kind of close to the developer speed. You can get a really, really good understanding of the code and what the actual product goals are by the security team. And that allows the app sec team to really make pragmatic choices in some of the things that they're building. And also they're more focused on preventive measures as opposed to just purely detective measures, which is more like the traditional style. As much as I love this style, it isn't perfect either. Like one of the big things is that oftentimes because there's not a huge paper trail or a lot of things are actually more innovative, it's hard for external regulators to understand and that can lead to gaps and potential issues and sometimes even fines. Because often the security teams are really, really lean, you can find yourself in a scenario where even if you have a lot of high caliber security engineers, they still get overwhelmed by the developers. In general, the development, broader development team is still gonna be larger than your app sec team. And then finally, when I put my pointy-haired hat on or pointy-haired boss hat on, whatever, it's difficult to actually find really, really good app sec engineers that can code, understand security and understand how to actually build things that make developers easier and those app sec engineers tend to be a little bit more expensive. There's another style, though, that I find interesting and I think a lot of you have probably been there before, at least no people that are there, which is a style called the pleading and prayer style. And this is generally characterized by a company that's more guided by cost. These generally tend to be smaller companies, maybe like a really, really small startup, like maybe less than 10 people. They don't think they're ready yet for a security team and also some companies that don't consider themselves technology companies. Like maybe it's an architectural firm or a law firm or maybe it is a financial institution and so they don't really think they deal with software. They don't think that they have application security type problems. They don't think they're regulated, so there's no external pressure on them as well. And when security needs to do arise, they rely more on this kind of like volunteer firefighter department type method. One of the good aspects of one of the things that actually makes it attractive about it, is that it's cheap, right? Because you're not paying for security people. It's cheap, right? That's headcount, you're not buying tools. All these other kind of things that can pile up that can seem like costs that are unnecessary because security can appear to be invisible unless something goes wrong. Ultimately, statistics are actually kind of on their side. The reality is is that most companies don't have a significant breach. There are definitely bad aspects of this though, right? You know, literally you get what you pay for. I've told people this time and time again, cheap security is generally expensive security, right? Statistics are on your side until they are not, right? When you roll the dice the wrong time, that one time it can be dramatically consequential and when you don't have an app sec team, you now find yourself in a bind. A lot of these companies forget that they are still utilizing software or writing software even if it's a tiny amount that can still have some impact to their business and ultimately to their customers. No one in the company is even aware because no one in the company is focused on software security until something goes wrong. You know, one of the things that I've learned long ago is that ultimately software is eating the world, right? And that's what allows us to be so innovative and that's also what allows us to have a virtual DEFCON here in COVID land. One thing that you notice about this though is that all of these styles work. They all work. As I mentioned, statistics kind of show that most companies don't get breached. Now, I say they all work, that doesn't necessarily mean that they're all secure and that it delivers the same level of security and resilience as some of the other styles but the reality is is that yeah, a lot of people can get by with any of these models and in some cases these models are really well tuned for the exact business need that's there. So, you know, that's actually a good thing, right? That's something that they all have in common. They also have another thing in common. All of these styles fail. They all break down at some point depending on actually what's going on in the company, depending on actually what's going on in the ecosystem. So, if you are in a more traditional organization that's actually practicing a more regimented style of security and app sec, what happens when you get a new VP of engineering or a new CTA that wants to be more agile and it's hiring like really aggressive developers and wants to move to a style where there's kind of like continuous delivery? That traditional security team just kind of breaks. When you think about this DevSecOps style slash agile style, what happens when these companies do get much bigger and they are heavily regulated and they now have to have a lot more process? How do you keep your app sec people more engaged? How do you actually deal with the bureaucracy that's actually now being forced down on you? On the pleading and parasite, it fails because yeah, eventually something might go wrong. So, what do we need to do about this? One of the things that has to recognize is that we as application security practitioners, we need to change based on the circumstances of what's going on in the company that we're in or the company that we may be joining. So, for me, I could not use the same style of application security that I practiced at a bank when I moved to a company like Twilio that's extremely agile, right? You know, when I was just a lowly engineer working in a meteorological center, that style of kind of like the, you know, plead and pray methodology, yeah, I can't use that inside of a bank where it's heavily regulated. You know, the world is constantly changing, threats are constantly changing, where I go in my career and where you may go in your career is going to change and what that means is that if you're too dogmatic, you will ultimately fail. As I mentioned, you also have to take into account who your adversaries are. You have to recognize that some of the things that are structured for a heavily regulated company and who they believe that they are, you know, targets from, like organized crime, et cetera, how those adversaries operate might be very different than how an adversary might operate for a social media company or some other quote, unquote, Silicon Valley style company. And so you need to be aware of that when you are designing and building and practicing application security inside these companies. The other thing to take into account is that even though you might understand your adversary today, your adversary is always changing. So one of the things that I think we have to come back to and one of the things I want to borrow and I have borrowed from, you know, Bruce Lee, is this idea of focusing on realistic fights or essentially realistic scenarios, right? You need to base your app sec program on the actual likely threats and not make some of the mistakes I've seen in the past. Like it's really common to go into an organization and see that, oh, they're practicing traditional app sec heavily, you know, regimented and they're given embedded C programmers, OWAS top 10 security training. That makes no sense at all, right? You need to actually modify based on what the company is looking like. You need to also like regularly review and adjust those threat models. Because as I said, you know, your adversaries are changing, your infrastructure is changing. The world around you is not static. So these static dogmatic styles of application security also need to change as well. And don't make any mistake about it. All of the styles are dogmatic, even the ones that claim to be agile. Some of the things I think are useful inside of organizations is going back and really understanding the past, getting a better understanding of where vulnerabilities have happened previously. So you can actually start really getting a gauge of what's important to the company, to the customers and how you commonly make mistakes. Cause those are the realistic fights that you've been in. And so that's what you need to practice for. And you also need to go back and actually say like, well, what is it we really own? What are the key assets here? And what kind of adversaries are going to be attracted to that? I mean, you can probably have a good idea of who your adversaries might be if you are, you know, moving billions of dollars a day. You may not understand who your adversaries are going to be if you're running social media or if you just have a cat picture website or those kinds of things. Even though this is DEF CON and there's a lot of interesting talks, definitely go check them out. Don't let the zero days distract you too much because often what's going to impact you are the 90, 180, the 365 day vulnerabilities that you haven't fixed yet. The other thing I really liked about Jeet Kune Do is that Bruce Lee really wanted to focus on the outcome of a fight, the actual intent. And the intent is to end the fight. For us as application security practitioners, the intent is to provide secure outcomes and you should do that with the least amount of energy in the most direct path. An interesting thing about Jeet Kune Do is that Bruce Lee introduced things like groin strikes. He introduced eye pokes because he was like, hey, I want to end the fight. I don't need to care about what's the proper way or what is the dogmatic way or what the proper style is. And that means that you should be very open to using whatever tool is the most sufficient. So if pen testing gives you quick results that gives a lot of value for you and you can actually fix security issues, use that. If static analysis gives you better results, use that. People are going to harass me about this later, especially those that know me personally. It hurts to even say this. If a WAF will help you solve security problems, you should use a WAF. Ugh, ugh, I just, I need a break. Even security unicorn here doesn't believe I just said that. But it is true, right? Because you need to get rid of ego, even my ego and focus on the real goal, which is secure outcomes, not the practice, the outcome. That's what we want. We want secure outcomes, not security practices. Some good security practices can lead to secure outcomes, but you should not, you know, heavily index on that. You also need to make sure that you and your application security team are also continually preparing, continually conditioning, Bruce Lee believed heavily that you should always be ready and training for a fight because you don't know when it's going to occur and you don't know what it's going to look like. If you're not practicing some of the fundamentals and if you're not practicing being ready, then you will always be on your back foot, which sets you up for failure. We have to remember that application security software itself, how we design and build software and infrastructure is changing daily and the things that you learned today or the things you learned five years ago may not actually be useful tomorrow. Now there are some fundamentals and some principles and things like that that I do believe continue to be useful. Like I think threat modeling, that's just, to me, it's just common sense. It's like, you know, you should know who your opponent is. What is it you're training for? Or at least broadly, what kind of fight are you training for or kinds of fights? What does your environment look like and what are the things that you know that you could probably predict now? I, you know, obviously I have a static analysis background and just general code understanding background. So yes, I still love analyzing code because it actually has so much return value for you. It allows you to really get a good indication about what's going on in your ecosystem and what are potential problems that may occur. This, yeah, it's AKA know yourself, right? If you don't know yourself, how can you actually know how to actually improve? Adversarial simulation and whatever form you want it to occur in, red team, pen testing, whatever tabletop exercises, you want to constantly be training, constantly sparring. And then there's also probably one of the more important things in particular in application security, which is the effect of communication. Application security wins and fails by its ability to convey risk in a way that other people in the organization can understand to bring them along in that journey. So you actually have true allies that are going to be proactive that can actually reach into all those places where you don't have enough time or don't have enough insight and understanding. Having allies in a fight is always a good thing. I don't understand anybody that wants to have a one-on-one fight. The idea of a fair fight is just dumb, right? You should always have an advantage by any means necessary. And the thing that you should remember is that these are the philosophies of your attackers, right? An attacker isn't going to say like, oh, well, this bank practices this traditional style of security. So I need to make sure that my attack matches that. No, no, they're not going to do that. They're going to use whatever is most efficient to get them the results that they want. An important thing that Bruce Lee believed was this idea that not only should he be teaching others, but he should be learning from others and learning from his students. Because the people that we actually interact with in application security, regardless of where they come from, all have something that we can learn from. And when you're bringing people along on the journey, it can also help you refine your understanding of application security and find out where your gaps are or maybe even be introduced to new concepts that you may have never even considered before. I, you know, obviously, you know, I'm not a big fan of some of these security gatekeeping that goes on and I've been guilty of it myself. But what I have learned is that security comes in all shapes, forms, sizes and backgrounds. And you can have somebody that doesn't even have a programming background. That's a phenomenal application security practitioner. You can have somebody that was maybe just a network engineer. You could even have somebody that was working at a front desk at a company, bringing significant value to an application security team. The gatekeeping bothers me also because everybody was a noob. There's nobody out there that was not a noob at some point. And anytime new technology is introduced, you're in that position again of being a newbie. So we just gotta get rid of the egos, y'all. The more we can invest in broadening the ecosystem, the more we can invest in bringing more and more people along, the better our app sec journey is going to be because we have more allies, we have more coverage. And you also get maybe a little bit of time back to maybe explore some of those zero day things that you're interested in, that I previously said, hey, don't get distracted by. You know, some of the things you can also take away from teaching others and bringing more people into application security is that when you understand everybody else's journey, you get to understand a little bit more about your own journey. And when you start listening to other people, you also learn more things you can incorporate into things like threat modeling, incorporate into things like abuse protection. Like we see this actually in the world today with regards to some of the things like privacy, for example, at least anecdotally, I've noticed that teams that are more diverse actually have better attitudes around privacy because there are more opinions about how various features and functions impact people based on what their life is like. I know that me as a six foot one black male, I have a different threat profile than a five foot one woman and what I want on the internet or from an application may be different. Somebody may be in an abusive relationship and they're worried about stalkers. And that's a different profile. If you don't have people on the team that can bring those things to the table, then you're actually, you're actually operating at a deficit. You really want to also make sure you're pushing yourself outside of your comfort zones and dipping into other areas of the business. As a good application security practitioner, the more you can learn about the business and more you can learn about your coworkers, the better you can actually serve your company and the better you can actually serve the ecosystem. Finally, one of the big things is really what I'm arguing for here is that app sec needs to be flexible, right? If you practice just one style, if you are too dogmatic, then you will always be on the back foot and you won't be able to adjust to new threats in the landscape, you won't be able to adjust to new jobs. You will have a difficult time migrating from a heavily regulated industry to a slightly regulated industry or like a small startup, et cetera. And if I first, if you're like a startup and you're like, hey, I'm all about agile and dev sec ops, et cetera, that is good at a startup in some cases. But when you go to a heavily regulated industry, you might run into a lot of friction and you might run into a lot of problems. So one of the other things that I think is useful for that flexibility is also understanding really what is important to you and people are probably gonna be a little bit unhappy about this, be flexible about where you actually wanna invest your security resources and your security care. Occasionally that means like, yeah, you might want to tell a developer that it's okay to do a release without a full security review because really the developer is just adding an extra button on the website or an extra image on the website. And instead of delaying them with a 20, 40, 60, 80 hour application security static analysis scan, you're like, oh, just go ahead and ship it. Still be happy, you'll be happy. And ultimately it allows you to actually get some goodwill. So you can also focus on the bigger problems. You also need to be aware like, yeah, you might have to be flexible in particular if you're one of the more agile and dev sec ops type operations when new bureaucracy comes in. Yeah, you might have additional regulations. We've experienced that in the recent future. Like I'm in California and CCPA is a recent and new regulation for us. A lot of people already experienced GDPR. It's a new and recent regulation. And it's not something that you were able to opt in or opt out of. As I mentioned, like you should think a lot about being flexible to have compromises on some of the smaller security recommendations. So you can actually have resources to get focus on the bigger risk and the bigger security regulations and security concerns. So for example, if you dump a static analysis scan in front of somebody that has 10,000 findings and you're like, oh, you need to fix every single one of those, even the low quote unquote recommendations, you're gonna quickly find yourself being walked out the door. But if you can get the neck, you focus on, hey, you know, this is actually really important. These are the high critical vulnerabilities and there's only 10 of them. Please just focus on those. You get a lot more buy in and ultimately you really are reducing risk and reducing the significant risk. And that's really what we want to do as application security practitioners. So there is no singular way to practice AppSec. There is value to be had in multiple approaches. There are no single profiles that make good AppSec practitioners. Many perspectives and backgrounds are valuable. Your approach must match the immediate situation. Being rigid in AppSec does not work. I said, empty your mind, be formless, shapeless, like water. Now you put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it in a teapot, it becomes the teapot. Now water can flow or it can crash, be water, my friend. So thank you for taking a little bit of your time out today. I'm really, really, really looking forward to interacting with some of you online, hopefully answering some questions, hopefully maybe even being challenged about some of the things that I said. As I mentioned, I can't teach you anything. I can tell you about my opinions and about my journey, but I would be even more hypocritical than I already am if I told you that I have the answers to this and that there's one particular way that you need to practice AppSec. Be like water, adjust to your environment, fill the container that you will be poured into and give the security that you really, really want to deliver to others. Thank you so much. I really, really, really do appreciate having the opportunity to speak to you and for those of you that even made it to the end of this talk.