6 ms·
There's still the question of access to the codebase. By all accounts, the best LLM cyber scanning approaches are really primitive - it's just a bash script tha
by somesortofthing 6mo ago
There's still the question of access to the codebase. By all accounts, the best LLM cyber scanning approaches are really primitive - it's just a bash script that goes through every single file in the codebase and, for each one and runs a "find the vulns here" prompt. The attacker usually has even less access than this - in the beginning, they have network tools, an undocumented API, and maybe some binaries.
You can do a lot better efficiency-wise if you control the source end-to-end though - you already group logically related changes into PRs, so you can save on scanning by asking the LLM to only look over the files you've changed. If you're touching security-relevant code, you can ask it for more per-file effort than the attacker might put into their own scanning. You can even do the big bulk scans an attacker might on a fixed schedule - each attacker has to run their own scan while you only need to run your one scan to find everything they would have. There's a massive cost asymmetry between the "hardening" phase for the defender and the "discovering exploits" phase for the attacker.
Exploitability also isn't binary: even if the attacker is better-resourced than you, they need to find a whole chain of exploits in your system, while you only need to break the weakest link in that chain.
If you boil security down to just a contest of who can burn more tokens, defenders get efficiency advantages only the best-resourced attackers can overcome. On net, public access to mythos-tier models will make software more secure.
- Retr0id 6mo agoTokens can also be burnt on decompilation.
- tptacek 6mo agoYes, and it apparently burns lots of tokens. But what I've heard is that the outcomes are drastically less expensive than hand-reversing was, when you account for labor costs.
- jeffmcjunkin 6mo agoCan confirm. Matching decompilation in particular (where you match the compiler along with your guess at source, compile, then compare assembly, repeating if it doesn't match) is very token-intensive, but it's now very viable: https://news.ycombinator.com/item?id=46080498 https://news.ycombinator.com/item?id=46080498 Of course LLMs see a lot more source-assembly pairs than even skilled reverse engineers, so this makes sense. Any area where you can get unlimited training data is one we expect to see top-tier performance from LLMs. (also, hi Thomas!)
- stackghost 6mo agoMy own experience has been that "ghidra -> ask LLM to reason about ghidra decompilation" is very effective on all but the most highly obfuscated binaries. Burning tokens by asking the LLM to compile, disassemble, compare assembly, recompile, repeat seems very wasteful and inefficient to me.
- mikestaas 6mo agoLaurieWired did a good episode about that kind of thing https://www.youtube.com/watch?v=u2vQapLAW88 https://www.youtube.com/watch?v=u2vQapLAW88
- kimixa 6mo agoThat matches my experience too - LLMs are very capable in "translating" between domains - one of the best experience I've had with LLMs is turning "decompiled" source into "human readable" source. I don't think that "Binary Only" closed-source isn't the defense against this that some people here seem to think it is.
- echelon 6mo agoHas anyone used an LLM to deobfuscate compiled Javascript?
- bitexploder 6mo agoYep. They are good at it.
- saagarjha 6mo agoI've used it for hobby efforts on Electron/React Native (Hermes bytecode) apps and it seems to work reasonably well
- heeen2 6mo agoyes, but it requires some nudging if you don't want to waste tokens. it will happily grep and sed through massive javascript bundles but if you tell it to first create tooling like babel scripts to format, it will be much quicker.
- gfosco 6mo agoYeah, it's token intensive but worth it. I built a very dumb example harness which used IDA via MCP and analyzed/renamed/commented all ~67k functions in a binary, using Claude Haiku for about $150. A local model could've accomplished it for much less/free. The knowledge base it outputs and the marked up IDA db are super valuable.
- whattheheckheck 6mo agoDo you have the repo example?
- heeen2 6mo agoI did something similar using ghidramcp for digging around this keyboard firmware, repo contains the ghidra project, linux driver and even patches to the original stock fw. https://github.com/echtzeit-solutions/monsgeek-akko-linux https://github.com/echtzeit-solutions/monsgeek-akko-linux
- somesortofthing 6mo agoAnother asymmetric advantage for defenders - attackers need to burn tokens to form incomplete, outdated, and partially wrong pictures of the codebase while the defender gets the whole latest version plus git history plus documentation plus organizational memory plus original authors' cooperation for free.
- high_na_euv 6mo ago>original authors' cooperation Ha >for free. Haha, it is more complicated in reality
- echelon 6mo ago> Tokens can also be burnt on decompilation. Prediction 1. We're going to have cheap "write Photoshop and AutoCad in Rust as a new program / FOSS" soon. No desktop software will be safe. Everything will be cloned. Prediction 2. We'll have a million Linux and Chrome and other FOSS variants with completely new codebases. Prediction 3. People will trivially clone games, change their assets. Modding will have a renaissance like never before. Prediction 4. To push back, everything will move to thin clients.
- jgraham 6mo agoI think if prediction 1 is true (that it becomes cheap to clone existing software in a way that doesn't violate copyright law), the response will not be purely technical (moving to thin clients, or otherwise trying to technically restrict the access surface to make reverse engineering harder). Instead I'd predict that companies look to the law to replace the protections that they previously got from copyright. Obvious possibilities include: * More use of software patents, since these apply to underlying ideas, rather than specific implementations. * Stronger DMCA-like laws which prohibit breaking technical provisions designed to prevent reverse engineering. Similarly, if the people predicting that humans are going to be required to take ultimate responsibility for the behaviour of software are correct, then it clearly won't be possible for that to be any random human. Instead you'll need legally recognised credentials to be allowed to ship software, similar to the way that doctors or engineers work today. Of course these specific predictions might be wrong. I think it's fair to say that nobody really knows what might have changed in a year, or where the technical capabilities will end up. But I see a lot of discussions and opinions that assume zero feedback from the broader social context in which the tech exists, which seems like they're likely missing a big part of the picture.
- btown 6mo agoThe problem, though, is that this turns "one of our developers was hit by a supply chain attack that never hit prod, we wiped their computer and rotated keys, and it's not like we're a big target for the attacker to make much use of anything they exfiltrated..." into "now our entire source code has been exfiltrated and, even with rudimentary line-by-line scanning, will be automatically audited for privilege escalation opportunities within hours." Taken to an extreme, the end result is a dark forest. I don't like what that means for entrepreneurship generally.
- linkregister 6mo agoThis is a great example of vulnerability chains that can be broken by vulnerability scanning by even cheaper open source models. The outcome of a developer getting pwned doesn't have to lead to total catastrophe. Having trivial privilege escalations closed off means an attacker will need to be noisy and set off commodity alerting. The will of the company to implement fixes for the 100 Github dependabot alerts on their code base is all that blocks these entrepreneurs. It does mean that the hoped-for 10x productivity increase from engineers using LLMs is eroded by the increased need for extra time for security. This take is not theoretical. I am working on this effort currently.
- pixl97 6mo agoI disagree that it's extra time for security, it's the time we should have been spending in the first place.
- fragmede 6mo agoIt's great news for developers. Extra spend on a development/test env so dev have no prod access, prod has no ssh access; and SREs get two laptops, with the second one being a Chromebook that only pulls credentials when it's absolutely necessary.
- linkregister 6mo agoYes, having a good development env with synthetic data, and an inaccessible, secure prod env just got justification. I never considered the secondary SRE laptop but I think it might be a good idea.
- anitil 6mo agoOn that latest episode of 'Security Cryptography Whatever' [0] they mention that the time spent on improving the harness (at the moment) end up being outperformed by the strategy of "wait for the next model". I doubt that will continue, but it broke my intuition about how to improve them [0] https://securitycryptographywhatever.com/2026/03/25/ai-bug-finding/ https://securitycryptographywhatever.com/2026/03/25/ai-bug-f...
- conception 6mo agoThis is basically how you should treat all AI dev. Working around AI model limits for something that will take 3-6 months of work has very little ROI compared to building what works today and just waiting and building what works tomorrow tomorrow.
- sally_glance 6mo agoThis is the hard part - especially with larger initiatives, it takes quite a bit of work to evaluate what the current combination of harness + LLM is good at. Running experiments yourself is cumbersome and expensive, public benchmarks are flawed. I wish providers would release at least a set of blessed example trajectories alongside new models. As it is, we're stuck with "yeah it seems this works well for bootstrapping a Next.js UI"...
- thephyber 6mo agoThis assumes AI model improvements will be predictable, which they won’t. There are several simultaneous moving targets: the different models available at any point in time, the model complexity/ capability, the model price per token, the number of tokens used by the model for that query, the context size capabilities and prices, and even the evolution of the codebase. You can’t calculate comparative ROIs of model A today or model B next year unless these are far more predictable than they currently are.
- theptip 6mo agoIt’s a good thing to keep in mind, but LLM + scaffolding is clearly superior. So if you just use vanilla LLMs you will always be behind. I think the important thing is to avoid over-optimizing. Your scaffold, not avoid building one altogether.
- kelvinjps10 6mo agowhat about open source software?
- pbgcp2026 6mo ago[dead]
- eru 6mo ago> There's a massive cost asymmetry between the "hardening" phase for the defender and the "discovering exploits" phase for the attacker. Well, you need to harden everything, the attacker only needs to find one or at most a handful of exploits.
- lelanthran 6mo ago> Well, you need to harden everything, the attacker only needs to find one or at most a handful of exploits. Yeah, but it's not like the attacker knows where to look without checking everything, it it? If you harden and fix 90% of vulns, the attacker may give up when their attempts reach 80% of vulns. It's the same as it has ever been; you don't need to outrun the bear, you only need to outrun the other runners.
- eru 6mo agoCompare and contrast https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
- lelanthran 6mo agoMy point is that the cost for the attacker is higher than the cost for the defender, if the attacker has to spend tokens probing for vulnerabilities against a system which has little know about it, while the defender spends tokens on a system they have the full source to. That is not at all relevant to "security via obscurity" or similar arguments: having the source in the open may (eventually) be more secure, but it lowers the token-spend for the attacker.
- eru 6mo agoThe attacker can get access to the sources via eg industrial espionage.
- lelanthran 6mo ago
- bryanrasmussen 6mo ago>By all accounts, the best LLM cyber scanning approaches are really primitive It seems like that is perhaps not the case anymore with the Mythos model?
- nl 6mo ago> By all accounts, the best LLM cyber scanning approaches are really primitive - it's just a bash script that goes through every single file in the codebase What accounts are these? I've seen some people use this but I cannot imaging that anyone thinks this is the best. For example I've had success telling LLMs to scan from application entry points and trace execution, and that seems an extremely obvious thing to do. I can't imagine others in the field don't have much better approaches.
- linkregister 6mo agoIndeed, all the hot security scanning vendors are using custom prompts to capture a more holistic approach. There are of course plenty of legacy scanners that still focus on OS package versions and static configs, but the parts of the industry leaning into LLMs have genuine value to add. I don't expect Claude Code Review to be a replacement for a good vendor's solution.
- kansface 6mo agoThis feels pretty fertile atm to me, because it has been prohibitively expensive to do. I expect there is a ton of low hanging fruit. Why not in the age of AI?
- ozim 6mo agoStill it makes cost of making software higher. You cannot get away with „well no one is going to spend time writing custom exploit to get us” or „just be faster than slowest running away from the bear”.
- xeyownt 6mo agoOne defender, many attackers, I don't see how the economy of scale can be positive for the defender. Assuming your code is inaccessible isn't good for security. All security reviews are done assuming code source is available. If you don't provide the source, you'll never score high in the review.
- throwawayqqq11 6mo agoI think automated scanning can be positive for the defenders, when the rate of introducing new vulnerabilities vs fixing old ones is < 1 (detection rate + infra is a factor too ofc). In that case, AI can become the many eyes to check FOSS and those projects will eventually reach a "secure" state.
- goodpoint 6mo agoIt's the opposite, the economy of scale favors defense.
- chrisjj 6mo ago> By all accounts, the best LLM cyber scanning approaches are really primitive - it's just a bash script that goes through every single file in the codebase and, for each one and runs a "find the vulns here" prompt Primitive? I'd say simple and thorough.
- lmeyerov 6mo agoMost companies and their vendor ecosystems run on OSS Worse, "attackers no longer break in, they log in", so the supply chain attacks harvesting credentials have been frightening
- tossandthrow 6mo ago> it's just a bash script that goes through every single file in the codebase and, for each one and runs a "find the vulns here" prompt. This really is not the case. You have freedom of methodology. You can also ask it to enumerate various risks and find proof of existence for each of them. Certainly our LLM audits are not just a prompt per file - so I have a hard time believing that best in class tools would do this.
- pseudohadamard 6mo agoI've actually had pretty good results from doing exactly that. There was one FP when it tried to be Coverity and failed miserably, but the others were "you need to look at this bit more closely", and in most cases there was something there. Not necessarily a vuln but places where the code could have been written more clearly. It was like having your fourth grade English teacher looking over your shoulder and saying "you need to look at the grammar in this sentence more closely". And using an LLM to audit your code isn't necessarily a case of turning it into perfect code, it's to keep ahead of the other side also using an LLM. You don't need to outrun the bear, just the other hikers.