Most teams don’t have a security problem. They have a timing problem.
By the time vulnerabilities are found, the code is already live. By the time reports are written, attackers may have already moved. And by the time fixes are prioritized, the damage is often done.
That’s the gap Derek Foster is focused on closing.
Derek is the Co-Founder and CTO of Best Defense, an AI-driven cybersecurity platform built for a world where software ships fast and breaks faster. His background spans SRE, penetration testing, and large-scale infrastructure security across fintech and enterprise systems. Across those roles, he kept seeing the same pattern: security was always behind.
In this conversation, he breaks down why that keeps happening and what needs to change.
The Core Problem: Security Is Still Too Slow
Modern development cycles have changed. Teams now deploy code daily, sometimes multiple times a day. AI tools are pushing that even further. Some teams report 2x to 10x increases in output.
Security hasn’t caught up.
Most companies still rely on periodic checks like annual or quarterly penetration tests. That model assumes systems stay stable between audits. They don’t.
Every new feature, dependency, or API creates a new attack surface. Attackers don’t wait for your next audit window. They move as soon as something is exposed.
Derek puts it simply: security can’t be a point-in-time activity in a system that changes every day.
Detection Isn’t the Bottleneck. Fixing Is.
Many companies already have tools that detect vulnerabilities. The problem is what happens next.
Security teams get flooded with alerts. Some are real. Some aren’t. Engineers have to triage, validate, reproduce, and then fix the issue. That process can take days or weeks.
In the meantime, the risk is still live.
Best Defense focuses on a different approach. Instead of stopping at detection, the system:
Proves whether a vulnerability is actually exploitable
Explains why it matters in context
Generates a targeted fix
Pushes that fix directly into the developer workflow
That last step matters most. If a fix shows up where developers already work, adoption goes up. If it requires another tool, another dashboard, or another process, it gets ignored.
Why Continuous Security Is Becoming the Default
The shift happening in cybersecurity mirrors what already happened in DevOps.
Years ago, testing happened at the end of the development cycle. Now it’s continuous. Every commit triggers tests automatically.
Security is moving the same way.
Derek calls this “shifting left,” meaning security happens earlier in the development process, closer to where code is written. The goal is simple: catch and fix issues before they ever reach production.
This becomes even more important as AI enters the stack.
AI is helping developers move faster. It’s also helping attackers move faster. The cost of launching attacks is dropping, while the speed of execution is increasing.
That compresses the window between exposure and exploitation.
If your defense doesn’t move at the same speed, you fall behind.
The Mistakes Founders Keep Making
Early-stage founders often treat security as something to handle later.
The logic is understandable. You need to ship fast, find product-market fit, and keep customers happy. Security feels like overhead.
But small gaps compound quickly.
Derek highlights a few common issues:
Weak access control and unclear identity boundaries
Unchecked third-party dependencies
Sensitive data flowing through systems without visibility
Lack of logging and monitoring
Attackers don’t need complex exploits. They look for what’s already exposed. Once inside, they move laterally and escalate access.
The advice is straightforward: build good habits early.
Know what data you have, where it lives, who can access it, and how it moves. Even basic hygiene reduces a large percentage of risk.
The Hard Tradeoff: Automation vs Control
One of the hardest problems in building AI security tools isn’t technical. It’s trust.
How much should the system do automatically? When should a human step in?
Full automation sounds appealing. But in security, mistakes can be costly. Teams need visibility, auditability, and control.
Best Defense approaches this as a spectrum:
Some actions are fully automated
Some are recommendations
Some require human approval
Getting that balance right determines whether teams actually adopt the tool.
If it’s too manual, it slows them down. If it’s too autonomous, they don’t trust it.
The Bigger Shift: Security as a Built-In System
Looking ahead, Derek expects security to become almost invisible.
Not because it’s less important, but because it’s fully integrated.
Instead of separate tools and reports, security will:
Run continuously in the background
Validate changes as they’re made
Fix issues before they surface
Provide clear context when human decisions are needed
The end state is simple: developers don’t think about security as a separate task. It’s part of how software gets built.
Why This Matters Now
The stakes are rising.
Recent data shows the average cost of a breach is around $4.4 million. At the same time, supply chain attacks and third-party vulnerabilities are increasing.
AI is accelerating both sides. More code is being written. More vulnerabilities are being introduced. And attackers have better tools to exploit them.
This creates a new baseline.
Security can’t rely on slower processes anymore. It has to match the speed of development.
Final Takeaway
Derek’s view is clear: security isn’t a checklist. It’s a system that needs to operate in real time.
If your development cycle is continuous, your security needs to be continuous too.
Everything else is just catching up.
How do you secure systems when attackers are moving faster than your developers?
Derek Foster has spent his career inside that gap. From breaking video games with GameShark to securing large-scale fintech systems, he now builds what most teams still lack: a way to test, validate, and fix vulnerabilities continuously, not once a year.
As Co-Founder and CTO of Best Defense, Derek is building an AI-driven cybersecurity platform that doesn’t just flag risks, it proves exploits and ships fixes directly into developer workflows. That shift matters now. Software velocity is accelerating, attackers are faster, and the cost of a breach averages over $4M.
In Today’s Episode We Discuss:
00:01 Introduction to Derek Foster & Best Defense
00:37 Derek’s Background and Early Curiosity in Systems
02:25 From Gaming to Cybersecurity Foundations
04:41 First Experiences in Security and Problem Solving
07:24 Origin Story of Best Defense
10:42 AI, Developer Velocity, and Rising Security Risks
13:15 Target Customers and User Focus
14:29 Why Traditional Security Models Are Broken
17:30 AI, Trust, and Security in Developer Workflows
21:19 Fixing Vulnerabilities vs Detecting Them
23:12 Building Automated Security Remediation
26:32 Market Trends and Investor Blind Spots
29:32 Common Security Mistakes Founders Make
31:52 Hardest Engineering Decisions at Best Defense
33:56 Open Source vs Closed Source Strategy
36:12 Long-Term Vision for Cybersecurity
39:30 Red Team vs Blue Team Explained
42:28 The Future of Cybersecurity and Automation
46:07 Seamless Security in Developer Workflows
48:30 Metrics That Signal Industry Change
49:37 Governance Debt and AI Risk
51:19 SOC 2 Compliance and Security Standards
👂🎧 Watch, listen, and follow on your favorite platform: https://tr.ee/S2ayrbx_fL
🙏 Join the conversation on your favorite social network: https://linktr.ee/theignitepodcast
Chapters:
00:01 Introduction to Derek Foster & Best Defense
00:37 Derek’s Background and Early Curiosity in Systems
02:25 From Gaming to Cybersecurity Foundations
04:41 First Experiences in Security and Problem Solving
07:24 Origin Story of Best Defense
10:42 AI, Developer Velocity, and Rising Security Risks
13:15 Target Customers and User Focus
14:29 Why Traditional Security Models Are Broken
17:30 AI, Trust, and Security in Developer Workflows
21:19 Fixing Vulnerabilities vs Detecting Them
23:12 Building Automated Security Remediation
26:32 Market Trends and Investor Blind Spots
29:32 Common Security Mistakes Founders Make
31:52 Hardest Engineering Decisions at Best Defense
33:56 Open Source vs Closed Source Strategy
36:12 Long-Term Vision for Cybersecurity
39:30 Red Team vs Blue Team Explained
42:28 The Future of Cybersecurity and Automation
46:07 Seamless Security in Developer Workflows
48:30 Metrics That Signal Industry Change
49:37 Governance Debt and AI Risk
51:19 SOC 2 Compliance and Security Standards
Transcript
Brian Bell (00:01:01): Hey everyone Welcome back to the Ignite Podcast today we’re thrilled to have Derek Foster on the mic he’s the co-founder and CTO of best defense an AI driven cyber security platform building what they call continuous security and resilience testing kind of a mouthful Derek has spent more than a decade working in SRE pen testing large-scale infra security across fintech and enterprise platforms and today’s helping build technology that automatically detects vulnerabilities and even ships fixes directly into developer workflows we’re excited to talk to him about his journey the future of cybersecurity and what he’s building thanks for coming on Derek
Derek Foster (00:01:34): Hey, no problem. I’m happy to be here just to talk shop.
Brian Bell (00:01:38): Yeah. Fair disclosure, Best Defense is a portfolio company, so we’re going to be nice. I’d love to get your origin story. What’s your background?
Derek Foster (00:01:44): You know, it really just started off with a lot of curiosity in the beginning more than anything else early on. So when I was young, I was kind of always drawn to systems, like not just using them, but understanding why they behave the way that they do. and funny enough it actually originated from the gaming space you know I play a lot of games with friends and I was kind of the one that was more particularly interested in the how that they were building it than playing the game itself so I tinkered a lot with it one of my favorite things that I picked up and I guess that would be related to cyber security in a way was something called a game shark and I may be dating myself a little bit here but it was this nifty little in-between that you could put in on this device and It would basically overwrite things during execution time You can put a little code
Brian Bell (00:02:32): in there and it’d give you infinite life on a game or something Yeah, exactly that Regular Super Nintendo kind of attachment on the cartridge Yes,
Derek Foster (00:02:41): absolutely And that’s just kind of got me fascinated as to how is that actually working behind the scenes I just plug in this thing in between and it’s doing something magical And I kind of picked that part and learned a little bit more about the memory management and how things happen on the on the board and the transfer of data, right? So early on that garnered a pretty good interest to computers in general and then it became networks and then software and then eventually security and infrared scale. Thankfully I’ve been blessed to have some good experience like that. So over time I realized that I was really attracted to that intersection of complexity and consequence from the gaming days. So I just liked the situations where the tech details really mattered more than anything.
Brian Bell (00:03:27): Back when video games were actually hard too like you needed a game shark in some cases like I don’t know I remember like Ninja Gaiden like it was almost like impossible like to beat Ninja Gaiden which I did a Christmas or two ago I sat there on the couch with the Nintendo Switch and beat Ninja Gaiden but it had the reverse thing where you could like press the two button the rockers and go back you know if you messed up and it still took me like four hours to beat the game and that was like with like redos yeah it was kind of you didn’t have a redo like you just know you just had to start
Derek Foster (00:03:59): over yeah they had it really good these days with that we built a certain amount of grit and resiliency with the games that came out early on especially Super Mario and stuff like that I mean yeah go back to entirely they still keep some of those philosophies in the Dark Souls games these days right yeah where you have to start over quite considerably if you fail but nowhere near
Brian Bell (00:04:20): as rough as it was before my main game is Escape from Tarkov which I still play a few times a week now and that game is very unforgiving on dying like you lose all your gear and it like it takes a while to kind of earn it back it reminds me of the
Derek Foster (00:04:34): RuneScape days yeah playing that you know you go into the wild and if you get lured out by higher levels on the promise of good good gear and then they just jump in the woods and you lose all your stuff
Brian Bell (00:04:46): Do you recall your favorite GameShark hack? My favorite GameShark hack?
Derek Foster (00:04:50): This is going to sound silly, but I mean, I just loved having the infinite life’s period in anything that I was doing because it gave me the chance to really just try to break the games over and over again in many different ways without, you know, consequence. So I guess I would say unashamedly, I chose God mode most of the time.
Brian Bell (00:05:10): So gaming kind of one thing led to another and you ended up in cybersecurity. Do you remember what the first technical challenge was in cybersecurity that really grabbed you?
Derek Foster (00:05:19): You know, I don’t think that it was like any specific challenge. Like it was mostly puzzles. I just like to solve puzzles. So really like it wasn’t just solving a technical problem per se. It was just seeing how certain weaknesses could become an operational or business problem. weakness very quickly. And when I got out of college to start doing this type of work, that’s when it became much more compelling to me because of that reason. So it wasn’t just a specialty in IT, right? It’s a place where it was one of the clearest places where engineering kind of meets business reality, right? So you get to both sides of the coin, right? So a lot of people picture the cyber sex space as this kind of abstract cat and mouse type game but what hooked me was just how tangible it actually is so like a bad assumption about permissions some overlooked depth or some weak validation paths some blind spots in observability like those just don’t stay small for super long so those turn into bad stuff outages incidents and really expensive cleanups so that’s really just what I loved about the field in general like you can get you get to combine technical depth with high-stakes reasoning at the end of the day. So you’re not just saying, can I do this? You’re asking, what does it mean if this fails and how to design the systems that are resilient under this type of stress, right? So I think the first problem I ever solved in security was literally just as simple as secure API connections through leveraging tokens and stuff where the token itself was exposed through one of the repos that we had. And we just didn’t know the proper way to obfuscate and transfer this type of information around without causing any proper issues. And I mean, this was way, way early on. It was probably my first job when I was writing just straight up raw PHP codes and files with really no framework or anything like that behind it.
Brian Bell (00:07:21): So when did the idea for Best Defense first come together?
Derek Foster (00:07:24): You know, so I spent a lot of time in a multitude of different domains. So fintech, e-commerce, Multifamily housing, marketing, and such. Not only just doing general app dev, but network administration and security because of compliances and controls that were necessary, right? We worked a lot as developers and with developers to push out code at light speed. I mean, the business needs were real. They wanted new features all the time. There was no excuse. If you said it could be done in two months, they wanted it in three weeks. So there was a lot of push on developers velocity and then just to be able to get stuff out. But the problem was, was that when you’re met with that reality, you tend to circumvent a lot of the normal practices that you might put into place to have the consideration for security. You don’t really think about what type of data you’re piping through this endpoint. Where is it ending up visually at the different result pages that you may have? You’re not really sure. You’re not really sure of what compliance control you may be going against by choosing certain tech. Perhaps you didn’t check a vendor that you’re using, a new package that you brought in for any issues that they might have. Recently, all in the name of just getting things done faster, right? So we just kept getting caught up in this situation where annually, traditionally the pin tests were annually, and we would go through this bum rush process where the audits were coming up and we would buy these temporary tools to kind of throw a bunch of alerts at us, which always ended up being thousands of alerts at the end of the day. And you’d really had to sift through and figure out what was priority, what mattered, what was taken care of by compensating controls and things of that nature, right? So that you can have some kind of actionable list of things that are actual issues that could have an actual impact. And then you had to problem rush to fix those things before the others had a chance to say fail. So what we really wanted to do, and before we got to the idea of best fence there, we had worked with AI already, my co-founder, I, Dan, and we had built systems that would leverage high amounts and volumes of data and just that information, make decisions based off of a multitude, a deep amount of rule sets to make decisions on documents to create resolutions that the agents needed at the time based on that information. And this was before AI was sexy by any means necessary. So it was really hard to do at the time. But with everything that’s happened more recently, AI becoming a little bit more accessible, much better, higher context windows and things like that
Brian Bell (00:10:08): It kind of got- Well, more software than ever is being generated, right? Absolutely Things like Cloud Code and Codex and Cursor like you’re shipping more and more features than ever right business like has a never ending hedonic treadmill of feature requests and that you know given you can ship you know I’ve heard estimates of at least double if not 10x faster I think you’re going to have a lot more security vulnerabilities now right than you had you know five or ten years ago
Derek Foster (00:10:33): Yeah because you know not only did you know just the needs of the business have these developers you know inadvertently circumventing those types of checks and balances. But now you just have folks who just have no clue, period, on how to approach security or how to understand it or what’s really necessary for what it is that they’re doing conductually. I mean, it’s just generating at light speed. And traditionally, the security tools and processes have just lagged behind in that same velocity, right? It’s becoming table stakes now to bring that security up to the velocity of development. And that’s what we’re trying to do here, right? It kind of came together when Dan and I’s repeated experience turned into this kind of shared thesis. We spent enough time around those situations, those systems, those real operations and real security issues to kind of see that gap from a couple of different angles. And since they were being asked to move faster, automate more, adopt AI, but also reduce exposure and maintain trust, the tooling around just still felt too, it was just too periodic and and just really noisy. So the more we looked at it, it wasn’t like a missing feature issue per se, it was just like a categorical issue. Like security testing, exploit validation,
Brian Bell (00:11:50): resilience validation and remediation workflows and all the stuff that we focus on at Best Defense,
Derek Foster (00:11:55): they were just too disconnected from each other and tools sprawl, so many tools involved compared to how engineering teams actually operate. So it started to feel a little bit of inevitable that we should create a platform that kind of married all those ideas together made it easy to use not only for people who just didn’t have huge tech backgrounds but also configurable and targetable enough for real red team operators to use like a sniper
Brian Bell (00:12:21): instead of a shotgun per se yeah so who’s typically your customer so we find that a lot of reasons that people come to us is really just for high compliance reasons so we end up speaking with
Derek Foster (00:12:38): development teams in general red team operators who are looking to kind of give themselves superpowers and amplify their capabilities but really it’s it’s really just about the people who are using the product at the end of the day not necessarily c-suite of course we we cater to them in a way where we create nice dashboards that give them the metrics and the trend analysis of what we find and what was fixed over time how it maps to their compliances and all that but being engineers ourselves we care mostly about making it very seamless and easy to use for for the operators at the end of the day so that’s who we tend to target the most
Brian Bell (00:13:16): yeah so what so I get the problem like what was your unique take when you looked at the market and you’re like okay this should exist and it doesn’t like what was it about what you were building where you just had to like see it through and build it well there was a time when companies would think about security and intervals so you’d run
Derek Foster (00:13:28): run a pen test produce a report fix a penetration test for anybody listening doesn’t know what security is so you’re basically trying to you’re hitting endpoints and you’re trying to like get into the system who do certain like API injections and just trying to like try to fool the system into giving you access well said Brian barely barely well said no it was good so you know you’re fixing these issues and trying to satisfy some compliance requirements and then move on but that model largely assumes that your environment stays sufficiently stable between those annual quarterly checkpoints and as we know now a lot of modern environments just absolutely do not
Brian Bell (00:14:17): Yeah, you’re doing continuous integration, CICD kind of pipelines where you’re deploying every day or two or a week. So technically you should be doing pen testing every time you have a pull request, more or less, which is a developer has a piece of code and I want to integrate it into the code base and ship it. You should be able to run it both pre-integration and post.
Derek Foster (00:14:38): Yeah, yeah, absolutely. I mean, code’s just shipping so fast. Throw a change is even faster. Tendencies on top of that. but you know in AI just around all of it accelerating it so it’s not the question just really becomes like how much confidence should you really have in a point in time assessment versus like a continuously changing system right so you hit the nail on the head that’s why continuous monitoring and validation matters so much now they had a report that came out that explicitly framed that monitoring and testing around continuous monitoring and periodic penetration testing and bone assessments depending on the monitoring maturity in place so this is the New York Department of Financial Services that’s the one okay yeah I can I always have to look this stuff up it drives me nuts yeah so that is a uh that’s a pretty good reflection of where like really things have gone when when we say the the model currently is broken really just mean I guess I would say I really just mean it’s too static for the dynamic environment
Brian Bell (00:15:44): right because it’s not just about detecting vulnerabilities what your platform does is it delivers the fixes directly into developer workflows maybe you could talk a little bit about what’s the technical breakthrough that made that possible yeah so
Derek Foster (00:15:55): I mean it was just a lot of different things that kind of coalesced right there was I think the biggest one being the trust factor when it comes to you know AI and how it how it’s trusted in your workflows and what you allow it to do We’re seeing a lot of that wall break down a bit more. It’s still a bit of a divide out there, but when we’re talking about adoption of AI into the development workflow, that seems to be where it has taken storm more than any place else as it is, right? So it’s kind of changing the narrative there that AI and programming can be a viable option. I think now with still more human in the loop involved, but it’s really helping amplify the skills of people who are out there, right? People are becoming more natural with that in their flow, you know, leveraging it for planning, checking against their work, looking for issues and refactors and stuff like that. So adding in something like that in the security space just became much more viable because people are now just understand how it can fit into their workflow on the day to day basis. And with them becoming much more accurate these days than before with the benchmarks that you’ve seen from Anthropic and stuff, it’s becoming a little bit easier of a bite to chew. I don’t think they’re fully ready for it, right? We’re definitely on our way and we’re seeing that with some of our customers. So I would say secondarily to that, it’s not just the AI tools in place that are causing this kind of shift in the market. But we’re seeing the narrative change from big names in the field like Chase and JP Morgan and even Google and stuff have been coming out with some keynotes and memos that they send out about how important it is for security to be more of a continuous function in your development environments than it is periodic because of the rates of adoption from not only developers who are building stuff, but also from the attackers who are trying to get into your systems. They’re not waiting for anybody. They’re already bought on. They’re on board. There’s been a few breaches even recently stemming from, you know, other countries that have leveraged AI in a way where it was more or less unmanaged. Just a few clicks for them to orchestrate attacks across dozens of different companies to exfil data at light speed. And, you know, unless you have the same kind of momentum and velocity in your defense work as the attackers do, you’re always going to be behind. So it just makes sense now to have this AI defense versus AI offense, right? But I think there’s still something about the operators that need to be in place so that we can leverage their creativity and their skills and their experience to leverage it more as a directed system than anything else. And so bringing this all, that’s the one side of the coin, right? The secondary side of the coin is the fixing it. so the fixing it’s always been an issue as I mentioned before you get inundated with all these alerts from these systems that find it but then you have to go through the triage of verification and then fixing the issue and doing making sure that it actually works so through regression testing and things like that right so leveraging on that side of the coin to be able to create a system that not only is is accurate enough to make a thin slice change to solve the problem but also gives a human in the loop for verification for review It makes it an easy addition to the team because we’ve seen with our benchmarks about 85% reduction and mean time to resolution just because after our system takes care of all the finding it part, it has all the context and information and awareness to tell you why it’s exploitable and the way that it was exploited and the reason why you should fix it in this way. And that makes it easy for the dev to sign off and say, okay, that looks like a great a great fix. Let’s click it through. And the red team operators, I’ll say from my recent ICP interviews, have been primarily excited about the fixing it part because there’s there’s just so much.
Brian Bell (00:19:48): they have to do they can detect a lot of issues right and like a bunch of exploitation surface area but now they got to go fix it right and I think that’s an important distinction is it’s not just detecting the exploit like points but also generating the fixes maybe maybe you talk about like how hard that was technically to build that kind of system
Derek Foster (00:20:05): so when you think about code fixing you know a lot of people will you know consider something like Anthropic and it it will fix your code and I mean it’s a powerful powerful AI and it it can fix issues when it finds them but there’s a few things around that that needed were necessary for this to be adoptable at a in a scalable sense and and for organizations that are high compliance rights it’s it’s really not about can the AI generate text for the security fix the unlock was just the bridge between that gap and between the detection and action right so this part of
Brian Bell (00:20:43): the system that was super difficult was and then verification so it’s not just the detection and the patching but then it’s like designing the regression tests to now okay now that we’ve merged this patch does it solve the problem that we detected and going forward every time we push more code into production, we can now run those same tests again.
Derek Foster (00:21:06): Yeah, you touched on a very key point, and that’s the exploit validation, right? A lot of the existing tools, they just tell you that something might be a problem, but to have it provably exploited is the key, you know, from that. And in that provable exploitation gives you the information and the context to create a highly targeted and effective fix for the issue.
Brian Bell (00:21:27): Yeah, it’s almost like a red team co-pilot tool. in a way. I mean, I know CodeBuy is kind of a dirty word now in software, but it is sort of like that. It’s a cloud code for red teaming.
Derek Foster (00:21:38): Yeah, I think that’s a pretty good way to put it. I’m going to steal that one. I’m going to write that down somewhere. Cloud code for red teaming. Write that down somewhere because it is, and it needs to be focused on those specific issues and to leverage the same tools that they use on a day-to-day basis and the way that they would use them because they just spend an enormous amount of time doing the reconnaissance on the targets that they’re given to do the enumeration to find out where those holes are and the scanning of the vulnerabilities to build that attack surface. There’s so much to that part of the job that takes so much time that by the time they get through that and run through all the tests and find things, the devs have already pushed out a ton of stuff. The attackers may have already found those things that needed to be patched before then. So that needed to be sped up. to meet today’s demand and velocity. And it was especially timely now because AI related risk is just a huge governance problem, not just a product problem per se. If you read up on IBM’s 2025 cost of data breach research, ungoverned AI systems are just way more likely to be breached and costly when they are. And that average right now is sitting at like 4.4 million per breach. So it’s not just creating opportunities for defenders, It’s also raising the cost of weak oversight, the late periodic checks that are there, right? So at the end of the day, it’s powerful to consider having this in your workflow, especially for the remediation. But yeah, that’s what I would say at the end of the day.
Brian Bell (00:23:12): Yeah, I mean, so this is a huge market. Obviously, I think the timing is excellent. AI is creating new gaps that can be exploited. The spending is huge. We’re seeing huge exits in this area with like Google acquiring Wiz for like $20 billion. You know, good for them. What shifts are you seeing on the ground that most investors and founders are underestimating? Just thinking.
Derek Foster (00:23:35): So dramatic pause, right? I think just the first underestimation here is just really it’s the shift of speed the attackers are just getting insanely fast like not just more sophisticated just super fast I mean AI itself is just lowering their costs fundamentally on research and contextual generation and like social engineering support that was a that was what we saw most most of what AI was being used by the threat actors first when that stuff came out was just making their Their emails sound, you know, better when they came through. So you might actually believe that it’s a prince that needs money. Not only that, but also the coding assistance lowers the barrier of entry for people who are interested in becoming hackers and exploiting businesses like that, right? So the time window between exposure and exploitation matters just way more than ever. And I would say secondarily, the supply chain. and third party risks that are involved, right? So everybody says they care about it, but a lot of organizations just operationalize it weekly. In Verizon’s report last year mentioned breaches through third parties doubled like 30%. And even OWASP in their top 10, they elevated the software supply chain failures to a top tier risk category.
Brian Bell (00:25:02): So maybe you can unpack what you just said. What is that acronym for people listening? OWASP?
Derek Foster (00:25:07): OWASP? yeah oh yeah yeah of course I apologize for that I know these acronyms can just get a little well especially especially in cybersecurity there’s lots of acronym shorthand yeah yeah I know and you know that that makes a lot of sense so that’s that’s basically the if I if I don’t mess this up open worldwide application security project is what that is so They’re kind of a non-profit. They dedicate mainly to just improving security through free and open source tools at this point.
Brian Bell (00:25:38): So we back a lot of founders that are building startups. What security mistakes do you see over and over again?
Derek Foster (00:25:46): If I were to boil it down to similar patterns that show up. So when it comes to founders, they have a lot of good intentions, right? They want to ship fast and get cool features out to their customers as they’re trying to find their product market fits and just cater to those who are on there currently so that they don’t experience crazy churn to start out right so but the problem with that is that the discipline of security becomes a bit more postponed so like a lot of founders will often assume that they can just clean up identity boundaries or access control stuff or clean up their dependencies, add logging in the right places, right? And do all their exposure management stuff later. And sometimes they can, but until they can’t, then it’s super dangerous because the thing people don’t understand is that attackers don’t really need your most exotic weakness to exploit per se. They just need whatever’s available to build the map. and to be able to move laterally within systems to do something with it, right? So the pattern data that we keep seeing reinforces that it’s mainly credential abuse, vulnerability exploitation, and operational weaknesses at that, that remain some major breach paths, right? So my advice is really just don’t act like, try not to act like a giant enterprise on day one per se, but just build your good habits early. Know what you have, know what data you’re managing, know what’s exposed, know who has the access to that, and make sure you take the time to validate it. Because if you just take those steps, just keep that proper hygiene, then you can prepare yourself for most things and be able to see the writing on the wall for where your weak points really are. And that’s where you can focus your limited bandwidth of security testing on or on those layers, those holes that you have.
Brian Bell (00:27:39): Yeah. So you’re CTO, right, for Best Defense?
Derek Foster (00:27:44): Yeah.
Brian Bell (00:27:44): What has been the hardest engineering decision you’ve had to make since founding the company?
Derek Foster (00:27:49): That’s a good question. The hardest engineering decision. This might be the one. So it’s not even specifically to the engineering. It’s really just the hardest recurring decisions is where to draw the line between the autonomy and the control, okay? Because it’s really easy to think Autonomy is great I mean because autonomy is exciting right people love the idea of AI just taking over the hard parts of everything but what we found is that really our customers really need scope control and and governance and evidence and auditability and the ability to just understand what the system did and why it did it so the hard the harder engineering decisions often come down to really like where should the system act automatically where should it recommend where should it automatically fix something where should it wait for some kind of a human and rights right so that’s not just a product design question per se that’s that’s like a trust design question is kind of a product philosophy question right Yeah, because in security, it just matters a lot to trust. Because they’re not just buying capability at the end of the day. They’re buying confidence in how capability is constrained, I guess I would say. Because with security, just so much can go wrong.
Brian Bell (00:29:18): And you guys are closed source, right?
Derek Foster (00:29:20): At this moment, yeah.
Brian Bell (00:29:21): What was that decision like? Because you probably looked at it and you probably considered open source. So there’s some security companies that kind of start with that kind of open source framework and then build a SaaS offering on top of an open source. Did you guys consider open source when you guys launched?
Derek Foster (00:29:37): Yeah, we certainly did. We certainly did. And I think that that’s not even out of the cards right now. We’re actually putting together one of our first open source contributions, which is going to kind of be a light version of the red teaming side of things and perhaps even with remediation coupled with it, right? A light version of that to help out the community. But I would say the core reason why we didn’t start off with that was simply because we were building these tools for our own internal use at the time for our own needs and really didn’t expand out into the space until we realized that other people might actually need it, right? And by that point, We’d already been working with other red teamers and stuff on design and figuring out how it can work at scale operationally. There’s pieces of this that will become open source and I probably already have, even from other people. But there’s a real need for the system that lives around that. And that’s when you start getting into the enterprise level, the public sector level with government and stuff. They can’t particularly just lean on on the open source side of things because they need a higher level of operationalization of governance and auditability that needs to surround these tools in order for them to be safe to use. So that’s one of the reasons why we chose to do that initially, because we want to figure it out as we’re going along here with our customers and as we grow. And then once we understand what would be the safest output for the general public so that they can do the same kind of things that we do to some degree, then that’s going to be when we do that.
