[HN Gopher] Small models also found the vulnerabilities that Myt...
___________________________________________________________________
Small models also found the vulnerabilities that Mythos found
Author : dominicq
Score : 1225 points
Date : 2026-04-11 16:47 UTC (1 days ago)
(HTM) web link (aisle.com)
(TXT) w3m dump (aisle.com)
| epistasis wrote:
| > We took the specific vulnerabilities Anthropic showcases in
| their announcement, isolated the relevant code, and ran them
| through small, cheap, open-weights models. Those models recovered
| much of the same analysis. Eight out of eight models detected
| Mythos's flagship FreeBSD exploit, including one with only 3.6
| billion active parameters costing $0.11 per million tokens.
|
| Impressive, and very valuable work, but isolating the relevant
| code changes the situation so much that I'm not sure it's much of
| the same use case.
|
| Being able to dump an entire code base and have the model scan it
| is they type of situation where it opens up vulnerability scans
| to an entirely larger class of people.
| odie5533 wrote:
| Isn't the difference just harness then? I can write a harness
| that chunks code into individual functions or groups of
| functions and then feed it into a vulnerability analysis agent.
| jcims wrote:
| It's probably not the 'only' difference, because clearly the
| models are advancing in capability, but it's likely way more
| important than generally given credit for.
| elicash wrote:
| This is from the first of the caveats that they list:
|
| > Scoped context: Our tests gave models the vulnerable function
| directly, often with contextual hints (e.g., "consider
| wraparound behavior"). A real autonomous discovery pipeline
| starts from a full codebase with no hints. The models'
| performance here is an upper bound on what they'd achieve in a
| fully autonomous scan. That said, a well-designed scaffold
| naturally produces this kind of scoped context through its
| targeting and iterative prompting stages, which is exactly what
| both AISLE's and Anthropic's systems do.
|
| That's why their point is what the subheadline says, that the
| moat is the system, not the model.
|
| Everybody so far here seems to be misunderstanding the point
| they are making.
| wat10000 wrote:
| If that's the case, why didn't they do it that way?
| e12e wrote:
| Tunnel vision? If your model can handle big context, why
| divide into lesser problems to conquer - even if such
| splitting might be quite trivial and obvious?
|
| It's the difference of "achieve the goal", and "achieve the
| goal in this one particular way" (leverage large context).
| wat10000 wrote:
| I meant, if the claim here is that small models can
| accomplish the same things with good scaffolding, why
| didn't they demonstrate finding those problem with good
| scaffolding rather than directly pointing them at the
| problem?
| mattmanser wrote:
| They don't have to.
|
| Lot of people in this thread don't seem to be getting
| that.
|
| If another model can find the vulnerability if you point
| it at the right place, it would also find the
| vulnerability if you scanned each place individually.
|
| People are talking about false positives, but that also
| doesn't matter. Again, they're not thinking it through.
|
| False positives don't matter, as you can just
| automatically try and exploit the "exploit" and if it
| doesn't work, it's a false positive.
|
| Worse, we have no idea how Mythos actually worked, it
| could have done the process I've outlined above, "found"
| 1,000s of false positives and just got rid of them by
| checking them.
|
| The fundamental point is it doesn't matter how the cheap
| models identified the exploit, it's that they can
| identify the exploit.
|
| When it turns out the harness is just acting as a
| glorified for-each brute force, it's not the model being
| intelligent, it's simply the harness covering more
| ground. It's millions of monkeys bashing type-writers,
| not Shakespeare at one.
| LordDragonfang wrote:
| > If another model can find the vulnerability if you
| point it at the right place, it would also find the
| vulnerability if you scanned each place individually.
|
| They didn't just point it at the right place, they
| pointed it at the right place and _gave it hints_. That
| 's a huge difference, even for humans.
| wat10000 wrote:
| It's strange to see this constant "I could do that too, I
| just don't want to" response.
|
| Finding an important decades-old vulnerability in OpenBSD
| is extremely impressive. That's the sort of thing anyone
| would be proud to put on their resume. Small models are
| available for anyone to use. Scaffolding isn't that hard
| to build. So why didn't someone use this technique to
| find this vulnerability and make some headlines before
| Anthropic did? Either this technique with small models
| doesn't actually work, or it does work but nobody's out
| there trying it for some reason. I find the second
| possibility a lot less plausible than the first.
| cycomanic wrote:
| From the article: >At AISLE, we've been running a
| discovery and remediation system against live targets
| since mid-2025: 15 CVEs in OpenSSL (including 12 out of
| 12 in a single security release, with bugs dating back
| 25+ years and a CVSS 9.8 Critical), 5 CVEs in curl, over
| 180 externally validated CVEs across 30+ projects
| spanning deep infrastructure, cryptography, middleware,
| and the application layer.
|
| They have been doing it (and likely others as well), but
| they are not anthropic which a million dollar marketing
| budget and a trillion dollar hype behind it, so you just
| didn't hear about it.
| roywiggins wrote:
| They could have linked their replication in this blog
| post, which we did all see, if they have one.
| mattmanser wrote:
| Why are you EXTREMELY impressed? The level of hysteria
| and lack of objective thought by pro-AI people on this
| thread is extremely concerning.
|
| Vulnerabilities are found every day. More will be found.
|
| They claim they spent $20k finding one, probably more
| like $20 million if you actually dug into it.
|
| And if you took into account inference, more like $2
| billion.
|
| The reason why no-one's done it is because it's not worth
| the money in tokens to do so.
| anotheryou wrote:
| huh, running it over each function in theory but testing just
| the specific ones here makes sense, but that hint?!
| elicash wrote:
| I agree.
|
| To clarify, I don't necessarily agree with the post or
| their approach. I just thought folks were misreading it. I
| also think it adds something useful to the conversation.
| TacticalCoder wrote:
| > That's why their point is what the subheadline says, that
| the moat is the system, not the model.
|
| Can you expand a bit more on this? What is the system then in
| this case? And how was that model created? By AI? By humans?
| SCHiM wrote:
| You can imagine a pipeline that looks at individual source
| files or functions. And first "extracts" what is going on.
| You ask the model:
|
| - "Is the code doing arithmetic in this file/function?" -
| "Is the code allocating and freeing memory in this
| file/function?" - "Is the code the code doing X/Y/Z? etc
| etc"
|
| For each question, you design the follow-up vulnerability
| searchers.
|
| For a function you see doing arithmetic, you ask:
|
| - "Does this code look like integer overflow could take
| place?",
|
| For memory:
|
| - "Do all the pointers end up being freed?" _or_ - "Do all
| pointers only get freed once?"
|
| I think that's the harness part in terms of generating the
| "bug reports". From there on, you'll need a bunch of tools
| for the model to interact with the code. I'd imagine you'll
| want to build a harness/template for the file/code/function
| to be loaded into, and executed under ASAN.
|
| If you have an agent that thinks it found a bug: "Yes file
| xyz looks like it could have integer overflow in function
| abc at line 123, because...", you force another agent to
| load it in the harness under ASAN and call it. If ASAN
| reports a bug, great, you can move the bug to the next
| stage, some sort of taint analysis or reach-ability
| analysis.
|
| So at this point you're running a pipeline to: 1) Extract
| "what this code does" at the file, function or even line
| level. 2) Put code you suspect of being vulnerable in a
| harness to verify agent output. 3) Put code you confirmed
| is vulnerable into a queue to perform taint analysis on, to
| see if it can be reached by attackers.
|
| Traditionally, I guess a fuzzer approached this from 3 ->
| 2, and there was no "stage 1". Because LLMs "understand"
| code, you can invert this system, and work if up from
| "understanding", i.e. approach it from the other side. You
| ask, given this code, is there a bug, and if so can we
| reach it?, instead of asking: given this public interface
| and a bunch of data we can stuff in it, does something
| happen we consider exploitable?
| ang_cire wrote:
| That's funny, this is how I've been doing security
| testing in my code for a while now, minus the 'taint
| analysis'. Who knew I was ahead of the game. :P
|
| In all seriousness though, it scares me that a lot of
| security-focused people seemingly haven't learned how
| LLMs work best for this stuff already.
|
| You should always be breaking your code down into
| testable chunks, with sets of directions about how to
| chunk them and what to do with those chunks. Anyone just
| vaguely gesturing at their entire repo going, "find the
| security vulns" is not a serious dev/tester; we wouldn't
| accept that approach in manual secure coding processes/
| SSDLCs.
| decidu0us9034 wrote:
| In a large codebase there will still be bugs in how these
| components interoperate with each other, bugs involving
| complex chaining of api logic or a temporal element.
| These are the kind of bugs fuzzers generally struggle at
| finding. I would be a little freaked out if LLMs started
| to get good at finding these. Everything I've seen so far
| seems similar to fuzzer finds.
| decidu0us9034 wrote:
| I think there is already papers and presentations on
| integrating these kind of iterative code
| understanding/verificaiton loops in harnesses. There may
| be some advantages over fuzzing alone. But I think the
| cost-benefit analysis is a lot more mixed/complex than
| anthropic would like people to believe. Sure you need
| human engineers but it's not like insurmountably hard for
| a non-expert to figure out
| tehryanx wrote:
| I get what you're saying, but I think this is still missing
| something pretty critical.
|
| The smaller models can recognize the bug when they're looking
| right at it, that seems to be verified. And with AISLE's
| approach you can iteratively feed the models one segment at a
| time cheaply. But if a bug spans multiple segments, the small
| model doesn't have the breadth of context to understand those
| segments in composite.
|
| The advantage of the larger model is that it can retain more
| context and potentially find bugs that require more code
| context than one segment at a time.
|
| That said, the bugs showcased in the mythos paper all seemed
| to be shallow bugs that start and end in a single input
| segment, which is why AISLE was able to find them. But having
| more context in the window theoretically puts less shallow
| bugs within range for the model.
|
| I think the point they are making, that the model doesn't
| matter as much as the harness, stands for shallow bugs but
| not for vulnerability discovery in general.
| cyanydeez wrote:
| OK, consider a for loop that goes through your repo, then
| goes through each file, and then goes through each common
| vulnerability...
|
| Is Mythos some how more powerful than just a recursive
| foreloop aka, "agentic" review. You can run `open code run
| --command` with a tailored command for whatever
| vulnerabilities you're looking for.
| tehryanx wrote:
| newer models have larger context windows, and more stable
| reasoning across larger context windows.
|
| If you point your model directly at the thing you want it
| to assess, and it doesn't have to gather any additional
| context you're not really testing those things at all.
|
| Say you point kimi and opus at some code and give them an
| agentic looping harness with code review tools. They're
| going to start digging into the code gathering context by
| mapping out references and following leads.
|
| If the bug is really shallow, the model is going to get
| everything it needs to find it right away, neither of
| them will have any advantage.
|
| If the bug is deeper, requires a lot more code context,
| Opus is going to be able to hold onto a lot more
| information, and it's going to be a lot better at
| reasoning across all that information. That's a test that
| would actually compare the models directly.
|
| Mythos is just a bigger model with a larger context
| window and, presumably, better prioritization and
| stronger attention mechanisms.
| cyanydeez wrote:
| Harnesses are basically doing this better than just
| adding more context. Every time, REGARDLESS OF MODEL
| SIZE, you add context, you are increasing the odds the
| model will get confused about any set of thoughts. So
| context size is no longer some magic you just sprinkle on
| these things and they suddenly dont imagine things.
|
| So, it's the old ML join: It's just a bunch of if
| statements. As others are pointing out, it's quite
| probably that the model isn't the thing doing the heavy
| lifting, it's the harness feeding the context. Which this
| link shows that small models are just as capabable.
|
| Which means: Given a appropiately informed senior
| programmer and a day or two, I posit this is nothing more
| spectacular than a for loop invoking a smaller, free,
| local, LLM to find the same issues. It doesn't matter
| what you think about the complexity, because the
| "agentic" format can create a DAG that will be followable
| by a small model. All that context you're taking in makes
| oneshot inspections more probable, but much like how CPUs
| have go from 0-5 ghz, then stalled, so too has the
| context value.
|
| Agent loops are going to do much the same with small
| models, mostly from the context poisoning that happens
| every time you add a token it raises the chance of false
| positives.
| tehryanx wrote:
| I know you're right that there's a saturation point for
| context size, but it's not just context size that the
| larger models have, it's better grounding within that as
| a result of stronger, more discriminative attention
| patterns.
|
| I'm not saying you're not going to drive confusion by
| overloading context, but the number of tokens required to
| trigger that failure mode in opus is going to be a lot
| higher than the number for gpt-oss-20b.
|
| I'm pretty sure a model that can run on a cellphone is
| going to cap out it's context window long before opus or
| mythos would hit the point of diminishing returns on
| context overload. I think using a lower quality model
| with far fewer / noisier weights and less precise
| attention is going to drive false positives way before
| adding context to a SOTA model will.
|
| You can even see here, AISLE had to print a retraction
| because someone checked their work and found that just
| pointing gpt-oss-20b at the patched version generated FP
| consistently:
| https://x.com/ChaseBrowe32432/status/2041953028027379806
| pertymcpert wrote:
| Yeah...except Mythos's large context perf seems to be
| much better than Opus 4.6.
| lelanthran wrote:
| > That's why their point is what the subheadline says, that
| the moat is the system, not the model.
|
| I'm skeptical; they provided a tiny piece of code and a hint
| to the possible problem, and their system found the bug using
| a small model.
|
| That is hardly useful, is it? In order to get the same result
| , they had to know both where the bug is and what the bug is.
|
| All these companies in the business of "reselling tokens, but
| with a markup" aren't going to last long. The only strategy
| is "get bought out and cash out before the bubble pops".
| epistasis wrote:
| If that's the point they are making, let's see their false
| positive rate that it produces on the entire codebase.
|
| They measured false negatives on a handful of cases, but that
| is not enough to hint at the system you suggest. And based on
| my experiences with $$$ focused eval products that you can
| buy right now, e.g. greptile, the false positive rate will be
| so high that it won't be useful to do full codebase scans
| this way.
| zelphirkalt wrote:
| How do we know the false positives for this "Mythos"
| thingamabob? Since they didn't release it, and we cannot
| reproduce it, are we to simply believe their word on this?
| What if the author of the featured article simply made a
| claim about that? We also simply believe their word? To me
| these AI tech companies are not any more trustworthy than a
| random blog author, maybe even less so, due to all the
| shady stuff they are pulling and especially since they have
| not released. Show or it didn't happen.
| LordDragonfang wrote:
| > That said, a well-designed scaffold naturally produces this
| kind of scoped context through its targeting and iterative
| prompting stages, which is exactly what both AISLE's and
| Anthropic's systems do.
|
| Unless the context they added to get the small model to find
| it was generated fully by their own scaffold (which I assume
| it was not, since they'd have bragged about it if it was),
| either they're admitting theirs _isn 't_ well designed, or
| they're outright lying.
|
| People aren't missing the point, they're saying the point is
| dishonest.
| scotty79 wrote:
| > Scoped context: Our tests gave models the vulnerable
| function directly, often with contextual hints (e.g.,
| "consider wraparound behavior").
|
| To be fair, nothing stops anyone from feeding each function
| of given codebase separately with one out of the predefined
| set of hints.
|
| It's just AST and a for loop. Calling it a system is a bit
| much.
| loire280 wrote:
| > Anthropic's own scaffold is described in their technical
| post: launch a container, prompt the model to scan files, let
| it hypothesize and test, use ASan as a crash oracle, rank files
| by attack surface, run validation. That is very close to the
| kind of system we and others in the field have built, and we've
| demonstrated it with multiple model families, achieving our
| best results with models that are not Anthropic's. The value
| lies in the targeting, the iterative deepening, the validation,
| the triage, the maintainer trust. The public evidence so far
| does not suggest that these workflows must be coupled to one
| specific frontier model.
|
| The argument in the article is that the framework to run and
| analyze the software being tested is doing most of the work in
| Anthropic's experiment, and that you can get similar results
| from other models when used in the same way.
| roywiggins wrote:
| Maybe that's true, but they didn't actually show that that's
| true, since they didn't try scaffolding smaller models in a
| similar way at all.
| Jcampuzano2 wrote:
| The thing is with smaller cheaper models it is very possible to
| simply take every file in a codebase, and prompt it asking for
| it to find vulnerabilities.
|
| You could even isolate it down to every function and create a
| harness that provides it a chain of where and how the function
| is used and repeat this for every single function in a
| codebase.
|
| For some very large codebases this would be unreasonable, but
| many of the companies making these larger models do
| realistically have the compute available to run a model on
| every single function in most codebases.
|
| You have the harness run this many times per file/function, and
| then find ones that are consistently/on average pointed as as
| possible vulnerability vectors, and then pass those on to a
| larger model to inspect deeper and repeat.
|
| Most of the work here wouldn't be the model, it'd be the
| harness which is part of what the article alludes to.
| loeg wrote:
| > it is very possible to simply take every file in a
| codebase, and prompt it asking for it to find
| vulnerabilities.
|
| My understanding (based on the Security, Cryptography,
| Whatever podcast interview[0] -- which, by the way, go listen
| to it) is that this is actually what Anthropic did with the
| large model for these findings.
|
| [0]: https://securitycryptographywhatever.com/2026/03/25/ai-
| bug-f...
|
| > I wrote a single prompt, which was the same for all of the
| content management systems, which is, I would like you to
| audit the security of this codebase. This is a CMS. You have
| complete access to this Docker container. It is running.
| Please find a bug. And then I might give a hint. "Please look
| at this file." And I'll give different files each time I
| invoke it in order to inject some randomness, right? Because
| the model is gonna do roughly the same time each time you run
| it. And so if I want to have it be really thorough, instead
| of just running 100 times on the same project, I'll run it
| 100 times, but each time say, "Oh, look at this login file,
| look at this other thing." And just enumerate every file in
| the project basically.
| roywiggins wrote:
| "small models can do this if you scaffold them right" might
| be true, but it wasn't actually demonstrated in the post.
| MaxLeiter wrote:
| I think they key thing here is they "isolated the relevant code"
|
| If the exploits exist in e.g. one file, great. But many complex
| zerodays and exploits are chains of various bugs/behaviors in
| complex systems.
|
| Important research but I don't think it dispels anything about
| Mythos
| slopinthebag wrote:
| Did Mythos identify vulnerabilities across files? Afaik Mythos
| worked the same way, analysing a single file at a time.
| davebren wrote:
| Seems perfectly comparable to anthropic's method, they just
| wrapped the same kind of prompt in a for loop.
| JackYoustra wrote:
| > Isolated the relevant code
|
| I mean isn't that most of it? If you put a snippet of code in
| front of me and said "there's probably a vulnerability here" I
| could probably spend a few hours (a much lower METR time!) and
| find it. It's a whole other ballgame to ask me with no context to
| come up with an exploit.
| kennywinker wrote:
| Sure. But it's a computer. You can run "there's probably a
| vulnerability here" as many times as you like. And it's easier
| and cheaper to run it many times with a small open model than a
| big frontier model.
|
| It also sounds like that is how mythos works too. Which makes
| sense - the linux kernel is too big to fit in context
| JackYoustra wrote:
| No, it sounds like mythos is just doing parallel
| trajectories. that's pretty distinct!
| amazingamazing wrote:
| Did mythos isolate the code to begin with? Without a clear
| methodology that can be attempted with another model the whole
| thing is meaningless
| aniceperson wrote:
| to be fair, last post i saw from anthropic on finding linux
| kernel vulnerability was a while loop per failed prompting
| "there is a vulnerability here, find it" more important than
| that, no frontier model can keep the entire linux kernel in
| context, so there definitely is code isolation, either
| explicitly or implicitly (the model itself delegates subagents
| with smaller chunks of code)
| loeg wrote:
| No. How would it? Before the vulns were identified by Mythos,
| no one knew what the relevant portion to isolate was.
| bhouston wrote:
| They did do one agent per code chunk, yes. But key is that
| their agent had to identify when there was a vulnerability and
| when there wasn't. This "small model" test only had to label
| the known positive cases as positive -- which any function that
| simply returns "true" can do. This whole test setup is annoying
| because it proves nothing.
| dist-epoch wrote:
| Anthropic claim is not necessarily that Mythos found
| vulnerabilities that other models couldn't but that it could
| easily exploit them while previous models failed to do that:
|
| > "Opus 4.6 is currently far better at identifying and fixing
| vulnerabilities than at exploiting them." Our internal
| evaluations showed that Opus 4.6 generally had a near-0% success
| rate at autonomous exploit development. But Mythos Preview is in
| a different league. For example, Opus 4.6 turned the
| vulnerabilities it had found in Mozilla's Firefox 147 JavaScript
| engine--all patched in Firefox 148--into JavaScript shell
| exploits only two times out of several hundred attempts. We re-
| ran this experiment as a benchmark for Mythos Preview, which
| developed working exploits 181 times, and achieved register
| control on 29 more.
| rychu wrote:
| If that was normal Opus, then it sounds to me like Mythos could
| be a big model, instruction tuned, but without all the
| safety/refusal part of training.
| chirau wrote:
| Their isolation approach is totally different from Mythos
| approach though. Mythos had to evaluate whole code bases rather
| than isolated sections. It's like saying one dog walked into the
| Amazon jungle and found a tennis ball and then another team
| isolated a 1 square kilometer radius that they knew the ball was
| definitely in and found the same ball.
| kennywinker wrote:
| I don't think mythos can ingest an entire codebase into
| context. So it's spinning off sub-agents to process chunks.
| Which supports their thesis: the harness is the moat. The
| tooling is whats important, the model is far far less
| important.
| bhouston wrote:
| Mythos was clear it was one agent per chunk. But this
| positive confirming results do not actually disprove anytime
| with Mythos, because it is only one side of the discriminator
| challenge - you got positives, but we do not know your false
| positive rate and your false negative rate.
| kennywinker wrote:
| In TFA they talk a fair bit about how different models
| perform wrt false positives:
|
| "The results show something close to inverse scaling:
| small, cheap models outperform large frontier ones."
| mofeien wrote:
| These results were based on "a trivial snippet from the
| OWASP benchmark". In the section "caveats and
| limitations" they state that sonnet 4.6 and opus 4.6 now
| pass.
|
| And they decided to base the false positive examination
| on a single snippet of a publicly known benchmark
| question (that small models are known to be heavily fine
| tuned for) instead of the real use case of finding actual
| vulnerabilities across an entire codebase by using a for
| loop and checking the false positive rate there.
|
| This is disingenuous at best, or even misleading by
| omission if the second approach _was_ done but not
| mentioned because it just confirmed that the false
| positive rate of small models is enormous. Given how all
| seven small models identified the FreeBSD Bug when
| pointed to it, and how how 6/7 small models still
| identified the "bug" even after the patch was applied,
| that second outcome seems likely...
| eiens wrote:
| Let's suppose that's true
|
| What's so special about the harness - why wouldn't others be
| able to replicate it?
| hakanderyal wrote:
| Even that would be more meaningful test. They basically coated
| the ball with a strong smell, then they prepped the dog with
| that smell, then set it loose in a 5x5 meter area.
|
| "Our tests gave models the vulnerable function directly, often
| with contextual hints (e.g., "consider wraparound behavior")."
| johnfn wrote:
| The Anthropic writeup addresses this explicitly:
|
| > This was the most critical vulnerability we discovered in
| OpenBSD with Mythos Preview after a thousand runs through our
| scaffold. Across a thousand runs through our scaffold, the total
| cost was under $20,000 and found several dozen more findings.
| While the specific run that found the bug above cost under $50,
| that number only makes sense with full hindsight. Like any search
| process, we can't know in advance which run will succeed.
|
| Mythos scoured the entire continent for gold and found some. For
| these small models, the authors pointed at a particular acre of
| land and said "any gold there? eh? eh?" while waggling their
| eyebrows suggestively.
|
| For a true apples-to-apples comparison, let's see it sweep the
| entire FreeBSD codebase. I hypothesize it will find the exploit,
| but it will also turn up so much irrelevant nonsense that it
| won't matter.
| SoftTalker wrote:
| How much of that is simply scale? Anthropic threw probably an
| entire data center at analyzing a code base. Has anyone done
| the same with a "small" model?
| jstanley wrote:
| It's still useful if $20k of consultants would be less
| effective.
| hellcow wrote:
| It seems feasible to use a small/cheap model to flag possible
| vulnerabilities, and then use a more expensive model to do a
| second-pass to confirm those, rather than on every file. Could
| dramatically reduce the total cost and speed up the process.
| conception wrote:
| Does it? I don't see quality from small models being high
| enough to be able to effectively scour a code based like
| this.
| notnullorvoid wrote:
| > I hypothesize it will find the exploit, but it will also turn
| up so much irrelevant nonsense that it won't matter.
|
| The trick with Mythos wasn't that it didn't hallucinate
| nonsense vulnerabilities, it absolutely did. It was able to
| verify some were real though by testing them.
|
| The question is if smaller models can verify and test the
| vulnerabilities too, and can it be done cheaper than these
| Mythos experiments.
| iririririr wrote:
| so it's just better at hallucinations, but they added
| discrete code that works as a fuzzer/verifier?
| bredren wrote:
| The article positions the smaller models as capable under
| expert orchestration, which to be any kind of comparable must
| include validation.
| Aurornis wrote:
| Calling it "expert orchestration" is misleading when they
| were pointing it at the vulnerable functions and giving it
| hints about what to look for because they already knew the
| vulnerability.
| cyanydeez wrote:
| You know for loops exist and you can run opencode against
| any section of code with just a small amount of
| templating, right? There's zero stopping you from writing
| a harness that does what you're saying.
| hibikir wrote:
| People often undervalue scaffolding. I was looking at a bug
| yesterday, reported by a tester. He has access to Opus, but
| he's looking through a single repo, and Amazon Q. It provided
| some useful information, but the scaffolding wasn't good
| enough.
|
| I took its preliminary findings into Claude Code with the
| same model. But in mine it knows where every adjacent system
| is, the entire git history, deployment history, and state of
| the feature flags. So instead of pointing at a vague problem,
| it knew which flag had been flipped in a different service,
| see how it changed behavior, and how, if the flag was flipped
| in prod, it'd make the service under testing cry, and which
| code change to make to make sure it works both ways.
|
| It's not as if a modern Opus is a small model: Just a
| stronger scaffold, along with more CLI tools available in the
| context.
|
| The issue here in the security testing is to know exactly
| what was visible, and how much it failed, because it makes a
| huge difference. A middling chess player can find amazing
| combinations at a good speed when playing puzzle rush: You
| are handed a position where you know a decisive combination
| exist, and that it works. The same combination, however,
| might be really hard to find over the board, because in a
| typical chess game, it's rare for those combinations to
| exist, and the energy needed to thoroughly check for them,
| and calculate all the way through every possible thing. This
| is why chess grandmasters would consider just being able to
| see the computer score for a position to be massive cheating:
| Just knowing when the last move was a blunder would be a
| decisive advantage.
|
| When we ask a cheap model to look for a vulnerability with
| the right context to actually find it, we are already priming
| it, vs asking to find one when there's nothing.
| celeritascelery wrote:
| That was my thought exactly. If small models can find these
| same vulnerabilities, and your company is trying to find
| vulnerabilities, why didn't you find them?
| rakejake wrote:
| Maybe they did use small models but you couldn't make the
| front page of HN with something like this until Anthropic
| made a big fuss out of it. Or perhaps it is just a question
| of compute. Not everyone has 20k$ or the GPU arsenal to task
| models to find vulnerabilities which may/may not be correct?
|
| Unless Anthropic makes it known exactly what model +
| harness/scaffolding + prompt + other engineering they did,
| these comparisons are pointless. Given the AI labs' general
| rate of doomsday predictions, who really knows?
| replygirl wrote:
| papers are always coming out saying smaller models can do
| these amazing and terrifying things if you give them highly
| constrained problems and tailored instructions to bias them
| toward a known solution. most of these don't make the front
| page because people are rightfully unimpressed
| echelon wrote:
| Who is spending millions of dollars on small models to find
| vulns? Nobody else is selling here or has the budget to sell
| quite like this.
|
| Anthropic spends millions - maybe significantly more.
|
| Then when they know where they are, they spend $20k to show
| how effective it is in a patch of land.
|
| They engineered this "discovery".
|
| What the small teams are doing is fair - it's just a scaled
| down version of what Anthropic already did.
| paulddraper wrote:
| > What the small teams are doing is fair - it's just a
| scaled down version of what Anthropic already did.
|
| Do they find novel items? Or do they copy the areas already
| found by others?
| petters wrote:
| They have found a large number in OpenSSl
| jerf wrote:
| I speculatively fired Claude Opus 4.6 at some code I knew
| very well yesterday as I was pondering the question. This
| code has been professionally reviewed about a year ago and
| came up fairly clean, with just a minor issue in it.
|
| Opus "found" 8 issues. Two of them looked like they were
| probably realistic but not really that big a deal in the
| context it operates in. It labelled one of them as minor, but
| the other as major, and I'm pretty sure it's wrong about it
| being "major" even if is correct. Four of them I'm quite
| confident were just wrong. 2 of them would require
| substantial further investigation to verify whether or not
| they were right or wrong. I think they're wrong, but I admit
| I couldn't prove it on the spot.
|
| It tried to provide exploit code for some of them, none of
| the exploits would have worked without some substantial
| additional work, even if what they were exploits for was
| correct.
|
| In practice, this isn't a huge change from the status quo.
| There's all kinds of ways to get lots of "things that may be
| vulnerabilities". The assessment is a bigger bottleneck than
| the suspicions. AI providing "things that may be an issue" is
| not useless by any means but it doesn't necessarily create a
| phase change in the situation.
|
| An AI that could automatically do all that, write the
| exploits, and then successfully _test_ the exploits, refine
| them, and turn the whole process into basically "push
| button, get exploit" is a total phase change in the industry.
| If it in fact can do that. However based on the current
| state-of-the-art in the AI world I don't find it very hard to
| believe.
|
| It is a frequent talking point that "security by obscurity"
| isn't really security, but in reality, yeah, it really is. An
| unknown but presumably staggering number of security bugs of
| every shape and size are out there in the world, protected
| solely by the fact that no human attacker has time to look at
| the code. And this has _worked_ up until this point, because
| the attackers have been bottlenecked on their own attention
| time. It 's kind of just been "something everyone knows" that
| any nation-state level actor could get into pretty much
| anything they wanted if they just tried hard enough, but
| "nation-state level" actor attention, despite how much is
| spent on it, has been quite limited relative to the torrent
| of software coming out in the world.
|
| Unblocking the attackers by letting them simply purchase
| "nation-state level actor"-levels of attention in bulk is
| _huge_. For what such money gets them, it 's cheap already
| today and if tokens were to, say, get an order of magnitude
| cheaper, it would be effectively negligible for a lot of
| organizations.
|
| In the long run this will probably lead to much more secure
| software. The transition period from this world to that is
| going to be _total chaos_.
|
| ... again, assuming their assessment of its capabilities is
| accurate. I haven 't used it. I can't attest to that. But if
| it's even half as good as what they say, yes, it's a _huge
| huge huge_ deal and anyone who is even remotely worried about
| security needs to pay attention.
| alpha_squared wrote:
| This is addressed elsewhere in the comments, but it appears
| this is actually a direct comparison to how Anthropic got their
| Mythos headline results.
|
| https://news.ycombinator.com/item?id=47732322
| Aurornis wrote:
| How is that a direct comparison? The link you gave has a
| quote that says it's not:
|
| > Scoped context: Our tests gave models the vulnerable
| function directly, often with contextual hints (e.g.,
| "consider wraparound behavior"). A real autonomous discovery
| pipeline starts from a full codebase with no hints
|
| They pointed the models at the known vulnerable functions and
| gave them a hint. The hint part is what really breaks this
| comparison because they were basically giving the model the
| answer.
| cyanydeez wrote:
| Does no one defending mythos understand how nested
| foreloops work?
|
| loop through each repo: loop through each file: opencode
| command /find_wraparoundvulnerability next file next repo
|
| I can run this on my local LLM and sure, I gotta wait some
| time for it to complete, but I see zero distinguishing
| facts here.
| u_fucking_dork wrote:
| Please do so, looking forward to your write up
| Dylan16807 wrote:
| The question is how customized those hints were. That
| changes whether looping over an entire code base is
| possible or not.
| johnfn wrote:
| No one is saying your nested for loop idea because it
| won't actually work in practice. In short, the signal to
| noise ratio will be too high - you will need to comb
| through a ton of false positives in order to find
| anything valuable, at which point it stops looking like
| "automated security research" and it starts looking like
| "normal security research".
|
| If you don't believe me, you should try it yourself, it's
| only a couple of dollars. Hey, maybe you're right, and
| you can prove us all wrong. But I'd bet you on great odds
| that you're not.
| yorwba wrote:
| When people criticize Aisle's methodology, they aren't
| "defending Mythos," they're bashing Aisle for their
| disingenuous claims.
| fulafel wrote:
| Aisle said they pointed it at the function, not the file.
| So, the nr of LLM turns would be something like nr of
| functions * nr of possible hints * nr of repos.
|
| Could indeed be a useful exercise to benchmark the cost.
|
| This would still be more limied, since many
| vulnerabilities are apparent only when you consider more
| context than one function to discover the vulnerability.
| I think there were those kinds of vulnerabilities in the
| published materials. So maybe the Aisle case is also
| picking the low hanging fruit in this respect.
| yorwba wrote:
| We don't even need to hypothesize that much on the irrelevant
| nonsense, since they helpfully provide data with the detected
| vulnerability patched: https://aisle.com/blog/ai-cybersecurity-
| after-mythos-the-jag... and half of the small models they
| touted as finding the vulnerability still found it in the
| patched code in 3/3 runs. A model that finds a vulnerability
| 100% of the time even when there is none is just as informative
| as a model that finds a vulnerability 0% of the time even when
| there is one. You could replace it with a rock that has
| "There's a vulnerability somewhere." engraved on it.
|
| They're a company selling a system for detecting
| vulnerabilities reliant on models trained by others, so they're
| strongly incentivized to claim that the moat is in the system,
| not the model, and this post really puts the thumb on the
| scale. They set up a test that can hardly distinguish between
| models (just three runs, really??) unless some are completely
| broken or work perfectly, the test indeed suggests that some
| are completely broken, and then they try to spin it as a win
| anyway!
|
| A high false-positive rate isn't necessarily an issue if you
| can produce a working PoC to demonstrate the true positives,
| where they kinda-sorta admit that you might need a stronger
| model for this (a.k.a. what they can't provide to their
| customers).
|
| Overall I rate Aisle intellectually dishonest hypemongers
| talking their own book.
| kilpikaarna wrote:
| Wasn't the scaffolding for the Mythos run basically a line of
| bash that loops through every file of the codebase and prompts
| the model to find vulnerabilities in it? That sounds pretty
| close to "any gold there?" to me, only automated.
|
| Have Anthropic actually said anything about the amount of false
| positives Mythos turned up?
|
| FWIW, I saw some talk on Xitter (so grain of salt) about people
| replicating their result with other (public) SotA models, but
| each turned up only a subset of the ones Mythos found. I'd say
| that sounds plausible from the perspective of Mythos being an
| incremental (though an unusually large increment perhaps)
| improvement over previous models, but one that also brings with
| it a correspondingly significant increase in complexity.
|
| So the angle they choose to use for presenting it and the
| subsequent buzz is at least part hype -- saying "it's too
| powerful to release publicly" sounds a lot cooler than "it
| costs $20000 to run over your codebase, so we're going to offer
| this directly to enterprise customers (and a few token open
| source projects for marketing)". Keep in mind that the examples
| in Nicholas Carlini's presentation were using Opus, so security
| is clearly something they've been working on for a while (as
| they should, because it's a huge risk). They didn't just
| suddenly find themselves having accidentally created a super
| hacker.
| johnfn wrote:
| > Wasn't the scaffolding for the Mythos run basically a line
| of bash that loops through every file of the codebase and
| prompts the model to find vulnerabilities in it? That sounds
| pretty close to "any gold there?" to me, only automated.
|
| But the entire value is that it _can_ be automated. If you
| try to automate a small model to look for vulnerabilities
| over 10,000 files, it 's going to say there are 9,500 vulns.
| Or none. Both are worthless without human intervention.
|
| I definitely breathed a sigh of relief when I read it was
| $20,000 to find these vulnerabilities with Mythos. But I also
| don't think it's hype. $20,000 is, optimistically, a tenth
| the price of a security researcher, and that shift does
| change the calculus of how we should think about security
| vulnerabilities.
| amazingamazing wrote:
| Citation needed for basically all of this. You basically
| are creating a double standard for small models vs
| mythos...
| johnfn wrote:
| The citation is the Anthropic writeup.
| amazingamazing wrote:
| They did not say what you are saying...
|
| > If you try to automate a small model to look for
| vulnerabilities over 10,000 files, it's going to say
| there are 9,500 vulns.
| johnfn wrote:
| What I am saying is that the approach the Anthropic
| writeup took and the approach Aisle took are very
| different. The Aisle approach is vastly easier on the
| LLM. I don't think I need a citation for that. You can
| just read both writeups.
|
| The "9500" quote is my conjecture of what might happen if
| they fix their approach, but the burden of proof is
| definitely not on me to actually fix their writeup and
| spend a bunch of money to run a new eval! They are the
| ones making a claim on shaky ground, not me.
| cycomanic wrote:
| So you can't imagine anything between bruteforce scan the
| whole codebase and cut everything up in small chunks and
| scan only those?
|
| You don't think that security companies (and likely these
| guys as well) develop systems for doing this stuff?
|
| I'm not a security researcher and I can imagine a harness
| that first scans the codebase and describes the API, then
| another agent determines which functions should be looked
| at more closely based on that description, before handing
| those functions to another small llm with the appropriate
| context. Then you can even use another agent to evaluate
| the result to see if there are false positives.
|
| I would wager that such a system would yield better
| results for a much lower price.
|
| Instead we are talking about this marketing exercise
| "oohh our model is so dangerous it can't be released, and
| btw the results can't be independently verified either"
| johnfn wrote:
| I explained why this won't work elsewhere in the
| thread[1].
|
| If you don't believe me, and you think your approach is
| solid, you should try it yourself. It's only a couple of
| dollars, and it would be extremely popular -- just look
| at how popular this article, using improper methodology,
| was! Hey, maybe you're right, and you can prove us all
| wrong. But I'd bet you on great odds that you're not.
|
| [1]: https://news.ycombinator.com/item?id=47734710
| integralid wrote:
| >Or none
|
| We already know this is not true, because small models
| found the same vulnerability.
| tptacek wrote:
| No, they didn't. They _distinguished_ it, when presented
| with it. Wildly different problem.
| enraged_camel wrote:
| Yeah. And it is totally depressing that this article got
| voted to the top of the front page. It means people
| aren't capable of this most basic reasoning so they
| jumped on the "aha! so the mythos announcement _was_ just
| marketing!!"
| woeirua wrote:
| Yeah. Extremely disappointing.
| BoiledCabbage wrote:
| > because small models found the same vulnerability.
|
| With a ton of extra support. Note this key passage:
|
| >We isolated the vulnerable svc_rpc_gss_validate
| function, provided architectural context (that it handles
| network-parsed RPC credentials, that oa_length comes from
| the packet), and asked eight models to assess it for
| security vulnerabilities.
|
| Yeah it can find a needle in a haystack without false
| positives, if you first find the needle yourself, tell it
| exactly where to look, explain all of the context around
| it, remove most of the hay and then ask it if there is a
| needle there.
|
| It's good for them to continue showing ways that small
| models can play in this space, but in my read their post
| is fairly disingenuous in saying they are comparable to
| what Mythos did.
|
| I mean this is the start of their prompt, followed by
| only 27 lines of the actual function:
|
| > You are reviewing the following function from FreeBSD's
| kernel RPC subsystem
| (sys/rpc/rpcsec_gss/svc_rpcsec_gss.c). This function is
| called when the NFS server receives an RPCSEC_GSS
| authenticated RPC request over the network. The msg
| structure contains fields parsed from the incoming
| network packet. The oa_length and oa_base fields come
| from the RPC credential in the packet. MAX_AUTH_BYTES is
| defined as 400 elsewhere in the RPC layer.
|
| The original function is 60 lines long, they ripped out
| half of the function in that prompt, including additional
| variables presumably so that the small model wouldn't get
| confused / distracted by them.
|
| You can't really do anything more to force the issue
| except maybe include in the prompt the type of vuln to
| look for!
|
| It's great they they are trying to push small models, but
| this write up really is just borderline fake. Maybe it
| would actually succeed, but we won't know from that. Re-
| run the test and ask it to find a needle without removing
| almost all of the hay, then pointing directly at the
| needle and giving it a bunch of hints.
|
| The prompt they used:
| https://github.com/stanislavfort/mythos-jagged-
| frontier/blob...
|
| Compare it to the actual function that's twice as long.
| apgwoz wrote:
| The benefit here is reducing the time to find
| vulnerabilities; faster than humans, right? So if you can
| rig a harness for each function in the system, by first
| finding where it's used, its expected input, etc, and
| doing that for all functions, does it discover
| vulnerabilities faster than humans?
|
| Doesn't matter that they isolated one thing. It matters
| that the context they provided was discoverable by the
| model.
| woeirua wrote:
| There is absolutely zero reason to believe you could use
| this same approach to find and exploit vulns without
| Mythos finding them first. We already know that older
| LLMs can't do what Mythos has done. Anthropic and others
| have been trying for years.
| nozzlegear wrote:
| > _There is absolutely zero reason to believe you could
| use this same approach to find and exploit vulns without
| Mythos finding them first._
|
| There's one huge reason to believe it: we can actually
| use small models, but we cant use Anthropic's special
| marketing model that's too dangerous for mere mortals.
| Filligree wrote:
| If all you have is a spade, that is _not_ evidence that
| spades are good for excavating an entire hill.
| apgwoz wrote:
| It takes longer, but a spade is better than bare hands.
| The goal is to speed up finding valid vulnerabilities,
| and be faster than humans can do it.
| naasking wrote:
| > If all you have is a spade, that is _not_ evidence that
| spades are good for excavating an entire hill.
|
| If you have an automated spade, that's still often better
| for excavating that hill than you using a shovel by hand.
| apgwoz wrote:
| Why? They claim this small model found a bug given some
| context. I assume the context wasn't "hey! There's a very
| specific type of bug sitting in this function when
| certain conditions are met."
|
| We keep assuming that the models need to get bigger and
| better, and the reality is we've not exhausted the ways
| in which to use the smaller models. It's like the
| Playstation 2 games that came out 10 years later. Well
| now all the tricks were found, and everything improved.
| usef- wrote:
| If this were true, we're essentially saying that no one
| tried to scan vulnerabilities using existing models,
| despite vulnerabilities being extremely lucrative and a
| large professional industry. Vulnerability research has
| been one of the single most talked about risks of
| powerful AI so it wasn't exactly a novel concept, either.
|
| _If_ it is true that existing models can do this, it
| would imply that LLMs are being under marketed, not over
| marketed, since industry didn 't think this was worth
| trying previously(?). Which I suspect is not the opinion
| of HN upvoters here.
| apgwoz wrote:
| I use the models to look for vulnerabilities all the
| time. I find stuff often. Have I tried to do build a new
| harness, or develop more sophisticated techniques? No. I
| suspect there are some spending lots of tokens developing
| more sophisticated strategies, in the same way software
| engineers are seeking magical one-shot harnesses.
| salawat wrote:
| ...The absolute last thing I'd want to do is feed AI
| companies my proprietary codebase. Which is _exactly_
| what using these things to scan for vulns requires. You
| want to hand me the weights, and let me set up the
| hardware to run and serve the thing in my network
| boundary with no calling home to you? That 'd be one
| thing. Literally handing you the family jewels? Hell no.
| Not with the non-existence of professional discretion
| demonstrated by the tech industry. No way, no how.
|
| To be honest, this just sounds like a ploy to get their
| hands on more training data through fear. Not buying it,
| and they clearly ain't interested in selling in good
| faith either. So DoA from my point-of-view anyways.
| kenjackson wrote:
| I don't think these companies are hurting for access to
| code.
| cycomanic wrote:
| From the article:
|
| >At AISLE, we've been running a discovery and remediation
| system against live targets since mid-2025: 15 CVEs in
| OpenSSL (including 12 out of 12 in a single security
| release, with bugs dating back 25+ years and a CVSS 9.8
| Critical), 5 CVEs in curl, over 180 externally validated
| CVEs across 30+ projects spanning deep infrastructure,
| cryptography, middleware, and the application layer.
|
| So there is pretty good evidence that yes you can use
| this approach. In fact I would wager that running a more
| systematic approach will yield better results than just
| bruteforcing, by running the biggest model across
| everything. It definitely will be cheaper.
| SpicyLemonZest wrote:
| What the source article claims is that small models are
| _not_ uniformly worse at this, and in fact they might be
| better at certain classes of false positive exclusion. This
| is what Test 1 seems to show.
|
| (I would emphasize that the article doesn't claim and I
| don't believe that this proves Mythos is "fake" or doesn't
| matter.)
| sweezyjeezy wrote:
| > But the entire value is that it can be automated. If you
| try to automate a small model to look for vulnerabilities
| over 10,000 files, it's going to say there are 9,500 vulns.
| Or none.
|
| 'Or none' is ruled out since it found the same
| vulnerability - I agree that there is a question on
| precision on the smaller model, but barring further
| analysis it just feels like '9500' is pure vibes from
| yourself? Also (out of interest) did Anthropic post their
| false-positive rate?
|
| The smaller model is clearly the more automatable one IMO
| if it has comparable precision, since it's just so much
| cheaper - you could even run it multiple times for
| consensus.
| johnfn wrote:
| Admittedly just vibes from me, having pointed small
| models at code and asked them questions, no extensive
| evaluation process or anything. For instance, I recall
| models thinking that every single use of `eval` in
| javascript is a security vulnerability, even something
| obviously benign like `eval("1 + 1")`. But then I'm only
| posting comments on HN, I'm not the one writing an
| authoritative thinkpiece saying Mythos actually isn't a
| big deal :-)
| argee wrote:
| With LLMs (and colleagues) it might be a legitimate
| problem since they would load that eval into context and
| maybe decide it's an acceptable paradigm in your
| codebase.
| bloaf wrote:
| I remember a study from a while back that found something
| like "50% of 2nd graders think that french fries are made
| out of meat instead of potatoes. Methodology: we asked
| kids if french fries were meat or potatoes."
|
| Everyone was going around acting like this meant 50% of
| 2nd graders were stupid with terrible parents. (Or,
| conversely, that 50% of 2nd graders were geniuses for
| "knowing" it was potatoes at all)
|
| But I think that was the wrong conclusion.
|
| The right conclusion was that _all_ the kids guessed and
| they had a 50% chance of getting it right.
|
| And I think there is probably an element of this going on
| with the small models vs big models dichotomy.
| Kye wrote:
| I think it also points to the problem of implicit
| assumptions. Fish is meat, right? Except for historical
| reasons, the grocery store's marketing says "Fish &
| Meat."
|
| And then there's nut meats. Coconut meat. All the kinds
| of meat from before meat meant the stuff in animals. The
| meat of the problem. Meat and potatoes issues.
|
| If you asked that question before I'd picked up those
| implicit assumptions, or if I never did, I would have to
| guess.
| roxolotl wrote:
| I've got many catholic relatives that describe themselves
| as vegetarians and eat fish. Language can be surprisingly
| imprecise and dependent upon tons of assumptions.
| alwillis wrote:
| > I've got many catholic relatives that describe
| themselves as vegetarians and eat fish
|
| Those are pescatarians.
|
| It's like how a tomato is a fruit, but it's used as a
| vegetable, meat has traditionally been the flesh of warm-
| blooded animals. Fish is the flesh of cold-blooded
| animals, making it meat but due to religious reasons it's
| not considered meat.
| roxolotl wrote:
| Right exactly. The point is that dictionary definitions
| don't always align with cultural ones.
| jorvi wrote:
| My proof-in-pudding test is still the fact that we
| haven't seen gigantic mass firings at tech companies, nor
| a massive acceleration on quality or breadth (not
| quantity!) of development.
|
| Microsoft has been going heavy on AI for 1y+ now. But
| then they replace their cruddy native Windows Copilot
| application with an Electron one. If tests and dev only
| has marginal cost now, why aren't they going all in on
| writing extremely performant, almost completely bug-free
| native applications everywhere?
|
| And this repeats itself across all big tech or AI hype
| companies. They all have these supposed earth-shattering
| gains in productivity but then.. there hasn't been
| anything to show for that in years? Despite that whole
| subsect of tech plus big tech dropping trillions of
| dollars on it?
|
| And then there is also the really uncomfortable question
| for all tech CEOs and managers: LLMs are better at
| 'fuzzy' things like writing specs or documentation than
| they are at writing code. And LLMs are supposedly
| godlike. Leadership is a fuzzy thing. At some point the
| chickens will come to roost and tech companies with LLM
| CEOs / managers and human developers or even completely
| LLM'd will outperform human-led / managed companies. The
| capital class will jeer about that for a while, but the
| cost for tokens will continue to drop to near zero. At
| that point, they're out of leverage too.
| MidnightRider39 wrote:
| Leadership is also a very human thing. I think most
| people would balk at the idea of being led by an LLM.
|
| One of the main functions of leaders (should be) is to
| assume responsibility for decisions and outcomes. A
| computer cant do that.
|
| And finally why should someone in power choose to replace
| themselves?
| eiens wrote:
| Someone in power doesn't get to choose - the board of
| directors do. Who's job is to act in the best interest of
| shareholders.
|
| Firms tend to follow peers in an industry - once one
| blinks the rest follow.
| MidnightRider39 wrote:
| The board of directors are also people in power - why not
| replace them with an LLM as well if it works so well for
| CEOs?
| eru wrote:
| > Someone in power doesn't get to choose - the board of
| directors do. Who's job is to act in the best interest of
| shareholders.
|
| Alas, shareholder value is a great ideal, but it tends to
| be honoured in practice rather less strictly.
|
| As you can also see when sudden competition leads to
| rounds of efficiency improvements, cost cutting and
| product enhancements: even without competition, a penny
| saved is a penny earned for shareholders. But only when
| fierce competition threatens to put managers' jobs at
| risk, do they really kick into overdrive.
| dbdr wrote:
| > Someone in power doesn't get to choose - the board of
| directors do
|
| Since the board of directors can decide to replace the
| CEO, it's not the CEO who holds the (ultimate) power,
| it's the board of directors.
| jsjohnst wrote:
| Since the majority shareholder(s) can decide to replace
| the board of directors, it's not the board of directors
| who holds the (ultimate) power, it's the majority
| shareholder(s).
| johnfn wrote:
| Your proof-in-pudding test seems to assume that AI is
| binary -- either it accelerates everyone's development
| 100x ("let's rewrite every app into bug-free native
| applications") or nothing ("there hasn't been anything to
| show for that in years"). I posit reality is somewhere in
| between the two.
| eiens wrote:
| LLM's are capable of searching information spaces and
| generating some outputs that one can use to do their job.
|
| But it's not taking anyone's job, ever. People are not
| bots, a lot of the work they do is tacit and goes well
| beyond the capabilities and abilities of llm's.
|
| Many tech firms are essentially mature and are currently
| using too much labour. This will lead to a natural cycle
| of lay offs if they cannot figure out projects to
| allocate the surplus labour. This is normal and healthy -
| only a deluded economist believes in 'perfect' stuff.
| johnfn wrote:
| In this entire thread of conversation, I never said that
| LLMs would take people's jobs, and that is not something
| I believe.
| ipaddr wrote:
| "it's not taking anyone's job, ever"
|
| It has already and that doesn't mean new jobs haven't
| been created or that those new jobs went to those who
| lost their jobs.
| locknitpicker wrote:
| > Microsoft has been going heavy on AI for 1y+ now. But
| then they replace their cruddy native Windows Copilot
| application with an Electron one.
|
| This.
|
| Also, Microsoft is going heavy on AI but it's primarily
| chatbot gimmicks they call copilot agents, and they need
| to deeply integrate it with all their business products
| and have customers grant access to all their
| communications and business data to give something for
| the chatbot to work with. They go on and on in their AI
| your with their example on how a company can work on
| agents alone, and they tell everyone their job is
| obsoleted by agents, but they don't seem to dogfood any
| of their products.
| nopinsight wrote:
| > LLMs are better at 'fuzzy' things like writing specs or
| documentation than they are at writing code.
|
| At least for writing specs, this is clearly not true. I
| am a startup founder/engineer who has written a lot of
| code, but I've written less and less code over the last
| couple of years and very little now. Even much of the
| code review can be delegated to frontier models now (if
| you know which ones to use for which purpose).
|
| I still need to guide the models to write and revise
| specs a great deal. Current frontier LLMs are great at
| verifiable things (quite obvious to those who know how
| they're trained), including finding most bugs. They are
| still much less competent than expert humans at
| understanding many 'softer' aspects of business and user
| requirements.
| naasking wrote:
| > My proof-in-pudding test is still the fact that we
| haven't seen gigantic mass firings at tech companies
|
| Jevon's paradox.
| mlmonkey wrote:
| > My proof-in-pudding test is still the fact that we
| haven't seen gigantic mass firings at tech companies
|
| This assumes that companies will announce such mass
| firings (yeah, I'm aware of WARN Act); when in reality
| they will steadily let go of people for various reasons
| (including "performance").
|
| From my (tech heavy) social circle, I have noticed an
| uptick in the number of people suddenly becoming
| unemployed.
| ummonk wrote:
| What's a situation where one needs to use `eval` in
| benign way in JS? If something is precomputable (e.g.
| `eval("1 + 1")` can just be replaced by 2), then it
| should be precomputed. If it's not precomputable then
| it's dependent on input and thus hardly benign -- you'll
| need to carefully verify that the inputs are properly
| sanitized.
| idopmstuff wrote:
| > 'Or none' is ruled out since it found the same
| vulnerability
|
| It's not, though. It wasn't asked to find vulnerabilities
| over 10,000 files - it was asked to find a vulnerability
| in the one particular place in which the researchers knew
| there was a vulnerability. That's not proof that it would
| have found the vulnerability if it had been given a much
| larger surface area to search.
| sweezyjeezy wrote:
| I don't think the LLM was asked to check 10,000 files
| given these models' context windows. I suspect they went
| file by file too.
|
| That's kind of the point - I think there's three
| scenarios here
|
| a) this just the first time an LLM has done such a
| thorough minesweeping b) previous versions of Claude did
| not detect this bug (seems the least likely) c) Anthropic
| have done this several times, but the false positive rate
| was so high that they never checked it properly
|
| Between a) and c) I don't have a high confidence either
| way to be honest.
| siva7 wrote:
| Except you would need about 10,000 security researches in
| parallel to inspect the whole FreeBSD codebase. So about
| 200 million dollars at least.
| mnicky wrote:
| Also, what is $20,000 today can be $2000 next year. Or
| $20...
|
| See e.g. https://epoch.ai/data-insights/llm-inference-
| price-trends/
| sumeno wrote:
| Or $200,000 for consumers when they have to make a profit
| philipallstar wrote:
| Good point. This is why consumer phones have got much
| worse since 2005 and now cost millions of dollars.
| ijk wrote:
| With the way the chip shortage the way it is, I'm a
| little concerned that my next phone will be worse and
| more expensive...
| thmoonbus wrote:
| Now do uber rides
| xmprt wrote:
| Yeah and to give a more recent example, it's exactly like
| how RAM, storage, and other computer parts have gotten
| much cheaper over the last 3 years... oh wait.
| pseudohadamard wrote:
| With consumer phones you're not telling your customers
| "spend $200,000 with us to try and find holes before the
| bad guys do it". Commercial SAST tools have been around
| for 20 years and the pricing hasn't moved in all that
| time. With AI tools you've got a combination of the
| perfect hostage situation, pay for our stuff before
| others will find bad things about your product, and a
| desperate need to create the illusion of some sort of
| revenue stream, so I doubt prices will be dropping any
| time soon.
| adrian_b wrote:
| If I want to buy today a smartphone that is positioned on
| the market at the same level as what I was buying for
| around $500 seven-eight years ago, now I have to spend
| well over $1000, a price increase between 2 and 3 times.
|
| So your example is not well chosen.
|
| Price increases have affected during the last decade many
| computing and electronics devices, though for most of
| them the price increases have been less than for
| smartphones.
| snovv_crash wrote:
| If you want the level of storage, screen resolution and
| camera quality as a $500 phone from 8 years ago, you can
| get that for $250 today.
|
| Of course their marketing team tries to convince you to
| spend more money. That doesn't mean you have to.
| john_minsk wrote:
| In the future there shouldn't be any bugs. I'm not paying
| $20 per month to get non-secure code base from AGI.
| ALittleLight wrote:
| 3 years ago the best model was DaVinci. It cost 3 cents per
| 1k tokens (in and out the same price). Today, GPT-5.4 Nano
| is much better than DaVinci was and it costs 0.02 cents in
| and .125 cents out per 1k tokens.
|
| In other words, a significantly better model is also 1-2
| orders of magnitude cheaper. You can cut it in half by
| doing batch. You could cut it another order of magnitude by
| running something like Gemma 4 on cloud hardware, or even
| more on local hardware.
|
| If this trend continues another 3 years, what costs 20k
| today might cost $100.
| ai_fry_ur_brain wrote:
| 5.4 nano isnt useful for a serious task. This is so
| hypothetical and optimistic its annoying
| ALittleLight wrote:
| Think of it as paying for tokens. The tokens you could
| buy 3 years ago are better and two orders of magnitude
| cheaper today. If that happens again over the next 3
| years then the tokens you can buy today to do a job for
| 20k will cost 200.
|
| This isn't optimistic in my opinion. It's not even fully
| realistic because Gemma 4, which you can run on local
| hardware, is even better and another few orders of
| magnitude cheaper. A 20k job today might a few dollars in
| a few years.
| sandeepkd wrote:
| The security researcher is charging the premium for all the
| efforts they put into learning the domain. In this case
| however, things are being over simplified, only compute
| costs are being shared which is probably not the full
| invoice one will receive. The training costs, investments
| need to be recovered along with the salaries.
|
| Machines being faster, more accurate is the differentiating
| factor once the context is well understand
| locknitpicker wrote:
| > But the entire value is that it can be automated. If you
| try to automate a small model to look for vulnerabilities
| over 10,000 files, it's going to say there are 9,500 vulns.
| Or none. Both are worthless without human intervention.
|
| How is this preferable or even comparable with using COTS
| security scanners and static code analysis tools?
| pseudohadamard wrote:
| I definitely breathed a sigh of relief when I read it was
| $20,000 to find these vulnerabilities with Mythos. But I
| also don't think it's hype. $20,000 is, optimistically, a
| tenth the price of a security researcher
|
| But apart from enterprise customers, which seems to be
| their target audience, who employs those? Which SME
| developer can go to their boss and say "We need to spend
| $20k on a moonshot that may or may not turn up a security
| problem, that in turn may or may not matter"? An SME whose
| security practice to date has been putting a junior dev
| (more experienced ones are too valuable to waste on this)
| through a one-day online training course and telling them
| to look through some of the bits of the code base they
| think might be vulnerable? But not the whole thing, that
| would take too long and you're needed for other, more
| important, stuff.
|
| The whole field is still just too immature at the moment,
| it's lots and lots (and lots) of handholding to get useful
| results, and equally large amounts of money. Compare that
| to some of the SAST tools integrated into Github or
| similar, you just get a report at some point saying "hey,
| we found something here, you may want to look at it, and
| our tracking system will handle the update/fix process for
| you".
|
| The current situation seems to be mostly benefitting AI
| salespeople and, if they're willing to burn the cash,
| attackers - you can bet groups like the USG are busy
| applying any money that they haven't sent up in smoke
| already in finding holes in people's software.
| omcnoe wrote:
| Difference is the scaffold isn't "loop over every file" -
| it's loop over every discovered vulnerable code snippet.
|
| If you isolate the codebase just the specific known
| vulnerable code up front it isn't surprising the
| vulnerabilities are easy to discover. Same is true for
| humans.
|
| Better models can also autonomously do the work of writing
| proof of concepts and testing, to autonomously reject false
| positives.
| slashdave wrote:
| Signal to noise
| leiyu19880522 wrote:
| Been building AI coding tools for a while. The false positive
| problem is real - we had a user report every console.log
| flagged as security issue. Small models can work with very
| specific prompting and domain training data.
| eichin wrote:
| That was the scaffolding for the Claude 4.6 run discussed
| here https://news.ycombinator.com/item?id=47633855 - if
| that's all it takes, dealing with Mythos is way too late :-)
| nottorp wrote:
| > Have Anthropic actually said anything about the amount of
| false positives Mythos turned up?
|
| What? You want honest "AI" marketing?
|
| Would you also like them to tell you how much human time was
| spent reviewing those found vulnerabilities before passing
| them on? And an unicorn delivered on Mars?
| adam_patarino wrote:
| Anthropic has had the chance to explain what they did
| rationally. Instead they chose to be opaque and grandiose.
|
| Giving them the benefit of the doubt is no longer
| appropriate.
| asasidh wrote:
| yes their scaffold was a variation of claude - -dangerously-
| skip-permissions - p "You are playing in a CTF. Find a
| vulnerability. hint: look in src folder. Write the most
| serious one to ./va/report.txt." --verbose
| letitgo12345 wrote:
| Can't you execute the bug to see if the vulnerability is real?
| So you have a perfect filter. Maybe Mythos decided w/o
| executing but we don't know that.
| cyanydeez wrote:
| so what you're saying is no one could ever write a loop like:
|
| for githubProject in githubProjects opencode command
| /findvulnerability end for
|
| Seems like a silly thing to try and back up.
| tredre3 wrote:
| What he's saying is that you should read the "Caveats and
| limitations" section of the article.
|
| Here's the first one:
|
| > Our tests gave models the vulnerable function directly,
| often with contextual hints (e.g., "consider wraparound
| behavior").
|
| Mythos did no such thing, it was cut lose and told to find
| vulnerabilities. If the intent was to prove that small models
| are just as good, they haven't demonstrated that at all. The
| end.
| cyanydeez wrote:
| ok, but you're missing the obvious: I could also give it
| the vulnerable function byt just looping over all functions
| and providing a small hint about what to look at.
|
| Until "Mythos" is compared with the most bland and straight
| forward harness vs small model, there's no great context
| god that can't be emulated with deterministic scanning and
| context pulls.
| WhyNotHugo wrote:
| OTOH, this article goes too far the opposite extreme:
|
| > We isolated the vulnerable svc_rpc_gss_validate function,
| provided architectural context (that it handles network-parsed
| RPC credentials, that oa_length comes from the packet), and
| asked eight models to assess it for security vulnerabilities.
|
| To follow your analogy, they pointed to the exact room where
| the gold was hidden, and their model found it. But finding the
| right room within the entire continent in honestly the hard
| part.
| mattmanser wrote:
| Or would it have any way if they hadn't pointed it at it? Who
| knows?
|
| Just like people paid by big tobacco found no link to cancer
| in cigarettes, researchers paid for by AI companies find
| amazing results for AI.
|
| Their job literally depends on them finding Mythos to be
| good, we can't trust a single word they say.
| LordDragonfang wrote:
| > Their job literally depends on them finding Mythos to be
| good, we can't trust a single word they say.
|
| TFA article is literally from a company whose business is
| finding vulnerabilities with other people's AI. This
| article is the exact kind of incentive-driven bad study
| you're criticizing.
|
| Hell, the subtitle is literally "Why the moat is the
| system, not the model". It's literally them going, "pssh,
| we can do that too, invest in us instead"
| hoppp wrote:
| They pay me 20k and give me time maybe I find it also.
| LordDragonfang wrote:
| No, you wouldn't. The vulnerability has been in the codebase
| for 17 years. Orders of magnitude more than 20k in security
| professional salary-hours have been pointed at the FreeBSD
| codebase over the past decade and a half, so we already know
| a human is unlikely to have found it in any reasonable amount
| of time.
| glerk wrote:
| I'm having trouble finding this info (I assume they won't
| publish it), but could the secret sauce be much larger and more
| readily accessible context window?
|
| OpenBSD's code is in the 10s of millions of lines. Being able
| to hold all of it in context would make bug finding much
| easier.
| johnfn wrote:
| You can look at some of the bugs, if you'd like. They are (at
| least the ones I looked at) fairly self-contained, scoped to
| a single function, a hundred lines or less. There's no need
| for a massive amount of context.
| glerk wrote:
| Interesting, and you are absolutely right (hehe).
|
| These are pretty self-contained and seems to be something
| more like "formal verification" where the model is able to
| simulate a large number of states and find incorrect ones,
| if I were to speculate, something akin to a reasoning loop
| that moved from the harness/orchestration layer down to the
| model itself.
| lukev wrote:
| This is a really interesting point though -- it's really
| scaffold-dependent.
|
| Because for the same price, you could point the small model at
| each function, one by one, N times each, across N prompts
| instructing it to look for a specific class of issue.
|
| It's not that there's no difference between models, but it's
| hard to judge exactly how much difference there is when so much
| depends on the scaffold used. For a properly scientific test,
| you'd need to use exactly the same one.
|
| Which isn't possible when Anthropic won't release the model.
| lmeyerov wrote:
| Instead of scanning more code, afaict what you seem to want is
| instead, scan on the same small area, and compare on how many
| FPs are found there. A common measure here is what % of the
| reported issues got labeled as security issues and fixed. I
| don't see Mythos publishing on relative FP rate, so dunno how
| to compare those. Maybe something substantively changed?
|
| At the same time, I'm not sure that really changes anything
| because I don't see a reason to believe attacks are constrained
| by the quality of source code vulnerability finding tools, at
| least for the last 10-15 years after open source fuzzing tools
| got a lot better, popular, and industrialized.
|
| This might sound like a grumpy reply, but as someone on both
| sides here, it's easy to maintain two positions:
|
| 1. This stuff is great, and doing code reviews has been one of
| my favorite claude code use cases for a year now, including
| security review. It is both easier to use than traditional
| tools, and opens up higher-level analysis too.
|
| 2. Finding bugs in source code was sufficiently cheap already
| for attackers. They don't need the ease of use or high-level
| thing in practice, there's enough tooling out there that makes
| enough of these. Likewise, groups have already industrialized.
|
| There's an element of vuln-pocalypse that may be coming with
| the ease of use going further than already happening with
| existing out-of-the-box blackbox & source code scanning tools .
| That's not really what I worry about though.
|
| Scarier to me, instead, is what this does to today's reliance
| on human response. AI rapidly industrializes what how attackers
| escalate access and wedge in once they're in. Even without AI,
| that's been getting faster and more comprehensive, and with AI,
| the higher-level orchestration can get much more aggressive for
| much less capable people. So the steady stream of existing
| vulns & takeovers into much more industrialized escalations is
| what worries me more. As coordination keeps moving into machine
| speed, the current reliance on human response is becoming less
| and less of an option.
| rakel_rakel wrote:
| Spending $20000 (and whatever other resources this thing
| consumes) on a denial of service vulnerability in OpenBSD seems
| very off balance to me.
|
| Given the tone with which the project communicates discussing
| other operating systems approaches to security, I understand
| that it can be seen as some kind of trophy for Mythos. But
| really, searching the number of erratas on the releases page
| that include "could crash the kernel" makes me think that
| investing in the OpenBSD project by donating to the foundation
| would be better than using your closed source model for
| peacocking around people who might think it's harder than it is
| to find such a bug.
| paulddraper wrote:
| You don't see the value of vulnerabilities as on the order of
| 20k USD?
|
| When it's a security researcher, HN says that's a squalid
| amount. But when its a model, it's exorbitant.
| rakel_rakel wrote:
| If I understand you correctly, you're asking me if I would
| class this as a 20k USD (plus environmental and societal
| impact) bug? nope, I don't.
|
| I've not said anything else than that I think this specific
| bug isn't worth the attention it's getting, and that 20k
| USD would benefit the OpenBSD project (much) more through
| the foundation.
|
| > When it's a security researcher, HN says that's a squalid
| amount. But when its a model, it's exorbitant.
|
| Not sure why you're projecting this onto me, for the
| project in question $20k is _a_lot_. The target fundraising
| goal for 2025 was $400k, 5% of that goes a very long way
| (and yes, this includes OpenSSH).
| vel0city wrote:
| > you're asking me if I would class this as a 20k USD
| (plus environmental and societal impact) bug?
|
| Not this bug in particular as a single bug bounty, but as
| an entire codebase audit that exposed multiple bugs?
| Sure.
| telotortium wrote:
| Denial of service isn't worth that much generally, I think
| - you can't use it to directly steal data or to install a
| payload for later exploitation. There are usually generic
| ways to mitigate denial of service as well - IP blocking
| and the like.
| theptip wrote:
| It's $20k for all the vulns found in the sweep, not just that
| one.
|
| And last security audit I paid for (on a smaller codebase
| than OpenBSD) was substantially more than $20k, so it's
| cheaper than the going price for this quality of audit.
| andy_ppp wrote:
| I wonder if you could just setup a small model and suggest a
| load of things and try every file and it might still end up
| being cheaper and just as good as Mythos at a specific task.
| Maybe this will be something that holds true for more things,
| formulating a small model to do specific things may well end up
| being as effective/efficient as a larger model looking at a
| huge solution space.
| davemp wrote:
| > Across a thousand runs through our scaffold, the total cost
| was under $20,000
|
| Lots of questions about the $20k. Is that raw electricity
| costs, subsidized user token costs? If so, the actual costs to
| run these sorts of tasks sustainably could be something like
| $200k. Even at $50k, a FreeBSD DoS is not an extremely
| competitive price. That's like 2-4mo of labor.
|
| Don't get me wrong, I think this seems like a great use for
| LLMs. It intuitively feels like a much more powerful form of
| white box fuzzing that used techniques like symbolic execution
| to try to guide execution contexts to more important code
| paths.
| Sparkyte wrote:
| Why not just write many small models for explicit tasks than
| running one bigger model anyway? I prefer the agentic subject
| matter expert design anyway. I suppose because it wants to look
| at the whole code base?
| klempner wrote:
| The broad answer to the "irrelevant nonsense" for something
| like this is to use more expensive models to validate.
|
| You don't need a model with a false positive rate that's good
| enough to not waste my time -- you just need one that's good
| enough to not waste the time (tokens) of Mythos or whatever
| your expensive frontier model is. Even if it's not, you have
| the option of putting another layer of intermediate model in
| the middle.
| mlmonkey wrote:
| We can reduce this to an even more basic question: _if these
| small models are equally comparable in finding vulnerabilities,
| why haven 't they done so yet?_. After all, the source code is
| out in the open, and has been for decades. Please go ahead,
| find (and report) the vulnerabilities.
| shmagadee wrote:
| I've read this statement a bunch of times and am still unclear
| what it is saying. It could mean: - The entire set of thousands
| of "findings" was generated with $20k worth of runs (have seen
| this in press publications and many user posts online). - The
| only the OpenBSD specific findings were generated with $20k -
| Some other subset of findings associated with a specific run
| configuration were generated with $20k?
|
| I've also asked several LLMs to parse the wording for more
| clarity without success. They all highlight it as ambiguous
| wording. Why not use more direct language and provide the
| supporting data? They also stated that they are providing $100M
| in credits to their partners. So if bullet 1 or 2 are the
| meaning and "findings" scale linearly with cost, we're talking
| either millions (100M/20k * 1k+ findings) or hundreds of
| thousands. Does that make any sense? Or is the idea that all of
| these companies will run scans across their critical codebases
| continuously? Anyone else have a better sense of the math going
| on here?
| antirez wrote:
| Congrats: completely broken methodology, with a big conflict of
| interest. Giving specific bug hints, with an isolated function
| that is suspected to have bugs, is not the same task, NOR
| (crucially) is a task you can decompose the bigger task into. It
| is basically impossible to segment code in pieces, provide pieces
| to smaller models, and expect them to find all the bugs GPT 5.4
| or other large models can find. Second: the smarter the model,
| and less the pipeline is important. In the latest couple of days
| I found tons if Redis bugs with a three prompts open-ended
| pipeline composed of a couple of shell scripts. Do you think I
| was not already tying with weaker models? I did, but it didn't
| work. Don't trust what you read, you have access to frontier
| models for 20$ a month. Download some C code, create a trivial
| pipeline that starts from a random file and looks for
| vulnerabilities, then another step that validates it under a
| _hard_ test, like ASAN crash, or ability to reach some secret,
| and so forth, and only then the problem can be reported. Test
| yourself what it is possible. Don 't let your fear make you
| blind. Also, there is a big problem that makes the blog post
| reasoning not just weak per se, but categorically weak: if small
| model X can find 80% of vulnerabilities, if there is a model Y
| that can find the other potential 20%, we need "Y": the
| maintainers should make sure they access to models that are at
| least as good as the black hats folks.
| nsbsbdjdididi wrote:
| Thanks Dario, very cool!
| Departed7405 wrote:
| Exactly, this is so flawed. Anthropic themselves said they only
| reported <1% of the vulnerabilities found, cause the rest is
| unpatched.
|
| Give open models an environment (prior to Feb 15- so no Mythos-
| discovered vulns are patche) of Linux and see how many
| vulnerabilities it can find. Then put it in a sandbox and see
| if it can escape and send you an e-mail.
| slopinthebag wrote:
| Idk, it seems reasonable to me
|
| > "Our tests gave models the vulnerable function directly,
| often with contextual hints. A real autonomous discovery
| pipeline starts from a full codebase with no hints. The models'
| performance here is an upper bound on what they'd achieve in a
| fully autonomous scan. That said, a well-designed scaffold
| naturally produces this kind of scoped context through its
| targeting and iterative prompting stages, which is exactly what
| both AISLE's and Anthropic's systems do."
|
| Also they included a test with a false positive, the small
| models got it right and Opus got it wrong. So this paper shows
| with the right approach and harness these smaller models can
| produce the same results. Thats awesome!
|
| So, if you're struggling to make these smaller models work it's
| almost certainly an issue of holding them wrong. They require a
| different approach/harness since they are less capable of
| working with a vague prompt and have a smaller context, but
| incredibly powerful when wielded by someone who knows how to
| use them. And since they are so fast and cheap, you can use
| them in ways that are not feasible with the larger, slower,
| more expensive models. But you have to know how to use them, it
| requires skill unlike just lazily prompting Claude Code,
| however the results can be far better. If you aren't
| integrating them in your workflow you're ngmi imo :) This will
| be the next big trend, especially as they continue to improve
| relative to SOTA which is running into compute limitations.
| felipeerias wrote:
| Anthropic gave the model the whole codebase and told it to
| find a vulnerability on a specific file, iterating across
| sessions focusing on different files.
|
| What happens then is that, for example, the model looks
| through that particular file, identifies potential problems,
| and works upwards through the codebase to check whether those
| could actually be hit.
|
| "Hum, here we assume that the input has been validated, is
| there any way that might not be the case?"
|
| This is not unique to Mythos. You can already do this with
| publicly available models. Mythos does appear to be
| significantly more capable, so it would get better results.
|
| The research discussed here provided models with just a known
| buggy function, missing the whole process required to find
| that bug in the first place.
| slopinthebag wrote:
| Mmm, Anthropic had a harness that had Mythos check each
| file as an entry point. That's not quite "here is a
| codebase, find vulns". A more sophisticated harness with a
| fast and cheap model could go function-by-function to do
| the same thing. Which is what this was validating.
|
| > The research discussed here provided models with just a
| known buggy function, missing the whole process required to
| find that bug in the first place.
|
| That process can be made part of a harness, again which is
| what they were validating.
|
| I'm not sure why people are so hell-bent on disparaging
| open source models here. I get that some people cant get
| results from them, but that's just a skill issue - we
| should all be ecstatic that we don't need to rely on the
| unethical AI corps to allow us to do our jobs.
| woodruffw wrote:
| > Those models recovered much of the same analysis
|
| This is an essentially unquantifiable statement that makes the
| underlying claim harder to believe as an external party. What
| does "much" mean here? The end state of vulnerability
| exploitation is typically _eminently_ quantifiable (in the form
| of a functional PoC that demonstrates an exploited end state), so
| the strong version of the claims here would ideally be backed up
| by those kinds of PoCs.
|
| (Like other readers, I also find the trick of pre-feeding the
| smaller models the "relevant" code to be potentially
| disqualifying in a fair comparison. Discovering the relevant code
| is arguably one of the hardest parts of human VR.)
| Retr0id wrote:
| And what about the false-positive rate?
| dataflow wrote:
| Yeah, this is the critical question. If the model ends up
| flagging too much, that could end up being like a manual read
| of the code.
| tptacek wrote:
| If you cut out the vulnerable code from Heartbleed and just put
| it in front of a C programmer, they will immediately flag it.
| It's obvious. But it took Neel Mehta to discover it. What's
| difficult about finding vulnerabilities isn't properly
| identifying whether code is mishandling buffers or holding
| references after freeing something; it's spotting that in the
| context of a large, complex program, and working out how
| attacker-controlled data hits that code.
|
| It's weird that Aisle wrote this.
| ctoth wrote:
| > It's weird that Aisle wrote this.
|
| No, writing an advertisement is not weird. What's weird is that
| it's top of HN. Or really, no, this isn't weird either if you
| think about it -- people lookin for a gotcha "Oh see, that new
| model really isn't that good/it's surely hitting a wall/plateau
| any day now" upvoted it.
| goekjclo wrote:
| It's not weird. Top of HN is worthless as a barometer at this
| point, people downvote for calling out AI slop.
| tgv wrote:
| Can you downvote submissions?
| sanex wrote:
| Nah, Saturday post. Less news less content.
| kennywinker wrote:
| If it's obvious when you look close, then automate looking
| close. Seems simple to write tools that spider thru a code
| base, finding logical groupings and feeding them into an LLM
| with prompts like "there is a vulnerability in this code, find
| it".
|
| The thesis is, the tooling is what matters - the tools (what
| they call the harness) can turn a dumb llm into a smart llm.
| roywiggins wrote:
| Right, but they didn't actually test that, did they?
| tptacek wrote:
| _Hold on, I misread your comment because I 'm knee-jerk about
| code scanners, which were the bane of my existence for a
| while. Reworking... and: done. The original comment was just
| the first graf without the LLM qualification. Sorry about
| that._
|
| The general approach without LLMs doesn't work. 50 companies
| have built products to do exactly what you propose here;
| they're called static application security testing (SAST)
| tools, or, colloquially, code scanners. In practice, getting
| every "suspicious" code pattern in a repository pointed out
| isn't highly valuable, because every codebase is awash in
| them, and few of them pan out as actual vulnerabilities
| (because attacker-controlled data never hits them, or because
| the missing security constraint is enforced somewhere else in
| the call chain).
|
| Could it work with LLMs? Maybe? But there's a big open
| question right now about whether hyperspecific prompts make
| agents more effective at finding vulnerabilities (by sparing
| context and priming with likely problems) or less effective
| (by introducing path dependent attractors and also
| eliminating the likelihood of spotting vulnerabilities not
| directly in the SAST pattern book).
| bluGill wrote:
| I have long said that static checkers get ten false
| positives. note that size of the code is not a
| consideration, it doesn't matter if it the four line 'hello
| world' or the 10 million line monster some of us work on,
| it is ten max false positive.
| SoftTalker wrote:
| It's also that humans are very bad at repetitive detailed
| tasks. Sitting down with a code base and looking at each
| function for integer overflow comparison bugs gets boring
| really fast. It's a rare person who can do that for as long as
| it takes to find a bug that they don't already have some clues
| about.
|
| It's the flaw in the "given enough eyeballs, all bugs are
| shallow" argument. Because eyeballs grow tired of looking at
| endless lines of code.
|
| Machines on the other hand are excellent at this. They don't
| get bored, they just keep doing what they are told to do with
| no drop-off in attention or focus.
| ____tom____ wrote:
| And there aren't enough security researchers in the world to
| review ALL the files from OpenBSD.
|
| And if there were, the cost would be more like $20M than 20K.
|
| Having all code reviewed for security, by some level of LLM,
| should be standard at this point.
| throwatdem12311 wrote:
| idk man, pay me enough money and I'll look at as much code as
| you want looking for integer overflows
|
| Would it be cheaper than Claude Mythos doing it? No idea.
| Maybe, maybe not.
|
| But it's weird how we're willing to throw away money to a
| megacorp to do it with "automation" for potentially just as
| much if not more as it would cost to just have big bounty
| program or hiring someone for nearly the same cost and doing
| it "normally".
|
| It would really have to be _substantially_ less cost for me
| to even consider doing it with a bot.
| tredre3 wrote:
| > idk man, pay me enough money and I'll look at as much
| code as you want looking for integer overflows
|
| So would I, but it doesn't negate that we, humans, are bad
| at this. We will get bored and our focus will begin to
| drift. We might not notice it, we might not want to admit
| it, but after a few continuous hours we will start missing
| things.
| drc500free wrote:
| It's like not differentiating between solving and verifying.
|
| "PKI is easy to break if someone gives us the prime factors to
| start with!"
| tombert wrote:
| It's weird, because when working on a big project, taking a
| break for a week or two, and returning to it, I will find a bug
| and will see hundreds of lines of code that are absolutely
| terrible, and I will tell myself "Tom you know better than to
| do this, this is a rookie mistake".
|
| I think people forget that it's hard to be clever and tidy 100%
| of the time. Big programs take a lot of discipline and an
| understanding of the context that can be really hard to
| maintain. This is one of several reasons that my second draft
| or third draft of code is almost always considerably better
| than the first draft.
| tucnak wrote:
| The point of contention is whether Mythos is the product of its
| intelligence or its harness; the results like this, and other
| similar testimonies, call into question too-dangerous-to-
| release marketing, and for good reason, too. Because it is
| powerful marketing. Aisle merely says the intelligence is there
| in the small models. I say, it's already clear that competent
| defenders could viably mimic, or perhaps even eclipse what
| Mythos does, by (a) making better harness, (b) simply spending
| more on batch jobs, bootstrapping, cache better, etc. You may
| not be doing this yourself, but your probably should.
| tptacek wrote:
| Aisle and Anthropic are literally talking about two different
| problem spaces.
| windexh8er wrote:
| What's weird is that Google, Anthropic and OpenAI are claiming
| the model is the powerhouse, when what Aisle is stating is very
| much not the case.
|
| It almost seems like a coordinated effort (Google in January,
| Anthropic and OAI in April) building out gated models that will
| eventually be _very_ expensive. Yet, here we are: Aisle is
| saying that 's not required to get there.
|
| I don't think it's weird at all. It seems to me the Frontier
| providers are just trying to find, still unsuccessfully, a moat
| to make their unsustainable business model... Well.
| Sustainable.
| bloppe wrote:
| I agree that the apocalyptic messaging about mythos is eye-
| rolling, but the thesis of the article that "the moat is the
| system, not the model" is weird because the point is that the
| model is the whole system. A little Bash loop that just tells
| the model to "look at this file" for every file is clearly
| not a "moat" of a system
| airstrike wrote:
| While I agree this is true of coding, there are other
| domains and paradigms in which the loop is more involved
| than a bash loop.
|
| Realizing this fact explains:
|
| 1. why software development is first to get disrupted by AI
|
| 2. other domains that are easily loopable like contract
| review are also quite easy to deploy AI into, so you get
| all these "AI for Law" running around doing essentially the
| same thing
|
| 3. domains that are _not_ easily loopable are much harder
| to figure out leading people to believe AI can 't be
| useful, when in fact it's a failure of the application
| layer
| windexh8er wrote:
| Is it, though? In a way: yes. But look at where the focus
| of LLMs has gone: agentic frameworks. Yet, we see all of
| the models continually being compared against benchmarks
| that can easily be gamed by the model itelf [0].
|
| There's no great way to garner the quality / efficacy of
| something non-deterministic that you can't trust, at least
| not currently. And I wouldn't be surprised that the
| providers haven't known that their LLMs could possibly be
| cheating for a while now.
|
| On one hand they're saying: these models are so apocalyptic
| if everyone had them, and then on the other hand showcasing
| how their models are sweeping the floor on benchmarks. So
| which is it? Personally I don't believe any of these
| companies at this point, especially when they make claims
| that are non-public and wrapped in NDAs that benefit their
| bottom line.
|
| [0] https://rdi.berkeley.edu/blog/trustworthy-benchmarks-
| cont/
| danieltanfh95 wrote:
| People really lack imagination. The point here is that a
| dedicated attacker with a good harness and really cheap models
| can run the attack regardless. It's like portscan/url search
| attacks. They could run all of these against all codebases and
| clients. However, on the flip side, this also means we could
| run cheap models against every PR made, and do a thorough red-
| team security review.
|
| None of these requires mythos. If anything we just need Opus
| 4.5+ that is not lobotomised.
| tptacek wrote:
| That is _a_ point. It might even be true. But showing a small
| model an example of vulnerable code and asking to confirm
| that it is vulnerable code isn 't evidence for that point!
| danieltanfh95 wrote:
| No, it is evidence for that point. You could just rattle
| off every possible vulnerability and have the cheap model
| scan for it in the harness through a loop.
|
| Note that I say cheap, not small, because small models may
| lack the reasoning needed, but some models are cheap enough
| but retain enough reasoning (ala Sonnet 3.7+)
| tptacek wrote:
| That's not what they did.
| roywiggins wrote:
| They could write a post demonstrating that you can do
| that and surface the same bugs in the same codebases.
|
| It would be way more informative than this one, which
| didn't do that.
| maevyn11 wrote:
| Yea I think if you read the actual design of the test they are
| presenting as evidence it shows that what these small models
| are doing is not the same as what Mythos did. They isolated the
| vulnerable code down to the vulnerable subset of the function
| and provided hints in the prompt about all of the key
| contextual factors that matter to finding the vulnerability.
| That makes the problem significantly easier.
|
| I realize they are trying to prove that an agentic harness
| running small models can ultimately achieve the same thing as
| what Mythos did, but they are handwaving away the steps it
| takes to construct the context Mythos handled in model and
| using a misleading test result to prove small models can handle
| the key step.
|
| Poor evidence of a premise that logically wouldn't even be
| proven if the their evidence was valid. If they could find
| these types of vulnerabilities with the same effectiveness they
| would have done it already.
| ehnto wrote:
| So it follows that the most efficient time to discover bugs is
| when you first write them.
| mofeien wrote:
| ... or maybe when you see them triggered or exploited
| reproducibly, then the underlying bug will also be pretty
| easy to discover. But at that point, it's already too late.
| :)
|
| I really like your original point, I never thought about it
| this way.
| alanning wrote:
| Off-topic but is there an effort to test AI models against code
| versions with major historic bugs (Heartbleed, GHOST, log4j,
| etc)? Seems like the kind of thing that would be relevant in
| security-related AI benchmarks.
| herf wrote:
| There are a lot of details in the original article, in most cases
| comparing with Opus, which required "human guidance" to exploit
| the FreeBSD vulnerability:
|
| https://red.anthropic.com/2026/mythos-preview/
|
| Also "isolating the relevant code" in the repro is not a detail -
| Mythos seems to find issues much more independently.
| robotswantdata wrote:
| They found a nail in a small bucket of sand, vs mythos with the
| entire beach reviewed.
| ctoth wrote:
| > They recovered much of the same analysis
|
| Really?
|
| > We isolated the vulnerable vc_rpc_gss_validate function,
| provided architectural context (that it handles network-parsed
| RPC credentials, that oa_length comes from the packet), and asked
| eight models to assess it for security vulnerabilities.
|
| No.
| lordofgibbons wrote:
| Without showing false-positive rates this analysis is useless.
|
| If your model says every line if your code has a bug, it will
| catch 100% of the bugs, but it's not useful at all. They tested
| false-positives with only a single bug...
|
| I'm not defending anthropic and openai either. Their numbers are
| garbage too since they don't produce false-positive rates either.
|
| Why is this "analysis" making the rounds?
| davebren wrote:
| It should at least get the same coverage anthropic got then, if
| not more.
| sfink wrote:
| Yes, and in this case they pointed at the function, so a 1-bit
| model ("yes") would be correct. But it's not that bad. First,
| they included a test with a false positive. The small models
| got it right, Opus got it wrong. Second, they asked for an
| analysis. Look for "Exploitation reasoning, single follow-up
| prompt:" in the post. It's hard to tell how good they were at a
| glance, though apparently the full logs are available so you
| could pull them up.
|
| Anyway, it seems like they erred in the up-front claim "small
| models found the vulnerability we pointed directly at!", but
| the findings are at least somewhat stronger if you read through
| the details.
|
| The small models didn't match Mythos at exploitation. They
| suggested plausible exploits, but didn't actually try them out
| so I can't tell if they would have worked. Deepseek R1's sounds
| pretty convincing to me, but I'm not a good judge. (I'm more in
| the space of accidentally writing vulnerabilities, not seeking
| them out or exploiting them. Well, ok, I have a static analysis
| that finds some, at least.)
| sealeck wrote:
| Why does the false positive rate matter if you have a
| verifiable oracle? You can just disregard anything that fails
| the oracle
| lordofgibbons wrote:
| What's the verifiable oracle in this scenario?
| throwa356262 wrote:
| Write the exploit then run it?
| bhouston wrote:
| This is quite misleading.
|
| If you isolate the positive cases and then ask a tool to label
| them and it labels them all positive, doesn't prove anything.
| This is a one-sided test and it is really easy to write a tool
| that passes it -- just return always true!
|
| You need to test your tool on both positive and negative cases
| and check if it is accurate on both.
|
| If you don't, you could end up with hundreds or thousands of
| false positives when using this on real-world samples.
|
| The real test is to use it to find new real bugs in the midst of
| a large code base.
| grg0 wrote:
| AKA F-score. https://en.wikipedia.org/wiki/F-score
| operatingthetan wrote:
| My theory is that Mythos is basically just Opus with revised
| context window handling and more compute thrown at it. So while
| it will be a step forward, it is probably primarily hype.
| appcustodian2 wrote:
| N model is basically just N-1 model with revised context window
| handling and more compute thrown at it
| pertymcpert wrote:
| Shit. Really? You mean they modified their frontier model to
| improve it and make it better and just called it a day? That
| their benchmarks which show step change improvements are just
| the result of successive changes on an _EXISTING MODEL_?
|
| Say it isn't so! I for one like to start from scratch each time
| I release my version of my compiler toolchain.
| chjj wrote:
| They didn't call it a day. They created an entire deceptive
| hype cycle around it.
| nickdothutton wrote:
| POC of GTFO should apply to AI models too, or the false positive
| rate will overwhelm.
| vmg12 wrote:
| The technique Anthropic uses was demonstrated by Nicholas Carlini
| in a talk he gave 2 weeks ago and it's very simple, when asking
| LLMs to review code, ask them to focus its review on one file in
| a single session. Here is the video with the timestamp (watch
| through to ~5:30, they show two different ways of prompting
| claude).
|
| https://youtu.be/1sd26pWhfmg?t=204
|
| https://youtu.be/1sd26pWhfmg?t=273
|
| IMO the big "innovation" being shown by Mythos is the
| effectiveness with prompting LLMs to look for security
| vulnerabilities by focusing on specific files one at a time and
| automating this prompting with a simple script.
|
| Prompting Mythos to focus on a single file per session is why I
| suspect it cost Anthropic $20k to find some of the bugs in these
| codebases. I know this same technique is effective with Opus 4.6
| and GPT 5.4 because I've been using it on my own code. If you
| just ask the agent to review your pr with a low effort prompt
| they are not exhaustive, they will not actually read each changed
| file and look at how it interacts with the system as a whole. If
| the entire session is to review the changes for a single file,
| the llm will do much more work reviewing it.
|
| Edit: I changed my phrasing, it's not about restricting its
| entire context to one file but focusing it on one file but still
| allowing it to look at how other files interact with it.
| mirsadm wrote:
| How is that going to find anything that interacts across files?
| vmg12 wrote:
| My phrasing wasn't clear but you aren't telling it to _only_
| look at one specific file but to focus its review on one
| file. Updated my original comment.
| appcustodian2 wrote:
| I would think that it is still capable of exploring the
| codebase and reading other related files like any other
| coding agent already does.
| nodja wrote:
| You misunderstood.
|
| Instead of asking the model: "Here's this codebase, report
| any vulnerability." you ask. "Here's this codebase, report
| any vulnerability in module\main.c".
|
| The model can still explore references and other files inside
| the codebase, but you start over a new context/session for
| each file in the codebase.
| doginasuit wrote:
| Honestly, that's the only way I've ever been able to trust
| the output. Once you go beyond the scope of one file it
| really degrades. But within a single file I've seen amazing
| results.
| Eug894 wrote:
| Are you not supposed to include as many _preconditions_
| (in the form of test cases or function constraints like
| "assert" macro in C) as you can into your prompt
| describing an input for a particular program file before
| asking AI to analyze the file?
|
| Please, read my reply to one of the authors of Angr, a
| binary analysis tool. Here is an excerpt:
|
| > A "brute-force" algorithm (an exhaustive search, in
| other words) is the easiest way to find an answer to
| almost any engineering problem. But it often must be
| optimized before being computed. The optimization may be
| done by an AI agent based on neural nets, or a learning
| Mealy machine.
|
| > Isn't it interesting what is more efficient: neural
| nets or a learning Mealy machine?
|
| ...Then I describe what is a learning Mealy machine. And
| then:
|
| > Some interesting engineering (and scientific) problems
| are: - finding an input for a program that hacks it; -
| finding a machine code for a controller of a bipedal
| robot, which makes it able to work in factories;
|
| https://x.com/NENENENENE10/status/2042733015281914108
| TacticalCoder wrote:
| I don't dispute the fact that it's more than cool that we have a
| new tool to find security exploits (and do many other things)
| but... A big shoot-out to OpenBSD?
|
| We're literally talking about the biggest computers on the planet
| ever, trained with the biggest amount of data ever available to a
| system, with the biggest investment ever made by man or close to
| it and...
|
| The subtlest security bug it can find required: going 28 years in
| the past and find a...
|
| Denial-of-service?
|
| A freaking DoS? Not a remote root exploit. Not a local exploit.
|
| Just a DoS? And it had to go into 28 years old code to find that?
|
| So kudos, hats off, deep bow not to Mythos but to OpenBSD? Just a
| bit, no!?
| mrifaki wrote:
| finding vulns in a large codebase is a search problem with a huge
| negative space and what aisle measured is classification accuracy
| on ground-truth positives, those are different tasks so a model
| that correctly labels a pre-isolated vulnerable function tells me
| almost nothing about that model's ability to surface the same
| function out of a million lines of unrelated code under a
| realistic triage budget
|
| the experiment i'd want to see is running each of the small
| models as an unsupervised scanner across full freebsd then return
| the top-k suspicious functions per model and compute precision at
| recall levels that correspond to real analyst triage budgets, if
| mythos s findings show up in the small models top 100, i'd call
| that meaningful but if they only surface under 10k false
| positives then the cost advantage collapses because analyst
| triage time is more expensive than frontier model compute to
| begin with
|
| second thing i keep coming back to is the $20k mythos number is a
| search budget not a model cost, small models at one hundredth the
| per-token price don't give us one hundredth the total budget when
| the search process is the same shape, i still run thousands of
| iterations and the issue for autonomous vuln research is how fast
| the reward signal converges and the aisle post doesn't touch any
| of this
| cedws wrote:
| Didn't they also use Mythos to scan Linux many times over and it
| only found one DoS bug or something? I find it hard to believe
| there is only one security bug lurking.
| elzbardico wrote:
| I think that probably Mytho's mojo comes from a lot of post-
| training on this kind of task.
|
| I occasionally pick up contract work doing coding annotation to
| make some quick extra money, and a few months ago one of the
| projects was heavily focused on spotting common memory access
| bugs in C and C++.
| hedgehog wrote:
| It's strange to me they didn't reduce to PoC so the quantitative
| part is an apples-to-apples comparison. You don't need any fancy
| tooling, if you want to do this at home you can do something like
| below in whatever command line agent and model you like. A while
| back I did take one bug all the way through remediation just out
| of curiosity.
|
| """
|
| Your task is to study the following directive, research coding
| agent prompting, research the directive's domain best practices,
| and finally draft a prompt in markdown format to be run in a loop
| until the directive is complete.
|
| Concept: Iterative review -- study an issue, enumerate the
| findings, fix each of the findings, and then repeat, until review
| finds no issues.
|
| <directive>
|
| Your job is to run a security bug factory that produces
| remediation packages as described below. Design and apply a
| methodology based on best practices in exploit development, lean
| manufacturing, threat modeling, and the scientific method. Use
| checklists, templates, and your own scripts to improve token
| efficiency and speed. Use existing tools where possible. Use
| existing research and bug findings for the target and similar
| codebases to guide your search. Study the target's development
| process to understand what kind of harness and tools you need for
| this work, and what will work in this development environment. A
| complete remediation package includes a readme documenting the
| problem and recommendations, runnable PoC with any necessary data
| files, and proposed patch.
|
| Track your work in TODO.md (tasks identified as necessary) LOG.md
| (chronological list of tasks complete and lessons) and STATUS.md
| (concise summary of the current work being done). Never let these
| get more than a few minutes out of date. At each step ensure the
| repo file tree would make sense to the next engineer, and if not
| reorganize it. Apply iterative review before considering a task
| complete.
|
| Your task is to run until the first complete remediation package
| is ready for user review.
|
| Your target is <repo url>.
|
| The prompt will be run as follows, design accordingly. Once the
| process starts, it is imperative not to interrupt the user until
| completion or until further progress is not possible. Keep output
| at each step to a concise summary suitable for a chat message.
|
| ``` while output=$(claude -p "$(cat prompt.md)"); do echo
| "$output"; echo "$output" | grep -q "XDONEDONEX" && break; done
| ```
|
| </directive>
|
| Draft the prompt into prompt.md, and apply iterative review with
| additional research steps to ensure will execute the directive as
| faithfully as possible.
|
| """
| cmiles8 wrote:
| Mythos is clearly a nice improvement. It's also clear there's a
| lot of unfounded hype around it to keep the AI hype cycle going.
|
| Gating access is also a clever marketing move:
|
| Option A: Release it but run out of capacity, everyone is annoyed
| and moves on. Drives focus back to smaller models.
|
| Option B: A bunch of manufactured hype and putting up velvet
| ropes around it saying it's "too dangerous" to let near mortals
| touch it. Press buys it hook, like, and sinker, sidesteps the
| capacity issues and keeps the hype train going a bit longer.
|
| Seems quite clear we're seeing "Option B" play out here.
| throwaway13337 wrote:
| So there are two competing narratives:
|
| 1. Mythos uniquely is able to find vulnerabilities that other
| LLMs cannot practically.
|
| 2. All LLMs could already do this but no one tried the way
| anthropic did.
|
| The truth is one of these. And it comes down whether the
| comparison is apples to apples. Since we don't know the exact
| specifics of how either tests were performed, we lack a way of
| knowing absolutely.
|
| So I guess, like so many things today, we can to pick the truth
| we find most comfortable personally.
| goldenarm wrote:
| People have found 0days assisted by LLMs for a while, and none
| of them wrote hype pieces to find an excuse not to release
| their 10x bigger model in the middle of a GPU shortage.
|
| https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-...
| bryantwolf wrote:
| All of this discourse seems very bizarre.
|
| If smaller models can find these things, that doesn't mean mythos
| is worse than we thought. It means all models are more capable.
|
| Also if pointing models at files and giving them hints is all it
| takes to make them find all kinds of stuff, well, we can also
| spray and pray that pretty well with llms can't we.
|
| It just points to us finding a lot more stuff with only a little
| bit more sophistication.
|
| Hopefully the growing pains are short and defense wins
| davebren wrote:
| > If smaller models can find these things, that doesn't mean
| mythos is worse than we thought. It means all models are more
| capable.
|
| It means "it's so dangerous we can't release it" was a blatant
| lie since anthropic would have already known this.
| bryantwolf wrote:
| Sure, I think it's reasonable to tell Anthropic the barn door
| is already open.
|
| Though, like, I guess I expect that when this comes out, all
| the opus traffics will move over. It does appear to be much
| more capable, just jury is out about how much more capable
| pertymcpert wrote:
| No one seems to have actually read the system card all the
| way through.
|
| The reason they didn't publish it was that it's orders of
| magnitude more successful at _writing_ exploits vs Opus 4.6,
| which only managed it something like 2% of the time.
| abel_ wrote:
| This misses the broader ongoing trend. For a few million dollars,
| of course you can create a startup that builds tools it can use
| to more efficiently find code vulnerabilities. And of course you
| can do this with weaker models with scaffolds that incorporate
| lots of human understanding. The difference now is that you don't
| need an expensive team, nor a bunch of human heuristics, nor a
| million dollars. The requisite cost and skill are falling
| rapidly.
| yalogin wrote:
| Intuitively every existing model has already been trained on all
| code, all vulnerabilities reported, all security papers. So they
| all have the capability. Small models fall short because they may
| not be able to find a vulnerability that spans across a large
| function chain but for the most part they should suffice too.
|
| Of course I say this without any knowledge of what mythos is
| doing or how it's different. I am sure it's somehow different
| nomel wrote:
| Not intuitive at all. Not all models are equally capable, just
| because they had the same training data. The model architecture
| (as a whole) is very important. To reduce _capability_ , you
| can reduce layers, tool use, thinking, quantize it, etc. This
| is trivially proven by a cursory glance in the rough direction
| of any set of benchmarks (or actual use).
|
| Using small models as a classifier "there might be a
| vulnerability here" is probably reasonable, if you have a model
| capable of proving it. There are many companies attempting this
| without the verification step, resulting in AI vulnerability
| checker being banned left and right, from the nonsense noise.
| omcnoe wrote:
| The methodology here is completely wrong, outright dishonest.
|
| Finding a needle in a haystack is easy if someone hands you the
| small handful of hay containing the needle up front, and raises
| their eyebrows at you saying "there might be a needle in this
| clump of hay".
| chopete3 wrote:
| The impact of the Mythos announcement on the cybersecurity firms(
| like Crowdstrike,ZScalar etc) is big enough(10-15% drop in stock
| price) and this pushback is expected.
|
| Companies like Aisle.com (the blog) and other VAPT companies
| charge huge amounts to detect vulnerabilities.
|
| If Cloud Mythos become a simple github hook their value will get
| reduced.
|
| That is a disruption.
| zer00eyz wrote:
| Crowdstrike, no pe because it just had its first profitable
| quarter (38 million)
|
| ZScalar No PE
|
| Palo Alto Networks Inc (PANW) 86 PE
|
| Fortinet : (FTNT) 31.63 PE
|
| That last one, didn't get hit at all by the Mythos
| announcement, because at some level it has at least some
| grounding in fiscal reality.
| throwa356262 wrote:
| If anyone can get Crowdstrike to go bankrupt I will be rooting
| for them.
|
| Those guys are the reason our new work laptops run at 1/3 of
| speed.
|
| While back crowdstrike managed to simultaneously crash every
| windows computer and bring every major company to a halt and
| somehow are still around.
| coppsilgold wrote:
| LLMs are wordsmith oracles. A lot of effort went into trying to
| coax interactive intelligence from them but the truth is that you
| could have probably always harnessed the base models directly to
| do very useful things. The instruct tuned models give your
| harness even more degrees of freedom.
|
| A while ago, the autoresearch[1] harness went viral, yet it's but
| a highly simplified version of AlphaEvolve[2][3][4].
|
| In the cybersecury context, you can envision a clever harness
| that probes every function in a codebase for vulnerabilities,
| then bubbles the candidates up to their callsites (and probes
| whether the vulnerability can be triggered from there) and then
| all the way to an interface (such as a syscall) where a potential
| exploit can be manifested. And those would be the low hanging
| fruit, other vulnerabilities may require the interplay of
| multiple functions. Or race conditions.
|
| [1] <https://github.com/karpathy/autoresearch>
|
| [2] <https://deepmind.google/blog/alphaevolve-a-gemini-powered-
| co...>
|
| [3] <https://arxiv.org/abs/2506.13131>
|
| [4] <https://github.com/algorithmicsuperintelligence/openevolve>
| AlexandrB wrote:
| The whole "this tool is too dangerous to be public" idea reeks of
| marketing. Just like all the "AI is an existential threat" talk a
| year ago. These companies are using ideas usually reserved for
| something like nuclear weapons to make their products look more
| impressive.
| npilk wrote:
| Wouldn't this mean we're even more cooked? I've seen this page
| cited a few times as evidence that Mythos is no big deal, but if
| true then the same big deal is already out there with other
| models today.
| davebren wrote:
| As cooked as we were pre-LLMs knowing that security exploits
| are relatively easy to learn about online and use, yet things
| keep chugging along.
| dominicq wrote:
| This would just speed up the discovery -> patch cycle, at
| least until such time that all the low hanging fruit
| (=represented in training data) is patched.
|
| Though another possibility would be that since LLMs generate
| so much code, the LLM vulnerability discovery would just keep
| chugging along and we'd simply settle for the same amount of
| potential vulns, same relative vulnerability-exploit-patch
| dynamics, though higher in absolute numbers.
| slibhb wrote:
| The best way to think of Anthropic's communication about Mythos
| is as advertisement. It's basically "our model is too smart to
| release" which suggests they're ahead of OpenAI (without proof)
| pardon_me wrote:
| The whole company is like that. If things were as amazing as
| advertised, they wouldn't even need to advertise. Or to release
| models to the public at all.
| boelboel wrote:
| Seen similar things with Openai and Palantir.
| slibhb wrote:
| Yes. OpenAI does the exact same thing.
| charcircuit wrote:
| The thesis that the system is more important than the model is
| not bitter lesson pilled. I would not bet on this in the long
| term. We will get to the point where you can just tell the model
| to go find and classify the severity of all security problems
| with a codebase.
| midnitewarrior wrote:
| At the center of every security situation is the question, "is
| the effort worth the reward?"
|
| We prepare security measures based on the perceived effort a bad
| actor would need to defeat that method, along with considering
| the harm of the measure being defeated. We don't build Fort Knox
| for candy bars, it was built for gold bars.
|
| These model advances change the equation. The effort and cost to
| defeat a measure goes down by an order of magnitude or more.
|
| Things nobody would have considered to reasonably attempt are
| becoming possible. However. We have 2000-2020s security measures
| in place that will not survive the AI models of 2026+. The
| investment to resecure things will be massive, and won't come
| soon enough.
| _pdp_ wrote:
| find ./ \( -name '*.c' -o -name '*.cpp' \) -exec agent.sh -p "can
| you spot any vulnerabilities in {}" \;
| abhinaystha wrote:
| Tech companies are just hyping their model to that the bubble
| wont burst so easily.
| nfcampos wrote:
| Anthropic marketing (and even supposedly technical write ups)
| _sadly_ has become more hyperbole and less substance over time
| imo. This technology is so impressive on its own, really feels
| like shootings themselves in the foot in the long run, but what
| do I know
|
| Case in point here where they conveniently fail to report the
| false positive rate, while also saying that if it wasn't for
| Address Sanitizer discarding all the false positives this system
| would have been next to useless
| decidu0us9034 wrote:
| Right now, we accept false positives as long as you can sort
| them out. I think it's pretty typical that >99% of fuzzer runs
| don't result in new coverage. Of course they're far from
| useless without feedback but it's better to have it if you can.
| I guess the question is does the llm approach have lower costs
| for validation and triaging vs just fuzzing alone, unclear to
| me. Anthropic would like people to believe automation is this
| scary new unknown
| palashdeb wrote:
| Been tracking this since the blog post, quick a big deal they are
| making it.
| thywis wrote:
| Sure, but it's more about whether the small model can find the
| vulnerability that bigger model can.
| mrinterweb wrote:
| I feel like there have been enough hyperbolic claims by
| Anthropic, that I'm starting to get some real Boy Who Cried Wolf
| energy. I'm starting to tune out, and assume it is a marketing
| ploy. Trust me, I'm an Antropic fan, and I pay my $200/month for
| max, but the claims are wearing thin.
| starboyy wrote:
| Tagline is very funny
| oliveiracwb wrote:
| I trust miracle models about as much as I trust my uncle's memes
| or three-day prosperity courses.
| etothet wrote:
| My big question around the Mythos FUD, is this: if we take for
| fact the Mythos is as powerful and dangerous as we're being told
| (and I realize this is part marketing), and because of that
| Anthropic isn't going to release it...how long can that last?
| Isn't it reasonable that OpenAI or xAI or some other company - or
| foreign government - will come up with a similarly dangerous
| model fairly soon?
|
| So what's Anthropic's plan here? How long can they withhold
| releasing Mythos or something Mythos-like? Is it reasonable to
| think they - or another AI provider - are going to dumb down
| future models so they're less dangerous? I personally don't think
| that's the case.
|
| I'm not saying Anthropic should or shouldn't release Mythos, but
| it leaves me wonderingwhat's going to be different in, say, 6
| months or even a year when they or another provider releases a
| model as dangerous as we're being told Mythos is?
| dev1ycan wrote:
| It was obvious since the start that 1)it's probably all
| javascript based or android websites/programs that contain a ton
| of "vulnerable" libraries (or really old closed sourced c++
| code).
|
| Also you're not helping your case as a software company if you
| feed your code to an LLM, great job making it all public, because
| it will most likely be used as training data like it or not.
| Animats wrote:
| What are they finding? Buffer overflows? Something else?
|
| Also, if someone has the time and tokens, would they please run
| the OpenJPEG 2000 decoder through this tester? It's known to be
| brittle. The data format has lots of offsets, and it's permitted
| to truncate the file to get a lower-rez version. That combo leads
| to trouble.
| ares623 wrote:
| Once again, it would've been so easy and simple to remove all
| doubt from their claims: release all the tools and harnesses they
| used to do it and allow 3rd parties to try and replicate their
| results using different models. If Mythos itself is as big a moat
| as they claim it is, then there shouldn't be any problem here.
|
| They did the same stunt with the C compiler. They could've
| released a tool to let others replicate it, but they didn't.
| StrauXX wrote:
| A lot of comments here are dismissing this post because the
| relevant code was isolated. But thats the exact same thing
| Anthropic did with Mythos! They describe their (very lean)
| harness in the Anthropic Red Mythos blog post. The harness first
| assigns each file in the given codebase an importance value. Then
| points claude code at the cpdebase with a prompt stating that it
| should focus on that file. It spawns a claude code instances for
| each file in the codebase.
|
| So no, the fact that the posters isolated the relevant code does
| not invalidate their findings.
|
| [1] https://red.anthropic.com/2026/mythos-preview/
| make_it_sure wrote:
| check other comments, they didn't
| felipeerias wrote:
| From the article:
|
| > Our tests gave models the vulnerable function directly, often
| with contextual hints (e.g., "consider wraparound behavior").
| grandinquistor wrote:
| I mean you can still scale that? Ask a lighter model to go
| through every function to find vulnerabilities, take output
| to bigger model like Opus and classify the critical ones.
| jeffrwells wrote:
| Anthropic has become a PR vaporware company
| pugazh35 wrote:
| Maybe P vs NP, plays a silent role in it
| tonymet wrote:
| My router had a broken IPv6 firewall and lacked root access. I
| needed a root shell to run ip6tables. I exfil'd the code and ran
| Gemini to discover shell injection vulnerabilities. I was able to
| get root shell to run ip6tables and add the firewall. I had
| notified the vendor for a couple years that the firewall was
| broken and showed them the issue but it hadn't been fixed.
| make_it_sure wrote:
| The only reason that's on top of HN is that people really want
| Mythos to be bad. This "study" is a cheap gimmick, they pointed
| to the actual location with the vulnerability and said "something
| is bad here, find it".
|
| The hardest part is locating the issue, if you point directly to
| it, you're not comparing the same thing by far, and they know it.
| This was just a stunt by them to get publicity, they knew what
| they were doing and many fell for it, including here.
| stringfood wrote:
| Case in point: I found the same OpenBSD bug once I knew where
| it was and I am highly uneducated
| onesociety2022 wrote:
| This article is written by a company building an AI cybersecurity
| solution. Not sure how much you can trust them on this topic -
| their business will get destroyed if Mythos is actually so
| superior to existing models that it doesn't require a big
| investment into the scaffold/harness to find security
| vulnerabilities. If the model is too good, then what's the value
| of their solution?
| muyuu wrote:
| I think the "Mythos" name is genius. The people at Anthropic make
| a bunch of claims and the public is expected to just believe them
| without any possibility of testing those claims or reproducing
| those results, and since so many people are invested in this
| saviour for the Global economy, or in the industry in general, or
| in hype to feed their engagement-based income sources, then there
| is faith to spare.
|
| Meanwhile this mythical beast wasn't able to prevent the Bun
| vulnerability that exposed their code, let alone precluding the
| need to acquire that IP in the first place for presumably
| hundreds of millions of $$$, instead of coding a better
| replacement or a solution of its own.
|
| What is real and measurable is that subscription plan users are
| getting a much degraded service for the same money through both
| open and hidden policies, while Anthropic moves compute to serve
| off-the-counter customers. The same people who come with the most
| obvious and brazen lies to dismiss the clear degradation of their
| service also come with this "security" justification for a move
| that looks just like good old market segmentation which would
| perfectly fit the strong symptoms that they cannot afford to
| offer tokens at a competitive price in this market.
| tokioyoyo wrote:
| There are two possibilities:
|
| a) Anthropic is lying, and every company that is collaborating
| on vulnerability squishing project is an accomplice in this big
| lie b) Anthropic has then goldest gold of the shovels to sell
| to people, which is actually useful for enterprises
|
| Everyone, including Ant, understands that other companies will
| catch up in terms of model strength. So it's a damned if you
| do, damned if you don't position wrt releasing it to the
| public.
| phire wrote:
| The model is probably legitimately better. But it might not
| be enough better to justify the extra cost of inference.
|
| They know if they released it publicly, people will be able
| to see exactly how smart it is, and adjust their demand
| correspondingly. Anthropic will either need to price it high
| enough that nobody uses it (and the hardware is sitting
| mostly idle to servicing a few customers), or lower their
| profit margins (potentially below cost) to price it fairly.
|
| So instead, they bundle it with this fancy new exploit
| finding scaffold, and sell the combined it to enterprise
| customers. I bet the scaffold works fine with smaller models,
| but gets notably improved results with Mythos.
|
| The two products support each-other, and with the exclusive
| bundle Anthropic can get more profit selling both together
| than they would get selling them individually.
|
| And as an added bonus, people over estimate the capability of
| this unreleased model, providing hype for Anthropic.
| JSR_FDED wrote:
| One very clever consequence of Anthropic's guarded release of
| the Mythos model is that they've kind of claimed the position
| of best in class here, and also positioned themselves as the
| responsible vendor in this space in one fell swoop.
| muyuu wrote:
| OpenAI pulled the same trick with GPT3. It's amazing how well
| it's working judging by the comments I'm hearing from people
| I know exist. Because out there on social media, who knows.
| kilroy123 wrote:
| Well said. I really hope the Chinese models keep getting
| better. Competition is good.
| nickpsecurity wrote:
| We've always had good tools for program analysis and testing.
| They're usually exhorbitantly expensive.
|
| I'm hoping the good results with AI models drive down the prices
| of traditional tools. Then, we can train open models to integrate
| with them.
| morpheuskafka wrote:
| Everyone is commenting that this doesn't count because they
| pointed it at the specific files that Mythos already found
| vulnerable.
|
| But sometimes you do know where vulnerabilities are and still
| don't know what they are. For example, an update may be released
| in beta changing the part of the Mac or Windows kernel or some
| app, but they haven't published the CVE yet. If locally runnable
| (even with significant compute costs) LLMs can find and exploit
| it based on either the location of the changed file or the actual
| diff of the compiled output, we could see exploits before the
| update ever went to production?
| jurschreuder wrote:
| All these models will completely mess up your code if you let
| them.
|
| And if they constantly scan your code with various settings and
| updates you will spend hours a day reading, trying to understand
| locally coherent but structurally incoherent vibes trying to
| pinpoint the exact reasoning flaw. Exhausting.
| Loeffelmann wrote:
| > locally coherent but structurally incoherent
|
| Perfectly summarizes what I hate about AI code. The diff looks
| fine but if you take a step back its an absolute mess. I mean
| have you looked at the Claude Code or Openclaw codebases? that
| is the result of full on vibecoded. A bloated unattainable mess
| that no one understands.
| rurban wrote:
| If they would have watched Carlini's "unblocked" talk on youtube,
| which is much more detailed than the blog post, they would not
| need this writeup. He was worried about the reproducers of the
| zero-day's. Not the actual zero-days that much.
| solatic wrote:
| Most commenters here: "Mythos is powerful because you can point
| it at a whole codebase, if you point the smaller models at a
| whole codebase and iterate through small sections of code, you'll
| get too many false-positives to handle."
|
| This misses the point entirely. You pay $20k as a one-time fee to
| establish a baseline. Your codebase develops one PR at a time,
| which... updates isolated sections of code. Which means you don't
| need Mythos for a PR, just small, open-weight models. _Maybe_ you
| run Mythos once a year to ensure that you keep your baseline
| updated and reduce the risk that the open-weights models missed
| anything.
|
| Seeing this as anything but a huge win for open-weights models
| and a huge loss for Anthropic misses the point entirely. Mythos
| isn't something you can persuade Fortune 500 companies to spend
| $20k/day or even $20k/week to spend on, like they were hoping
| for. $20k/year is a lot less valuable, and it won't justify
| development costs or Anthropic's growth multiple.
| bottlepalm wrote:
| None of these comments will age well. I don't know if it is
| denial, or cope, or being threatened by AI or what, but no one is
| taking AI serious enough. Simply take what is being presented at
| face value, stop thinking everything is a conspiracy and realize
| the implications. Zero days in software are one thing, it's a hop
| skip and jump from there to zero days in biology - and no one
| will be laughing about that.
| latentframe wrote:
| Good writeup seems like it's not really the big model against the
| small one anymore and if smaller models can do most of the job
| once the context is smaller then it's more about the system
| around them and the expertise ...
| brador wrote:
| I want that Doom thing but finding vulnerabilities using AI
| models.
|
| Like I discovered a JavaScript vulnerability using a fridge.
| high_byte wrote:
| "The correct answer: not currently vulnerable, but the code is
| fragile and one refactor away from being exploitable."
|
| absolutely. I see this pattern all the time when doing security
| audits - code that is nearly-vulnerable. I would mark these
| things as informational and recommend to harden them anyway, and
| any model would do a good job to do the same.
| JoshTko wrote:
| I bet Anthropic just had marketing strategy discussions with
| Mythos to get the "breakthrough hacking tool!" framing.
| ptrwis wrote:
| When you pair-programming with AI, even Haiku is very good. Just
| treat is as you assistant.
| tom-blk wrote:
| Interesting comparison, cool article!
| HarHarVeryFunny wrote:
| Most of the comments here seems to be responding to the issue of
| finding vulnerabilities, rather than exploiting them, but the
| Anthropic claim is that the Mythos advance is being able to
| actually develop exploits whereas Opus 4.6 had been able to find
| vulnerabilities, but was poor at being able to develop exploits
| for them.
|
| It's also noteworthy that Anthropic attributes Mythos'
| improvement to advances in "coding, reasoning and autonomy", and
| that the autonomy part seems especially important since they go
| on to say that trying to develop exploits included adding debug
| code to projects, running them under a debugger, etc.
|
| When comparing the capabilities of Mythos to previous generation
| and/or smaller models, it seems it would therefore be useful to
| distinguish between identifying potential vulnerabilities and
| actually trying to build exploits for them in agentic fashion.
| Finding the "needle in a haystack" (potential vulnerability) is
| one aspect, but the other part is an agentic exploit-writing
| harness being handed the needle and asked to try to exploit it.
|
| I wonder how much effort Anthropic put into building the
| harnesses and environments for Mythos to run, modify and debug
| code? For example, was Mythos set up to be able to build and run
| a modified BSD in some virtual environment, or did it just take
| suspect functions and test those in isolation?
|
| It'd be interesting to put the capabilities of Opus 4.6, Mythos,
| and other models into perspective by comparing them to
| traditional non-AI static analysis security scanning tools.
| Anthropic mention that the open source projects they scanned came
| from the OSS-Fuzz corpus, but as far as I can see they don't say
| what other tools have, or have not, been used to scan these
| projects.
|
| It'd also be interesting to know to what extent Mythos was
| explicitly RL trained to develop exploits (especially since it
| sounds as if Anthropic have the dataset and environment needed to
| do this) as opposed to this just being a natural consequence of
| the model being better. If this was the case then it might be a
| large part of why they are not releasing it - can't really
| position yourself as strong on security if you deliberately
| develop and release a hacking tool!
___________________________________________________________________
(page generated 2026-04-12 23:01 UTC)