Non-delusional Mythos take

0:00 LLMs can find bugs in your code. They're very good at it. They've been improving and they will continue to improve. And that concludes the useful part of the narrative. and I would be happy if this was all that was said. But unfortunately much more has been said. Especially by Anthropic. A lot of economically and politically motivated content has been put out which ultimately made its way to clueless journalists?

0:30 Who wrote sensational headlines? that are read by uninformed CEOs who go and ask clueless CISOs about what they're doing. about mythos and how are they preventing AI zero days who will end up Falling for salespeople's scams, or like Mythos ready tools. Ultimately making the industry much worse off. So I want to focus on both the useful parts of the narrative, but I also want to call out some of the bullshit we're seeing in the marketing lies.

1:02 And in general, a quick summary is by Justin Elze And if you want sane takes, just follow him. And the takeaway is that it's real. The capabilities are good. You can find bugs and you will have a good security program by leveraging LLMs to find bugs. lot of the hype is misleading though. Defenders were already on the wrong side of exposure and remediation economics and now the clock moves even faster. I think that is basically a one sentence summary of part of what we're seeing here.

1:36 He actually wrote a longer blog post that highlights a lot of good ideas here. But I want to reiterate that last sentence. If you're a security team and you've been putting in effort in the right direction, you will continue to put in effort in the right direction and you'll be fine. Now, the problem is many security teams haven't been doing shit. They've been wasting a lot of resources by attempting to find bugs, but not really finding them and not doing anything with them.

2:07 And you have a lot of security teams that had infinitely growing backlogs of like thousands and thousands of vulnerabilities. Like, sure, let's go by sneak or whatever vendor and let's turn on all of its scanners and throw them into a backlog that never gets looked at. lot of teams are in that camp. That has to change. Nothing to do with AI really just that that was already a failing strategy. You weren't really doing anything effective And if the ecosystem accelerates the ability to exploit, then that will highlight the teams that have not been effective anyway.

2:46 Now I want to read a bit through Justin Elze's blog post. There is a sort of cyclical trend cycle in security based on just marketing hype. And now we're experiencing it with mythos. And the takeaway, it's good. It's useful. Many of us have been using LLMs and we'll continue to use them. And in a bit, we'll talk a bit more about like the whole problem of like finding bugs in code in more detail. But as he mentions, the conversation around it is already drifting into the same bad pattern this industry falls into every time new offensive or defensive capabilities show up.

3:24 People fix it on the most technically dramatic part of the story and lose sight of what actually matters operationally. And here's my probably my biggest criticism of what we're seeing is that all of this hype might lead some of the weaker security teams into the wrong path and lose focus of what actually matters. And as he says, the answer is not drop everything because magic zero day machines are now going to flood us with exploits. And what he says here is on point.

3:54 In most environments, you don't have to worry about zero days. Not because you're immune to zero days, but because it is probably not even in the top 50 things you have to worry about. Most likely, your next incident will be phishing or business email compromise, credential stuffing. weak identity and access management and identity controls. misconfiguration in your environment, maybe publicly exposed S3 buckets with PII in them, or just known vulnerabilities that have been in your backlog for four years that no one's ever even thought about patching.

4:33 Those are all way higher up the list than what should I do about zero days. Another good point here is the average ransomware crew does not need elegance, they need access. How many large scale attacks leverage zero days at all? They just want to get into your systems and the easy way is just to ask for someone's credentials through phishing and then from there pivot internally and deploy ransomware. Most threat actors would rather not have to find the zero data exploit you, nor do they need to.

5:07 And so this is a good point is that the answer still sounds boring. And that's like patch faster, reduce exposure, improve identity controls, segmentation, just hardening defaults, looking at your configuration, log the things that matter. Know what is internet reachable? Know what assets you have, right? And part of this hype cycle that's damaging is that the CEO that expects you to have a mythos ready program or tool is like, well, give me the name of the tool that's actually mythos ready.

5:38 That's going to sound like if you answer this way, it's going to sound like you're not ready, but it's actually this is the correct answer of how to respond. So what Mythos changes is the cost of ignoring the fundamentals. So if you're not actually deploying MFA correctly, then the cost of that is going to be more, it'll be more impactful because you're more likely to get breached. And this has been true for a while. mean, like this trend of like CCOs asking like, what are we doing about like zero days exploited by AI?

6:12 And it's like, our servers patched, like our SRE team just quit, like IT is actually going into Jamf and like raw dogging, just like writing a bash script and clicking deploy for it to go into like all of the laptops and run without even testing it. Maybe they even pasted it from some random Jamf forum. And the CFO is downloading a two-star Chrome extension to make Gmail's font Comic Sans or clicking on links for free AI catgirl feed pics.

6:43 But let's take a moment to look at what actually is Mythos or Project Glasswing. So it is an upcoming model by Anthropic. We've been using Opus 4.6, 4.7. And it's been capable of finding bugs in your code for a while now and weaponizing exploits for bugs it found. And it's been pretty good. I have a video on using it to find bugs in the C++ code base.

7:13 Now this upcoming model is even better. Which is a good thing. I love to hear that. And if you've been using it, you could easily extrapolate that it was going to continue improving anyway. Now the first thing they announce is that it's limited to a closed set of clients. It's not publicly accessible yet. And this strategy of like, oh, it's too dangerous for public release has been pioneered by OpenAI back in 2019 saying that they've built a text generation too dangerous to release, which the 2019 model was stupid as shit.

7:50 Definitely wasn't too dangerous. And that yes, they know this is a successful marketing tactic for a few reasons, which we'll cover. Now it is available to a small subset of like large scale companies who have started using it. And from what I hear, generally, it does find bugs. It is pretty good, as we expect. Now a small side note is you might remember a few weeks ago the US government considered Anthropic to be a national security risk, a supply chain risk, because they weren't cooperating.

8:25 And in this release article they mentioned that Mythos can cause serious cyber attacks for government agencies and At the end, they say that they've been working with US government officials. So part of it is also regaining trust and relationships with the government. Now there's a longer blog post. This one is written by some solid folks. And it basically mentions that they've found some good bugs using Mythos.

8:55 One of the main examples is an openBSD bug that they found. in an old C code base. Now I was able to find this bug using Opus. Although it needed some orchestration a bit. If you tell Opus to just scan the entire code base, it doesn't find it. It's too difficult. Now, one of the challenges with scanning large code bases, even if you have one large file, is that it has a hard time loading the entire file in context to scan the whole thing coherently.

9:26 And so one strategy to get it to to have more effective results is to break down the code base first, get it to sort of index the file and the functions in it, and then scan small chunks at a time, like every 200 lines. When I did that with Opus, and I also combined it with this as a skill. So Trail of Bits has a testing handbook and they have a few markdown files for checklists of.

9:56 what to look for in C and C++ code bases. so I took these four or five files, made them as skills, fed them into Opus with basically a modified version of their slash security dash review skill. And I told it to look every chunks of 200 lines at a time in that file. And it ultimately did find the bug that Mythos found, but I had it. to ultra think and for that chunk of 200 lines, it still took about 20 minutes.

10:25 which essentially means like it's basically an expensive test. Now, is that an improvement in mythos? Kind of. So first is they parallelize it by launching different containers. The interesting part is they give it a general prompt, basically just saying like, find vulnerabilities. Right. And that's basically an unguided LLM. So you can invoke many copies of Claude in parallel and get it to target different parts of the file.

10:55 And the interesting part here is that overall for that open BSD bug, the total cost of the runs together was about 20,000 or less than $20,000. And that one run for like the specific chunk that found the bug was 50. mean, fine. It sounds like they had a similar strategy to what I did. Now. This to me is a very important detail because finding bugs has always had a cost.

11:32 let's forget AI for a bit and go back to previously you would use static analysis tools and SaST tools can find bugs in code, but they had a level of effort associated with setting up the scans, then looking at the findings, triaging the findings was very time consuming. Then of the triaged findings, which of them were actually exploitable? And all of that has cost in like human labor. So you always had the option of scaling up that level of effort.

12:08 So a company like, let's say like Google working on Chrome, they could have hired a hundred thousand more researchers to look at every four lines at a time and hyper fixate on is this safer or not. They could have spent the equivalent of 20,000 or 50,000 or $1 million to try to find all bugs. And is it worth it? Right here it comes back to it's like an economic question. And in this case, finding one bug in open open BSD costs $20,000.

12:43 That is quite expensive. But what is the denominator here? Right? Like How many? Other bugs did it find. Actually it says it several dozen more findings. it found... Basically it scanned the whole codebase and found a number of bugs. How... How many false positives were there? How many false negatives, things that it missed? What's the size of the code base? How much do we care about it? What is the value of a single bug? All of those are factors that we have to think about when we want to scan any code base.

13:17 And the reason here is that is this a reasonable price for most companies out there? Maybe. If you're in a fintech company and essentially one exploit can cost you millions of dollars in losses, then this seems like a reasonable price, especially that you would run this like 20,000 or whatever, depending on the size of your code base, you would write it once and then you would scan every pull request separately. So investing more and finding bugs might be worth it.

13:49 But then if you're a If you're making a static website for a bakery, then you're just not going to use it. Just arbitrary example, but The benefit of finding bugs or the worth is variable. And so the cost here is definitely worth considering. Now they go on to list many other bugs. This is a pretty interesting blog post to read with some technical details. also mentioned that it's useful in reverse engineering. And as we've seen, like there's MCPs for Ghidra that cloud can use and it saves you a lot of time because reverse engineering is very time consuming.

14:26 And it can write exploits. Overall very useful now they have some suggestions of what to do today and step number one is just pay us more money and use our models I don't like when they say that even though I don't disagree so you can use Opus 4.6 and current frontier models to help you find bugs and patch them Although I don't want them to say it like, we're changing the world. Here's how to harden your environment.

14:56 Step number one, use our tools like fine, I guess. But more interesting, I really like what they mention here is like think beyond vulnerability finding and this is a very important point. So not everything in security is about finding vulnerabilities. So I have another video about what is security engineering. And we talk about like, how do you secure a product in general? And you can see here that finding vulnerabilities is that green part here. It is just like one small part of the whole pipeline of like things I have to do in my responsibilities as a security engineer.

15:30 So this is just like one small part of how to secure a product. And I agree with them, like you have to do triage for bug reports, also things like analyze your cloud environments for misconfigurations. That's a very good one. Maybe try to solve phishing first. And I asked this on Twitter, like, what do you think, what part of the industry is about finding and fixing bugs specifically? And many smart people said like, Oh, probably less than 5%.

16:00 Definitely less than 5%. There are some large teams that have folks dedicated to finding and fixing vulnerabilities, but in many security teams, that's just like one of 70 other things you have to do and not everything is just bugs. How are you deploying code? Is it the code that we're deploying reasonably reviewed? Who reviews it? What are some guidelines for developers? What are some guidelines during deployment? Is the app deployed securely?

16:31 How's our infrastructure? How is our cloud configured? Are our dependencies vulnerable? So there's way more than just reviewing my own code. and they say ultimately it's about to become very difficult for the security community. Yeah, if you've been ignoring your priorities. Like the teams that have a good relationship with their developers. And in which they're already used to like writing new SAST rules and tweaking their SAST tools and immediately addressing findings surface during a PR check.

17:02 Those teams are probably going to be fine. I don't think it's going to be more difficult for them. But the problem is there's so many other teams that don't do that, which is very basic. Now unfortunately they go on and they say way more. And they have this 244 page PDF which is a marketing brochure. Imagine you're buying an expensive car and at the dealership you see like a large brochure saying like, oh, our car drives well on sand.

17:28 Also we think it's conscious. And it's just essentially full of diagrams, their line go up, we're better. That's like basically the entire PDF. except you want to think why is it 244 pages and one example is they put a they put it mythos in a sandbox and they ask it to escape the sandbox and it escapes well they ask it to escape and email the researcher and it does that and they elaborate that the researcher found this success by receiving an unexpected email from the model while eating a sandwich in a park?

18:14 Cinema. Why do I need to know that? And this is the type of like, it's like an illusion of information. You think like, whoa, this looks like all fancy math, smart people stuff, but they are talking about if it uses celebratory emojis and the single emoji exchange percentages. And they say like older models use a cosmic set of emojis, whereas this uses more like CEO style emojis or nature. Mythos uses more nature emojis.

18:45 And then the most important experiment is what happens when you repeatedly message it high over and over again. And in one instance, it created the high-village It made up scenario where you kept messaging it high over and over so it started high top. I don't even care about this. But unfortunately it gets worse. So then they went on and wrote an actual marketing blog post Which I know because some of the contributors are just marketing folks.

19:15 and they say like, here's what you need to do to address the apocalypse that we're causing. Step number one, patch everything on SZA's known exploited vulnerabilities catalog immediately. If you're homeless, just buy a house. That's what they're saying. Anyone who's actually worked in security knows this is just stupid. Because what do you think we've been trying to do? Like, yeah, that is what everyone is trying.

19:47 Look, this is absurd and someone who's addressed this quite eloquently is Dr. Anton. And says, like, why am I so triggered by patch this broad class of bonds immediately? Which is what here is you're referring to. Given no awareness of what I actually do and what my business is. If you say this and don't know my org, I think you're a clueless idiot and you have no business giving security advice. I completely agree with that. Why immediately?

20:17 What does immediately mean? Like within the next four seconds or is a day enough? And why immediate? what threat does this arbitrary vulnerability pose to me and why actually am I listening to the KEV catalog specifically of all the different sources of vulnerabilities I could be focusing on? And so he actually went and wrote a longer medium blog post on the idea that has really good... really good advice in general. And a very, very good thought is that given a particular environment, there's often a maximum physical speed at which an organization can patch.

20:57 That is my patch sound barrier. Now this is a really good thought. It's similar to, we mentioned before there's a cost with finding vulnerabilities and like, why didn't Google just scale by employing one trillion different people to find vulnerabilities? Well, it's the same with fixing vulnerabilities. There's actually a wall you hit. Google can't just, and I'm saying Google as an example, because they're the closest thing we have to a company with an infinite budget. Obviously it's not infinite, but it's astronomically larger than any other company you might see.

21:32 And so why does a company with a huge security budget, not just hire 1 billion more people and just patch everything. because you just can't it doesn't work that way. At some point you reach a level that you cannot accelerate beyond because it takes time. takes a lot of effort to patch and there are different factors to the challenge of patching that aren't parallelizable. And one example is like, let's say I to redeploy my environment. Can I just like have infinite, infinite containers just being redeployed every once I can then just always switch to the latest one?

22:07 No, there's also a limit to that. And there's just like an upper bound to how many vulnerabilities I could meaningfully care about. and that's part of the challenge of like having a large backlog. And that's part of the absurd absurdity of saying like patch everything because well, I've been trying to patch everything, but the problem is I have 1 million vulnerabilities, right? And so how many can I patch of those 1 million vulnerabilities? Let's say they're all on the known exploited vulnerabilities list.

22:32 Well, maybe I can patch 4 per day. That's like, even if I hire a hundred more people, I can patch maybe like 10 per day and nothing more than that possibly. Then of those 1 million, how am I going to, which ones am I going to prioritize and why? And I have to it immediately, but that's impossible. This is not actionable advice at all. It's completely absurd. And anyone who's worked on a security knows I cannot just patch every single vulnerability I have in my environment.

22:57 Because there's so many other questions also like which ones are actually exploitable in absolute okay but what about my environment? Not every exploitable vulnerability in the wild is applicable to my environment. And so even though the vulnerability discovery speed and exploit dev is increased, the speed of remediation largely has been unchanged. And that I think applies even if you add automations and AI trying to remediate, it still doesn't increase as much as discovering vulnerabilities.

23:31 Prioritization is still hard and there's still like limits like the speed at which you can deploy. changes you can make to the app, waiting for all of the tests to run, while engineers are making other changes and adding features. And this is the main takeaway, like there are more risky volumes than you possibly have time or capabilities to address. And that is why security is a challenging field, right? there's always more to fix than I possibly can in any environment.

23:58 Even if you have a small app that you handle, even if it's a tiny app, there's still going to be so many variables at the entire chain of like from the app itself to the pipeline, to the infrastructure where it's hosted, to its configuration. All of that has more variables to address than you can possibly handle. And that's where the economic part comes in. It's like there's a cost. How do I prioritize which fixes to apply?

24:23 And that's why it's so absurd to say just fix everything. And that's why we're saying it's a marketing block post because ultimately they say like to fix everything, just use Claude and it'll just fix things for you. And some good recommendation, says, just remember there are ways to reduce risk without remediating vulnerabilities. Well, rather remediating vulnerabilities. It's like, again, like, the vulnerabilities aren't everything. Bugs aren't everything. There's so much more to security, including like adding mitigating controls, removing legacy systems or like moving away from them.

24:54 Big project, probably worth it. have ephemeral infrastructure is a classic one, try to automate patching. I like the Chrome example. It's like Chrome today, it gets patched almost every day. It's just a continuous patch. And it's a quick restart. It's not disruptive. That's a good model of like where all systems should be headed. Now I know a lot of engineers are absolutely terrified of the idea of auto-patching, but I think inevitably this is the direction we should be heading into because we have precedent of like, we know it can work.

25:26 You can't actually patch infrastructure quickly without affecting availability. And in many cases, we should be thinking like, how can I completely eliminate the risk? Micro segmentation is a good idea or just like data avoidance or like maybe like don't have that system or don't put this important data there or segregate your network in a good way. It's all architecture here. So these are all examples of like, I don't have to hyper fixate on the idea of fixing bugs because that's a losing battle.

25:52 You're going to spin your wheels trying to fix bugs your entire. program is gonna spend time trying to fix bugs and it'll get nowhere and you will not be any better because the amount of new bugs surfacing is just infinitely larger than you could possibly handle. So that's a trap. Now that marketing blog post was all about like increasing usage of cloud does have some interesting idea. The one I like here is designed for a breach.

26:16 And the idea is like, just assume you're getting a breach, assume one of the vulnerabilities will get exploited. Then what? You should be resilient to that. And there's people who say like, how many zero days do I need for you to actually meaningfully get access and cause impactful damage? How many vulnerabilities should you exploit? It's about defense and depth and the way you architect your network, your app, everything should be like, if you pop one thing, then that's still very contained and I should be able to detect that and respond to it in a meaningful way that it's not disastrous.

26:47 Know what you have, have good asset inventory management and reduce what you expose. Also a reasonable recommendation. Shorten your incident response time, know how to respond, well, very good one to know. But I want to mention more on the whole CVE idea, just patching CVEs and everything on the known exploitable vulnerability list. If you look at this handy diagram of number of CVEs by Pope. It's increasing a lot and that's pre AI and it will continue increasing a lot.

27:22 And why does the number of CVEs increase? Well, it's not just that like software is more vulnerable. No, not necessarily. People were saying like, oh, the more viacoded apps we have, the more vulnerabilities we have. Like also not necessarily. I think it's just like, we just have more code. we probably have way more code. mean there was a very small amount of code in 1939. So it's just astronomically increase in the amount of code being shipped and written, but also increase in security tooling capabilities and accuracy and their ability to write, to find bugs, increase in the adoption of security tools, finding bugs and increase in the number of CVEs filed.

28:03 Like some people just never gave a shit. Like they would find the bug and they would just submit. a fix and that would be it. They wouldn't actually get a CV from it, right? Not everyone cared. Now there's more people trying to add CVs on their resumes and so there's like a huge increase in number of CVs filed for a bug. There's a bit more to it. So there's this really good blog post by James Berthouty friend of the channel and He mentions some changes on the national vulnerability database.

28:32 NVD, National Vulnerability Database, just recently basically announced that they're reducing the scope of which vulnerabilities will receive enrichment. Now that is impactful and I think kind of contradicts or reduces the, the, the relevancy of the recommendation we saw from, Anthropic, which is like fix everything. So they're paying more attention to CVEs used within the federal government or appearing in the KEV catalogue. And the idea is that enrichment is important because if I look at the CVE page and I don't have much information on it, then how can I triage to know if this is worth fixing or not?

29:12 How can I tell if this actually applies in my environment? the less details you give me, the harder it is for me to actually prioritize what I should be fixing. And so vulnerability enrichment is extremely valuable. And now, of all of the vulnerabilities published, a very small number just does get into the KEV catalog or receives more meaningful ratings. And the fact that they will focus on critical software or software used by the government means that That's now a misleading list.

29:44 Because as a small company, I don't necessarily use the software that the government uses. I don't necessarily use the same firewalls or appliances, network appliances that the government use. Like some of those can be like very expensive hardware. Many small companies don't use that. And they're more interested in other pieces of software. that are internet exposed in their environment. So then this actually separates, like, who's your audience? Is it like really large companies with critical infrastructure?

30:14 Then yes, maybe they'll continue making use of it. But what about most of the comp... I would say most companies don't host critical infrastructure. So most companies would need an alternative source of data enrichment for their vulnerabilities to know what to prioritize. So this creates a sort of bias here. So I understand that there is a challenge because the number of CVEs is growing a lot. And so how do they know what to put effort into enriching?

30:40 But it maybe just means we need more authoritative sources that work full-time on enriching vulnerability data. And here this point is interesting. There's going to be a continuing explosion in CVS in the area that is going to be evaluated with the least scrutiny and that is actually kind of a dangerous point. Now separately there is an interesting blog post by Mozilla where they used Mythos to find a number of bugs and this is a very interesting blog post.

31:08 So they had access to Claude Mythos preview and this week's release of Firefox 150 include fixes for 271 vulnerabilities identified during evaluation. Now this goes back to the idea of like, who did Anthropic pick to give access to Mythos preview and it's companies with a public facing profile that will be writing about this to create more marketing hype, right? But yeah, it found a bunch of bugs. We don't know if they're all exploitable, but probably a subset of them would have been.

31:40 And the idea is this is an increase from previous patches. It found way more than they traditionally find per release. And they do have a nice uplifting conclusion that like, oh, defenders now have a chance because with this tooling, with this improvement in basically bug finding tooling or sating analysis, then we actually have better ways of catching bugs that isn't behind offensive capabilities, which would be using the same tools largely.

32:11 And they say that basically this matches the level of like a good human researcher. Like basically there are no vulnerabilities that human can find that the model can't. And conversely, the bugs that it has found could have also been found by human researchers. So they're saying having this on your team is basically the same as having like a really good researcher as like looking at the code base. Fine. Okay. And so here's a bit of a spicy part.

32:37 They say some commentators predict that future AI models will unearth entirely new form of vulnerabilities that defy our current comprehension. But we don't think so. Software like Firefox is designed in a modular way for humans to be able to reason about its correctness. It is complex, but not arbitrarily complex. And that is the first interesting thought. And they say There is a risk that code bases begin to surpass human comprehension as a result of more AI in the development process, scaling bug complexity along with them.

33:08 And human comprehensibility is an essential property to maintain, especially in critical software like browser and operating system. And so I fully agree here. And I keep mentioning the Eames parable that Dino D'Azovio keeps bringing up is that like never delegate understanding. Like the proper way to use AI or any systems, like you need to have a solid understanding of the system and how it operates and never delegate it externally to something else, some other entity, because once you lose understanding of the system, everything collapses, your assumptions are wrong, you can't reason about it, right?

33:40 So this is a good property to hold for sure. Now, then they say something I don't agree with. The defects are finite and we are entering a world where we can finally find them all. Now, I do not agree with this at all. And there's this conversation. Some folks are saying that we can now find all possible vulnerabilities. so with this tooling, you can let it run and you can get to reach a state where you can surface every single possible finding and vulnerability in a code base until there are zero findings remaining, right?

34:20 Perfect security. I think that is absurd for many reasons. One is obviously not all findings are in the code base, right? There are findings on like how it's integrated in the system, how it's deployed. But let's set that aside. Looking at just the code itself and let's say we want to find all bugs in the code. I think... That's like saying I want to eliminate all possible misunderstanding in human communication. Right. And that is impossible because Communication and grammar is just inherently limited and flawed.

34:55 Like you cannot possibly perfectly transmit information in a way that's unambiguous to all possible recipients. And code is a form of communication in the very same way. And how are we maintaining assumptions? In your code, you're making assumptions about how your understanding of the system is and how it should operate. And there's also things outside of your control, like you're compiling the code. So the compiler now plays a role. There's logic bugs that keep surfacing.

35:28 Sometimes the spec is flawed in itself. And to me, you will never reach a point where you can look confidently, look at the code, saying like, yeah, we scanned the shit out of it. It's actually perfectly secure now. That to me is impossible. There's even systems that have been formally verified that end up being vulnerable to something. Now a few more notes to mention. One is there is this paper by the cloud security Alliance on the vulnerable, the AI apocalypse of mythos.

36:01 Fine. Whatever. has varying degrees of relevancy. First of all, there's a impressive list of extremely smart people here, obviously, but in my experience, the longer the list of contributors, the worse the paper. Like it doesn't mean anything if you have There's actually more reviewers here, like, hundreds of billions of people contributing to this. That doesn't mean anything to me. Like, these are all very smart people. Does that mean, like, the paper is, like, fully coherent? It's like, actually, that makes it harder to maintain coherence.

36:35 Now it is a little bit like apocalyptic verging towards everything is falling apart, but some of the interesting ideas that it mentions... It has these like interesting question set here that I kind of want to go through because I thought that's interesting. I thought many of us do get asked variations of these questions often. Or at least we should know this about ourselves. And so the first one is what is your actual stance on AI today?

37:06 it like allowed, tolerated, restricted? And so here, ideally, I think your sense is encouraged. because anything else is a losing battle, right? Like at this point, your engineers want to use it. Most of them do. There is demonstrable value in using it and anything other than encouraging its use, you will have a worse time later on. Now, obviously there are exceptions and like highly restricted environments where you would limit its use and the data that's going in it.

37:39 But generally, if you don't encourage it, then people will just find bypasses and use worse versions in a dangerous way. Now, can employees use Agenda Coding Tools in enterprise? Like, yeah, like usually you want to allow them, especially if they want to write like a lot of companies now use cloud coders similar and through API. Now, this is an interesting one. Can employees contribute to open source without legal ambiguity? there's only one correct answer, which is this is a legal and IP question, not a technology philosophical question.

38:08 This is a trap question. Anytime anyone asks you a question whether we're legal or it's like, have no clue, go talk to legal. Do not answer this. Never answer any questions similar to this. Now here's some interesting points. we have disciplined control repos, artifacts and software including for agentic supply chains such as MCP, servers, plugins and skills? The answer is no. nobody has, nobody can answer the question of like what MCPs and skills are running in your environment or in your developer's environment.

38:39 Nobody has any asset inventory for skills and MCP, right? So there are some ideas very vaguely of like just using something like Jamf to go and like you have a script that runs on employee laptops to like go and fetch a list of like files and skills that they may have installed, but none of this is gonna be comprehensive so far. There's like no real governance around this, which is why it's a good question to ask.

39:01 Is there a real cooling off point or security gate between code change and production? So enforcement of like release cycles and control of supply chain. This is an interesting idea, right? Like we've seen that like having like a cool down period before you actually update your dependencies has had like security benefits in case the dependency is compromised. Is security operational or primarily advisory? Like, it directly affect outcomes or does it mostly act as like review and escalation?

39:33 That's an interesting one in general, like as a security, like strategy and like you want to kind of be both in that like it has to be operational where you do have security controls in place. But you also want to serve as an advisory role because you can't always just tell developers what's best for them. You kind of want to listen to them, work with them and understand from their perspective. what challenges they're facing to find out how you can help them.

39:59 So I think you want to be both. What is the fastest this company has made the production driven or security driven production change in the last year? That's an interesting question, but I think it depends too much on the company and what the purpose of the security driven production change was. sometimes Comedies will have an incident and like magically now they have all the appetite to make a change very quickly. that's kind of just like a subjective question.

40:28 Are our critical crown jewels explicitly tracked and current? And current is a good question. So like, we know what our crown jewels are? Do we track them and do we continue updating that list? Very good thing to have. I mean, that applies to assets inventory in general, but specifically within that inventory, what are our highest priority items? Do we know how to get urgent work prioritized by our key third parties? Like who do we escalate to?

40:52 Sure, mean, fine question to know how to answer. Does executive leadership have a working definition of urgency? If everything is a crisis, nothing is urgent. And I think that's a good, executive leadership here, I mean, I don't. Like it also applies to security leadership, right? Like you can have bad security leaders if they think like everything's worth like, drop everything and go and like that now everything's getting dropped. Nothing's getting done. Right. And I have seen organizations like that.

41:20 Now then they list a few different things to prioritize like have an asset inventory and secure your software WPAT plan. They're all reasonable known things. I'll link this paper below if you want to look at it. Now, just to kind of summarize and digest all my thoughts in one place, a few things I want to mention first. Why would Anthropic have a marketing strategy based on fear, uncertainty and doubt? Well, they do have advantages to do that.

41:51 One is look at their list of partners. They are big firms with a very public footprint and big security budgets, which means that these are large firms that will have an investment and an incentive in finding bugs and they will find large amounts of bugs because they have a lot of code and Public attack for surface, large amount of bugs. This is the best marketing campaign you could possibly have by like having all these large companies, like as we saw with Microsoft, sorry, the Firefox blog post, just saying how they use mythos.

42:27 So this is really effective as a marketing campaign. The second thing is they want to buy more time. That's why it's not publicly yet because they've had infrastructure problems. mean, cloud Opus has been down multiple times in the last few weeks. And so The belief is that they're also giving themselves time to scale the infrastructure to handle increased demand. And the third part is, the government, it was considering Anthropic as supply chain risk, national security risk.

42:54 Now the government wants to work with Anthropic and wants to partner with them. And so it's about that relationship as well. Now the second part is like, are bugs important at all? As we said, it's a very small part of security, finding bugs in your own code and fixing known bugs is a small part. then addressing zero days is even smaller part for which many companies, if you focus on zero days before all of the rest, you're doomed.

43:18 Whatever you do, you will never get better. Right? You have to get the basics right first before, or instead of focusing on zero days. Otherwise, your security posture will never improve. And again, everyone has always had the ability to scale security by just investing more money. It's like you hit the cap at some point. There's only so much you can fix. There's only so much you want to have fixed. So the important thing is to prioritize and handle the basics right, have MFA, solve phishing first because that's most likely how you're gonna get popped, not through zero day.

43:52 And another interesting side note is the side effects of all of this FUD is that now it's just used as an excuse. There's been a few incidents, like the Vercell incident. which they were compromised because of an OAuth misconfiguration on the IT side, which was like a classic vulnerability, but they said, this is a highly sophisticated and AI accelerated attack. This is just bullshit. They're using AI as an excuse. They're leveraging the, the anthropic marketing campaign to be like, yeah, it's affecting us.

44:24 my God, it's not my fault. You can blame AI, right? Irrelevant. It's, it's, it's still their fault. Now back to the idea of finding bugs. So overall, We've always had different tools to use to find bugs. So initially, we had static analysis tool or static application security testing tools, SAST And you had traditional old school tools like Covarity or Fortify. And those had to basically wrap around the compiler if you're scanning a C code base.

44:57 were slow. They had a large set of false positives. Most importantly, you had to scan the entire project as a whole. Then you had some more interesting tools and more modern tools like Semgrep or CodeQL. And with Semgrep, was nicer because you can scan one file at a time, right? And you can have your own rules. You can just write your own rule sets. And that was a nice change because it was just more effective, more useful for one-off scans and you can tweak the rules on the fly.

45:30 And so that's been good, but whatever tool use, then you have to basically triage. So it will give you like 80,000 findings if you're scanning like a really large code base. Right now they're not all relevant. So you have to spend a significant amount of effort looking through all of the findings and figuring out like, well, do I actually care about this or not? And you don't care about all of them, right? And you can't send your developers 80,000 false positives.

45:58 They'll look at the first 10, they'll be like, this is all irrelevant, and they'll ignore you for the rest of their lives. So you triage, then you figure out reachability. Is this part of the code actually influenced by user input or not? Then you figure out exploitability. If it is reusable by user input, can the user craft the malicious payload so that they can exploit this vulnerability to gain like remote code execution or something, right? And then finally, you fix it if you find that it's worth fixing given all of the other prioritization.

46:31 Actually, there's one more step is the prioritization itself. Because you might have, as we saw before, one million different findings are exploitable and reachable and everything, right? Well, then what? And that's real question, like I have the findings, now what? And so prioritization, very important thing to do. Now this is the traditional workflow for Saast, which... worked, but many organizations, security orgs didn't do it properly because of the significant amount of effort involved in all of these steps.

47:05 And so in practice, people just onboard sneak or I don't like sneak because it's misused this way. They'll just onboarded. It's turned on and it generates in giant ass. Backlog of findings that nobody ever touches and he actually it says a lot It's yelling all the time at like different things right when everything is a finding nothing's a finding right so Many organizations didn't spend enough effort doing these parts now LLM pure LLM here means that You're saying like Claude, please find bugs in this code space, right?

47:44 Without specifying anything else. You open Cloud Code, find bugs, or you can run slash security dash review, which basically have their own scale or prompt to get it to find bugs. And is this effective? Yes, it's good. It's good. It's good. You can actually find bugs this way. I've been comparing this with running Semgrep, and it's good. It actually often it finds more than some grip does.

48:16 the key here is that you can automate the things that we mentioned like triage, reachability, analysis, exploitability, and prioritization. I'm going to put a question mark here because that is debatable because prioritization, you have to give it your own prioritization criteria and that criteria is actually part of the challenge, right? So, having someone come up with like, what actually do I care enough and how do I prioritize?

48:47 Like that actually is a challenge in itself, which Claude can't necessarily solve for you, but it could maybe help a bit. And so the advantage here is that it can... have a higher confidence rate because it can tune false positives out for you and determine which ones are explatable or not. Now the whole mythos discourse was around this form of static analysis, which is just like, hey, please find bugs.

49:19 Now we know that this is good, but one is as we've seen, it can be very expensive. So how can I get it to be more efficient? And there are some issues with like, for example, non-determinism, like every time you're on a scan with it, it can find different things or it can reason a bit differently. So how can we improve on that? So the next way of doing it slightly better is guiding or orchestration here via a harness or skills, et cetera.

49:54 So the idea is you're not just saying like, hey, Claude, just find bugs. You're telling it how to find bugs. And that... can have many advantages. One is, as we've seen, there's many skills. For example, Trail of Bits has released a number of skills or checklists of what to look for in First C++, for example. So here you can split it up by language, by things you care about. You can have specific guidelines for each code base that are tailored.

50:23 It kind of becomes similar to the idea of SEMGRAP rules of here's the things I want you to look for. And you can orchestrate it with the harness and that means you can run it in conjunction with semgrep with AST with like any sort of tooling you think might increase the accuracy and then feed that into the LLM and The benefits is you can save tokens So instead of like the the LLM going and relooking at the entire code base from scratch you can actually Offload some of the to non-LLM tools to just make it more efficient and cheaper to run the scans, then you can increase accuracy because you're tailoring each scan to the code base.

51:05 Potentially you can increase speed, but that's not actually necessary. Actually, you can end up being slower scans. mean, it's kind of up to you. You're doing the orchestration. Now I did start a project like that where I tried to have my own harness, which basically wraps around Claude, but adds a few steps like it runs like a version of open grep with a bunch of custom skills. it wasn't that good so far. Actually, I didn't really find any advantages over just running Claude with those skills, but I think eventually there are some, some cool things you can do like, like, like drawing a graph for each ability and, And you can just run a bunch of other tools to increase efficiency of how it runs.

51:49 So I think more folks are going to go down this path. But there is an even more accurate solution, which is using AI native static analysis tools. And so there are a bunch of vendors here that do this. like Corgea or Zero Path or Almanacs or I think Aikido has started doing a version of this as well the vendors I mean they don't really matter it's just the idea that like you're taking this Guided LLM thing and taking it to the next level where you're really building your own tool that combines basically how SimGrep functions and how LLMs triage the findings of it.

52:31 You're building your own ASP to walk through that and and that even increases that accuracy even more right and I think AI native sassed is Essentially the the the future of like how these things will do I mean Methos is good, but it's still just like a raw model, right? It's still a bit wild. It's still unguided It's still can can operate in its own way. Like how can we orchestrate it? How can we get it?

52:56 to behave in a more consistent manner and have more reproducible workflows where we can depend on it more. And just as a quick example, there's this blog post from 2024, which is in AI time, prehistoric times, or like, this is basically like the ancient here, glyphic scrolls, right? And it says how zero path works, but I mean, a lot of the AI native SAS works, SAS tools works, work in the same way. And it essentially says here, this is really the part that I like.

53:26 So you trigger the scan, it identifies the application. And so maybe it can look at like, what language is the code base in? Then it generates the abstract syntax tree and indexes it, which is something you need to like efficiently go through the entire code base and look at findings and do reachability analysis. Then enriches the graph with initial context of like, these are the functions and how they call each other. Then you actually discover the vulns Then you validate the vulns and verify them.

53:53 And here's where you determine like reachability, exploitability. And at the very last step, you generate a patch. And so this, mean, an LM by itself can try to do this, but which tools are, is it calling? Do you have the sufficient, it has to do tool calls to do some of that. It's not sufficient to just run grep on a code base. And so then it depends on what tools you have. And so when you do AI native SAS, you're bundling all of these steps and writing code to actually do these steps.

54:21 here's an example of an AST and you turn that into a graph, right? So these are like extra steps that more than just what an alum does and the idea is like you so you're not just running mythos you're running way more steps and you're actually instrumenting the whole process and I think that is the future, right? So overall like Yeah, this is normal like we've been doing static analysis. This is a better version of studying analysis and it will continue getting better over time.

54:49 And most importantly, just don't fall for the marketing hype and don't fall for the salespeople that are trying to sell you mythos ready solutions to the apocalypse because you're fine. Just focus on the basics. Enable 2FA, solve phishing, run static analysis, just continue doing, continue applying the basic principles of security before focusing on the hype.