Collaboration is Key: Bridging the Gap Between Developers and Cybersecurity Experts | Ep. 16

In this episode of The Med Device Cyber Podcast, hosts Trevor Slattery and Christian Espinosa from Blue Goat Cyber delve into the often-contentious relationship between software developers and cybersecurity professionals. They frame the discussion around the fundamental problem of bridging the communication and priority gap that exists between these two critical teams, a challenge that Christian Espinosa addresses in his book, "The Smartest Person in the Room." He argues that the high-IQ and ego-driven nature of both fields can lead to friction, as each group's identity is tied to being the expert in either building or breaking a system. This dynamic frequently results in poor collaboration and communication, hindering the ultimate goal of creating a secure product. The hosts explore a common and problematic scenario where medical device manufacturers delay cybersecurity testing until just weeks before their FDA submission deadline. When penetration testers inevitably discover a multitude of vulnerabilities, the development team's reaction is often defensive. Developers, proud of the product they've built, may deny the feasibility of the exploits or feel personally attacked by the long list of identified flaws. The hosts acknowledge the validity of this emotional response but stress that it creates a significant obstacle. They argue that the primary responsibility of a cybersecurity professional extends beyond simply finding vulnerabilities; it includes delivering a clear, actionable report that helps developers understand the risks and empowers them to fix the issues. If the report is confusing or overly technical without providing context, the pen tester has failed in their core duty. Throughout the conversation, Slattery and Espinosa discuss the systemic reasons why security is often an afterthought. Business pressures, such as unrealistic timelines and budget constraints, frequently lead management to rush products to market, making cybersecurity a "necessary evil" that is the first to be cut. This is compounded by an educational gap, where secure coding practices are not a foundational part of software development training, leading developers to unknowingly introduce vulnerabilities, sometimes by copying insecure code directly from online sources like Stack Overflow. The hosts conclude that while it's unrealistic for every developer to be a cybersecurity expert, fostering a basic understanding of core security principles—such as input validation and proper credential management—is essential. By integrating a security-first mindset and automated tools early into the software development life cycle (DevSecOps), organizations can prevent the vast majority of common vulnerabilities, making the process more efficient, collaborative, and ultimately safer for the end-user.

Trevor: Welcome back to the Med Device Cyber podcast. I'm Trevor Slattery here with the co-host Christian Espinosa. And today we're talking about a little bit of a controversial topic, bridging the gap between developers and cyber security. How are you doing today, Christian? Christian: I'm not doing that great. I have a cold and it's been... It's like one hour I'll feel really good, next hour I'm like coughing and my nose is running, so... you know, it depends. But I'm glad to be here today talking about this controversial topic. I think it's a fundamental problem that we are not making much progress on. Trevor: Yeah, you know, someone should write a book on that. Seems like a good topic to cover. Christian: Yeah, I did write a book on that. Are you talking about my book? Trevor: I am. The Smartest Person in the Room. Christian: Yeah, I have a little plug into it. Yeah, it's about the egos with high IQ individuals and they want to protect their identity at all costs, so they want to be smarter than everybody because that's their identity, which doesn't make for good collaboration or communication typically. Trevor: No, and that can be a problem with developers and cybersecurity experts. If someone's really good at making something or really good at breaking something, they're going to be pretty proud of that fact and can lead to clashes here and there. Christian: Yeah, and since we're talking about developers, I think it's interesting, because we've had this scenario come up quite a bit, where the... a manufacturer waits to... a medical device manufacturer waits to like 60 days before their FDA submission, as an example, and they... we, they come to us and we test everything, we find like a thousand vulnerabilities. And then we tell them the vulnerabilities, and their software developers are like, "There's no way you could do this," right? They they like get defensive and argue that there's no way we could have done what we've done. Uh and how, you know, we have to have some emotional intelligence, which my book is about, to navigate that scenario. But do you think that's more the norm, or just kind of a rare scenario where the developers get defensive and like, "There's no way you could do this." What do you think based on our interactions? Trevor: It's pretty much a coin flip every time you do this interaction, whether or not it's gonna... they're gonna go, "Oh, yeah, that's really good to know. Cool, let's fix it." Or if they'll be a little bit defensive. And it makes sense. That's their product, they built it, they're proud of it. And you're saying, "Here are a thousand things you did wrong." And that can be a little bit upsetting for some people. Christian: I guess that's true. I mean, I was talking to Melissa the other day and and I I'd pointed out a couple things that she needed to improve on and she's like, "All you're doing is complaining about all this stuff I did wrong, not the stuff I did right." And I I imagine a developer feels the same way. Trevor: Well, that was your first mistake, ever pointing out anything wrong. Christian: Yeah, I uh... I'm I'm I'm constantly trying to make improvements. Sometimes I don't learn from my mistakes until like the hammer hits me over the head. Unfortunately, you know, it's like, I got to make the same mistake a few times. I try not to, but I'm not as smart as I think I am sometimes. Trevor: Yeah, and I think that with like developers making a product, those two different responses do require navigating the situation a little bit differently. Um, and this isn't to say that every time we talk to developers, they immediately like come to attack us because they think we're attacking them, which we aren't. We're just trying to make them, you know, help them build a secure product. We're trying to secure their devices and we're there to help. Uh, a lot of the times, people recognize that from the get-go. We're there to help, we're not trying to cause problems, we're not trying to, you know, make them feel bad or attack them. We're just saying, "Hey, this is what you can work on to design a safer product." And they're excited, they're enthusiastic. They like to see this come out and they can't wait to get the fixes done. That's the interaction that we always love to see. And I think that those are obviously really easy interactions, but even when someone, you know, saying, "Well, how are you finding all these problems? I don't think this is, you know, fair. Like, I can't believe you find all this." There there's a right way to navigate it and we can point out, "Hey, this isn't us trying to poke apart your product. This is the standard that we have to follow. This is what you guys have to follow. We're just helping you follow that. That's all we're doing here." Christian: Yeah, and we've had a couple interesting scenarios come up, um, since we're talking a little bit about emotional intelligence and navigating this. Didn't we have a client that we pointed something out to them. I think it was like a way we could like expose some sensitive data. And they they didn't really fix it, but they tried to trick us, didn't they? They tried to say for the one record, if you look at this one, it's fixed, but if you looked at a different record, it wasn't fixed. And I don't know how we... I wasn't involved with that scenario, but I don't know how we navigated that or what happened. Can you explain that a little bit? Trevor: Yeah, situations like that can come up where, you know, in a similar vein, we'll have people just disagree with findings. They'll say, "We don't think this is actually a problem." And we say, "Well, you know, according to ISO 27001, it is a problem. This is a key cybersecurity consideration that you missed." Um, but sometimes fixes... I think that there can be two situations where that issue comes up with the, you know, partial fix. Either developers don't exactly understand what the problem is. And when that's the case, that's our fault. Our job as penetration testers is, you know, primarily to deliver a good report. It doesn't matter how good you are at hacking into something if you can't convey that in an easy-to-understand way. That's the number one job of our testers, is deliver a good report. Christian: I agree. And and from my experience, most people don't like writing reports. Trevor: No. Christian: Which is like the challenge, right? Trevor: Yeah. Christian: That's actually all that matters with the pen test. It doesn't matter how great your hack was. It's how well it was conveyed in the report and how well it was conveyed how to fix this thing. Trevor: Yeah. No, exactly. If you go to the developer, you're like, "Let me tell you about how cool this hack was." They'll go, "Oh, how do I fix it?" and you go, "I don't know. Good luck." Then that's useless. You're providing no value to them. And so, that can be an issue that comes up. If the developer doesn't understand what the problem is and they don't understand how to properly fix it, then that's on us for not explaining it well enough. Now, the opposite situation can come up where they understand perfectly well what's going on and they just choose not to, or they do like insufficient fix, even if they know what the proper one is. Or it can be a technical constraint where they just can't fix it all the way. When that comes up, we have to find the right balance of, if there's a technical constraint, okay, how can we get it good enough? So there's still a little risk, but it's heavily reduced. If they're doing it wrong, or if they're not actively just trying to get it out of the way, then we just have to keep working through it until it's fixed. Ultimately, risk acceptance is decided by the client. We can't... we can't accept risk for them. We can only explain the risk to them. So, if they say, "Well, we don't care about this," then that's their decision. They can just leave it. But we just have to inform them of what risk they are taking on because of that. Christian: Right. Do you feel this challenge is is solvable because because from my perspective, I I'd have to look at through the lens of a software developer. Their job is to develop software and this product that's functional, it has a nice UI, uh and that's their only other job. And cybersecurity's job is to figure out all the ways to break this product. So it's a very different lens we're looking at the the so the code through. And do you think it's possible because, you know, people specialize in certain things for like a software developer to actually understand both, like how to develop the software but then also how to develop it securely because they have to have both perspectives. Do you think that's feasible or are we always have to have like a cybersecurity person or team working in conjunction with a software developer? Trevor: I do think it's possible, but I don't think that it's really that realistic. Developing really great software and really great products is extremely hard. That's why all these top developers out in San Francisco are paid, you know, a million bucks a year to write code. They're creating really cool, impactful products and they're doing it in a way that they're fixing problems with solutions that other people can't come up with. That takes a lot of skill. That takes a lot of practice. That takes, you know, 20 years of experience writing code. In the same way that super talented hackers, they can get into anything. And they spend years refining their craft. All they do is live and breathe cybersecurity. And so, I think to be truly great at both of those, there just aren't enough hours in the day. There the fields are evolving too fast. Every time you turn around, there's a new exploit or a new hacking technique out there. There are new development tools, processes, best practices, it seems every other day. So, being able to keep up with all of that is really, really hard. And I don't think that most people have the bandwidth to do everything. So, that's why it's good to have a specialty and kind of focus on one thing. Christian: Yeah, so there there are some some ways to improve that, um like a secure CI/CD pipeline or secure software development pipeline, where you have gates. Uh and the gate would be, I do this unit of code, and then I run it through this tool, and if it's not secure, I go back and fix the code before it goes to the next uh the next, you know, the system as a whole. Uh do you feel like... and OWASP has, you know, a guide on how to implement a secure software development pipeline. Do you feel like most people have a secure software development pipeline? Trevor: No. I'd say it is the tiny minority that do. And there's a lot that goes into a real secure software development life cycle. There are a lot of steps that have to be considered. There's a lot of review and testing. And I think that developers with standard development practice, like maintaining version control... Most developers know that. I'd say, you know, pretty much any developer knows that. Unit testing, pretty much any developer knows that, even if they hate it. Writing code documentation. Everyone knows it, even if they don't do it. And so those are some of the main core concepts of, you know, software development. But some security-specific things, like where are your security requirements? Before you even touch the keyboard, do any code development, what security requirements need to be built into this device? As soon as you have an idea for a product, how can you threat model that device immediately, before you've done any development? Figure out what the problems are before you introduce them into the system. These steps have to happen really early in the development life cycle, way earlier than I think most developers are doing this. Christian: I don't think anyone knows about those steps. Like they should even do like threat modeling. Trevor: Yeah. It's it's just not as common knowledge. It's not very, you know, commonly taught. Um, I always like to use the example when I was in college, I went to school for cybersecurity. I had a lot of friends that were software engineers. I had to take secure development classes, so I had to learn about secure development practices, developing in a secure software development life cycle, CI/CD pipelines, all that stuff. They did not, and they were the ones actually writing code. So, it can just partially be an education problem. Um, developers don't know what they don't know. But it's just an awareness problem too. It's not as, it's not a very forecasted issue. Nobody really talks about cybersecurity outside of the cybersecurity bubble. Uh, and that leads to developers building insecure CI/CD pipelines. Christian: Yeah, I I I don't want to put all the blame on the developers. Uh, I think one of the challenges, cuz I I know a lot of developers and we work with a lot of them, is, uh, unrealistic timelines as well. Uh, I know when I worked as a director a long time ago, I oversaw uh a big group of software developers. And we had a a road map for our product we were developing. And let's say it was supposed to be released in June, and it was January. And one day, the CEO of the company came to me, came to me and he said, uh, and this is like in Feb, this is like, in January, he said, "We we sold a bunch of units, we have to ship them by the end of February." I'm like, "Well, we haven't done all our security testing. We didn't do this, we didn't do that." He's like, "I don't care. Just package up whatever you got done and ship it out the door." I'm like, "Okay, it's got a lot of bugs in it and it's got a lot of problems." Um, but I'm sure that same scenario happens all the time everywhere. So you can't that even if the developers had a plan to secure the software, there's a business decision made that's like, "Screw it, just ship it out the door," right? Or, "Let's just submit it to the FDA, submit it to EU MDR. We don't care. We gotta keep the timeline going." Do you think that's realistic that happens a lot? Trevor: Oh, all the time. And I think that's a really big problem because, like, you know, we've said it all the time, security is not anyone's favorite budget allocation. As soon as there are... Christian: It's a necessary evil, as you like to say. Trevor: It's a necessary evil. I know when all the big tech layoffs happen, cybersecurity teams seem to get hit the hardest often. Christian: They don't like them anyway. Trevor: As soon as there are budget constraints, everyone wants to get rid of security. It's annoying. Christian: Cybersecurity people are difficult to deal with most of the time. Trevor: Yeah, they're frustrating, annoying and they all have huge egos. It's super complicated. And so, you see that it's it's never the priority. It's always on the back burner. And if there is any reason why it needs to be gone, it's gone. So, budget constraints, cybersecurity's gone. Timelines, cybersecurity's gone. It's always the first thing to go, which, you know, it's a huge security problem, but it's also a regulatory problem, which is what I think cybersecurity is at its core with medical devices. It's a regulatory problem more so than anything else. And so if you're not... Christian: But it's only a regulatory problem because there's a mandate to force cybersecurity. I feel like if there wasn't a mandate, which is a compliance driver, nobody would care about cybersecurity. Trevor: Totally. Yeah. If you don't have to do it, you don't want to do it. You know, it's cybersecurity is very expensive. Getting all this done, it takes a lot of time, it frustrates the developers because they have to go back and fix all these problems. And so, if there wasn't any, you know, mandate around it, if there were no laws around cybersecurity, if there were no punishments if you get PHI breached or something, nobody would do it. Nobody would care about it. And so, regulations are what drives cybersecurity being an industry, really. Christian: Yeah, 100%. And it's like the necessary evil, like you said. And I know, ironically, like, uh, I don't remember what episode, we were talking about comparing, uh, going to the dentist to cybersecurity, cuz it's a necessary evil. And I hate the dentist and I tell you I never go, but now I have like, part of my filling is a... a filling of my tooth is falling out. So it's like keeps cutting my my uh inside of my mouth. So I'm going to have to go to the dentist, but I don't want to do it. Trevor: I think I remember like five or six months ago bugging you to go to the dentist after this conversation. Christian: I know. I mean, I got so worried about it. I was grinding my teeth at night or something and it and it made it created the problem, you know. But now I have to go. But I don't have a dentist, I have to find a freaking dentist, which is another challenge within itself, just like choosing a cybersecurity vendor. I got to find a dentist that I can trust. Trevor: Well, I know a great one in Scottsdale, so I'll send you his number. Christian: Okay, perfect. Trevor: It's a good example. So, you know, having to deal with this problem, you're fixing a problem. You have something that is frustrating, annoying, it's already cut your mouth. Christian: And continually cutting my mouth, yes. Trevor: Yeah, it's continually cutting your mouth and, you know, it's probably going to be more expensive to fix than it would have been to prevent. And so, I feel like that's a perfect analogy for how cybersecurity works. Preventive cybersecurity is going to be cheaper than incident response, fines, and dealing with your problem. If you fix... Christian: And probably less painful. Trevor: And probably less painful. Christian: That's why I don't want to go. I know it's going to hurt. Trevor: Yeah. If you're... Christian: I'm not a wuss, but last time, they messed up an anesthesia and I almost passed out, it hurts so bad. I was like, I was like gripping the chair so hard. I thought I was going to rip the chair off and like tears were coming down my eyes and I'm just trying to gut gut it out, but I had to like raise my hand and say, "I I can't handle it anymore," you know. It was it was a traumatic experience. Trevor: Yeah, that sounds sounds like a good reason to not want to go to the dentist. Christian: That's probably how people feel about cybersecurity, though. Trevor: Yeah. Yeah, if they have like a bad... if they have a bad auditor or a bad consultant or a penetration tester who doesn't know how to deliver a report, then they go, "Great, we just wasted all this money. We still have problems and why did we do that in the first place?" Christian: Yeah, it was a painful experience for them, kind of like the dentist for me. Trevor: Yep. So, so so, if we're trying to bridge the gap, which is the, you know, the topic between software developers and cybersecurity, I I know there's this push... there's been this push forever with DevSecOps, you know, the secure software development life cycle. And I, you know, I know when it first it was dev developers and then operations. Like they need to, you know, integrate together so we actually develop software that people can use properly. And now we put, you know, you see these Venn diagrams, security in there. So, DevSecOps. But I still feel like, and we've been talking about this for like 20 years, uh, we haven't made much progress. And I, I think a lot of it has to deal with, maybe we have made some, but like you said, it costs more to add cybersecurity and some manager or the leadership in a company made a decision just to ship it whenever it was done. So I think that's one problem. But then I think the other problem you alluded to in college, we don't really teach software developers how to develop secure code, even though even though, like there's a data breach every day because often it's insecure code or insecure code. And I often it's a misconfiguration. It's like it's a combination of those two. Uh, and I would say it's probably 70%, you know, insecure code and 30% misconfiguration, no exact stats. But it seems like if the majority of breaches are caused by insecure code or insecure code, some people like to say, then how come we don't start teaching this stuff in school, in coding school to to software developers? Or is it like we we talked about earlier, is this even something that is feasible? Trevor: I think it is feasible and it's feasible to an extent. We can go back to the original point where to be truly excellent at cyber security or development, I think that needs to be your sole focus. You can be decent at one and great at the other. If you know general core cyber security concepts, data validation, how to prevent, you know, race conditions, eliminating timing attacks, basic configuration stuff, you're going to get rid of 80% of problems. Um, maybe even 90%. And then what's leftover, that's where you have someone doing targeted, specific consulting. You have a penetration tester where they live and breathe this stuff. But if you've already covered 90% of the problems, they're only picking apart a few things that you get a report back with three or four items, that's an easy fix compared to if you get that report back with 20 items. And those, you know, most of reports we see the same vulnerabilities in the same products all the time. Anytime we're dealing with a web app, I can before even taking a look at it, before even knowing what the app does, I can predict three findings that are going to be on it because they're always on it. They're always just the low-hanging fruits. Um, and actually a really interesting statistic, in big data breaches and in like organizational compromises, only 3% of breaches are because of a coding problem in an application that lets you get all the way through the app into an internal network. It's only 3%. Um, it's close to 80% are human error due to a misconfiguration or due to a fishing attack. Uh, and when I say misconfiguration, it can also include a network appliance, so like a VPN gateway or a firewall. Those can have misconfigurations or vulnerabilities in them pretty commonly. Um, but only 3% of the time it's an actual exploit in a web application. So, it's not super common to really have massive compromise from that because attackers are going for those low-hanging fruits. There's a misconfiguration. Christian: So you think the statistics are different than I said? It's it's it's reversed. It's more misconfiguration than coding errors. Trevor: Well, the reason for that is coding errors are harder to find, really. And misconfigurations are super, super easy to find. You can run a tool like Shodan, which just scans across the internet and it says, "These eight servers are misconfigured. Go get into one of them." If you're looking for a targeted attack, if someone like a nation-state actor is trying to take down one website, they're going to find problems. They're going to do it, they're going to get through. But it's it's not the easy solution. And so, usually the use case is like a nation-state attack or terrorism or targeted attack instead of just trying to get money through ransomware. And the terrorism angle or like the very targeted attack, it would be more prevalent in the medical space as opposed to like finance or something like that. Christian: Yeah. I would think with like GitHub and Bitbucket and the integrations with like SAST tools, uh, static application security testing tools and DAST tools, dynamic tools, that it would be easier to set up a secure software development pipeline. What are your thoughts on that? Trevor: You know, honestly, it's not that hard to set it up. It takes time, it takes planning, and part of why it's not so prevalent is developers will have had... they'll be in their flow. They've been developing code this way for 10 years and they've had their pipeline for 10 years. Changing that up, change... people don't like change. People don't want to change their systems, especially when it works. So, if you're standing up a new development pipeline or a new project, a new company, whatever it is, it's really not that hard to do it right the first time. You build that pipeline in, you have everyone stick to it, and it's going to fix again that 90% of problems, as long as you just stick to that pipeline. It's integrating it into an existing system that's often complex and difficult. Christian: Yeah, I guess that's true. People don't like to change that much. Uh, but we have we have the tools to make it a lot easier. Static application security tools have gotten better, but they're they're also like largely prone to false positives, which is another challenge with itself, right? Trevor: Yeah, it can definitely be an issue, but you know, luckily they aren't very prone to false negatives. Uh, it's... static application security testing tools are looking for just patterns that lead to vulnerabilities. They're not going to catch everything. Uh, like they won't catch logic flaws where the actual operation of the device causes a problem or they won't catch necessarily something like a race condition where a race condition is if you do a certain action and immediately follow it with another action, it might try to do two things at once or it'll swap the order and that can lead to a problem. It's not going to catch things like that. But it's going to say, "You missed all these hardcoded credentials." It's really good at finding those. It's going to say, "You can have a memory problem here. You're not validating your data input here." It looks for stuff like that, the low-hanging fruit that's super common, uh, easily exploited and prolific. And so these static testing tools do a really good job at getting that wide coverage. Sure they might say a lot of things like, "Oh, you're not checking... you're not freeing this memory here when you do it in the next line." and so it's just finding something fake. But it's not going to miss it if you aren't actually freeing that memory. It's not going to skip right over it. It should catch it most of the time. Christian: So I I've known software developers, we've had a few clients where the developer didn't know how to write a specific function. They searched the internet, found that function, put it in their code. How how are those things detected? Cuz I I've seen it before where they left like the comments is exactly from the internet, even like passwords and things. How do we find what's the way to find those things and how do we solve that challenge? Trevor: Ooh, that's a pretty good question. Uh, I'm sure that that could be a pretty cool AI solution. I'm not aware of any tools that are going to like scan your code and say, "Hey, I found it in stack overflow over here. You got to write this yourself." But that would be a pretty... Christian: Like if we run it through a software of unknown materials, does it kind of does some of that, but like for the suit perspective, the software of unknown provenance, but I mean, would that detect it? Trevor: That would... that just looks at the components. So if you... if a component has a known vulnerability, it'll find it, but it isn't... it's not really looking to see if developers are just copy-pasting code. I know we had uh one example where there was a key for authenticating to API to an API server. And that functionality was published on Stack Overflow, how to write out the code. And they left like the signing key in that code. And obviously got breached forever ago, like 10 years ago. But the code as a general concept for creating that signing functionality still worked. And so the team just took that code, stuck it right into their code base with the key still in it. And so when we were testing it, we captured the key and that got flagged as a known breached key. And we go, "Oh, okay." And we tried to decrypt it. Sure enough, we were able to decrypt all communications and authenticate ourselves as anything to this product. And so if they had just switched the key for something else, it would have been totally fine, but they just ripped code out of Stack Overflow, stuck it right into the product without reading what the code did. Christian: In that scenario, SAST wouldn't have caught that. The SBOM wouldn't have caught that. The penetration test is what caught that. Trevor: Exactly. So, the SAST is going to say like, you know, "Oh, you're hardcoding a credential here." But it's not going to tell you that's a bad credential. And so then you take that credential and you stick it into an environment variable, boom, SAST doesn't catch it anymore. The S-B isn't going to catch it cuz it's technically in the code that you wrote. But it's it's not a third-party component. What's going to test that is a penetration tester catching that key, taking a look at that key and going, "Oh, this is a breached key. I can decrypt this because I already know what the key says." And so you just match it against that. And then sure enough, you have the decrypted information and it's the keys to the kingdom at that point. Christian: For sure. Well, we're coming up up on time here. So, what's some advice or words of wisdom to a software developer that has all these challenges, you know, they have like these timelines, they may not know cybersecurity. You know, what what are some some pieces of advice you think would be useful for them? Trevor: I think it's about striking the balance. So, cybersecurity, we always say it, there's a big awareness problem. People aren't aware of the requirements, people aren't aware of what can go wrong. Uh, that's not an easy solution for sure. That requires a lot more effort than I think we can provide here. But for any developers listening to what they can do, it's find the balance. What can you do to understand 80% of the vulnerabilities that'll pop up? Input validation, don't hardcode your credentials, just general best practices for cybersecurity. You don't need to go all the way down the rabbit hole. Just get good enough so that you can get rid of 90% of a problem and that 10% is when you go to specialized cybersecurity help. Christian: Yeah, and I I know like OWASP.org has some guides and how to develop secure code based on the language you're writing the code in. Some uh cheat sheets, so I I would recommend going there as well. And um, yeah, I guess we'll wrap up here and I'm going to go see the dentist. Uh I don't know, I'm going to put it off for a while, but I feel like I have a second, what what were what we were talking about in the previous podcast, a second order attack, uh which is my tooth which is then attacking uh my uh my inside of my mouth so it's making me bleed. So I got I got to do something about it. Trevor: Yeah, you you got to get that fixed. Go to the dentist. Christian: Okay. All right. Well, thanks everyone for tuning in. I hope you found value in this episode and we hope to see you on the next one.