[HN Gopher] Vulnerability research is cooked
___________________________________________________________________
Vulnerability research is cooked
Author : pedro84
Score : 101 points
Date : 2026-03-30 18:43 UTC (4 hours ago)
(HTM) web link (sockpuppet.org)
(TXT) w3m dump (sockpuppet.org)
| nitros wrote:
| I'm suspicious of this prediction given the curl project's
| experiences...
| tptacek wrote:
| Everybody agrees that idiots were spamming curl with random
| just-plausible-enough-seeming output from old models.
| tomjakubowski wrote:
| It sounds like what makes the pipeline in the article
| effective is the second stage, which takes in the
| vulnerability reports produced by the first level and
| confirms or rejects them. The article doesn't say what the
| rejection rate is there.
|
| I don't think the spammers would think to write the second
| layer, they would most likely pipe the first layer (a more
| naive version of it too, probably) directly to the issue
| feed.
| tptacek wrote:
| There are at least three differences:
|
| * Carlini's team used new frontier models that have gotten
| materially better at finding vulnerabilities (talk to
| vulnerability researchers outside the frontier labs,
| they'll echo that). Stenberg was getting random slop from
| people using random models.
|
| * Carlini's process is iterated exhaustively over the whole
| codebase; he's not starting with a repo and just saying
| "find me an awesome bug" and taking that and only that
| forward in the process.
|
| * And then yes, Carlini is qualifying the first-pass
| findings with a second pass.
| wslh wrote:
| The problem is that you have all kind of "security spam" in the
| same way that social media is flooded by automatic, but on-
| topic, content. This doesn't mean that some very few reports
| are not correct.
|
| One way to filter that out could be to receive the PoC of the
| exploit, and test it in some sandbox. I think what XBOW and
| others are doing is real.
| jerf wrote:
| The people spamming curl did step one, "write me a
| vulnerability report on X" but skipped step two, "verify for me
| that it's actually exploitable". Tack on a step three where a
| reasonably educated user in the field of security research does
| a sanity check on the vulnerability implementation as well and
| you'll have a pipeline that doesn't generate a ton of false
| positives. The question then will rather be how cost-effective
| it is for the tokens and the still-non-zero human time
| involved.
| MajesticHobo2 wrote:
| That was then, this is now. The new models are scarily good. If
| you're skeptical, just take an hour to replicate the strategy
| the article references. Point Claude at any open-source
| codebase you find interesting and instruct it to find
| exploitable vulnerabilities. Give it a well-defined endpoint if
| you want (e.g., "You must develop a Python script that triggers
| memory corruption via a crafted request") and see how well it
| does.
| phyzome wrote:
| > That was then, this is now.
|
| No, what we were seeing with curl was script kiddies. It
| wasn't about the quality of the models at all. They were not
| filtering their results for validity.
| MajesticHobo2 wrote:
| It was definitely partially about model quality. The
| frontier models are capable of producing valid findings
| with (reasonably) complex exploit chains on the first pass
| (or with limited nudging) and are much less prone to making
| up the kinds of nonsensical reports that were submitted to
| curl. Compared to now, the old models essentially didn't
| work for security.
|
| If those script kiddies had been using today's models
| instead and _still_ didn't do any filtering, a lot more of
| those bugs would have been true positives.
| tomjakubowski wrote:
| > Now consider the poor open source developers who, for the last
| 18 months, have complained about a torrent of slop vulnerability
| reports. I'd had mixed sympathies, but the complaints were at
| least empirically correct. That could change real fast. The new
| models find real stuff.
|
| The slop reports won't stop just because real ones are coming in.
| If the author's right, open source maintainers will still will
| have to deal with the torrent of slop: _on top of_ triaging and
| identifying the legit vulnerabilities. Obviously, this is just
| another role for AI models to fill.
| stavros wrote:
| I don't understand why the takeaway here is (unless I'm missing
| something), more or less "everything is going to get exploited
| all the time". If LLMs can really find a ton of vulnerabilities
| in my software, why would I not run them and just patch all the
| vulnerabilities, leading to perfectly secure software (or, at the
| very least, software for which LLMs can no longer find any new
| vulnerabilities)?
| tptacek wrote:
| That might be one outcome, especially for large, expertly-
| staffed vendors who are already on top of this stuff. My real
| interest in what happens to the field for vulnerability
| researchers.
| lifty wrote:
| Perhaps a meta evolution, they become experts at writing
| harnesses and prompts for discovering and patching
| vulnerabilities in existing code and software. My main
| interest is, now that we have LLMs, will the software
| industry move to adopting techniques like formal verification
| and other perhaps more lax approaches that massively increase
| the quality of software.
| stavros wrote:
| True, but I already am curious to see what happens in a
| multitude of fields, so this is just one more entry in that
| list.
| underdeserver wrote:
| Just wanted to point out that tptacek is the blog post's
| author (and a veteran security researcher).
| layer8 wrote:
| The pressure to do so will only happen as a consequence of the
| predicted vulnerability explosion, and not before it. And it
| will have some cost, as you need dedicated and motivated people
| to conduct the vulnerability search, applying the fixes, and
| re-checking until it comes up empty, before each new
| deployment.
|
| The prediction is: _Within the next few months, coding agents
| will drastically alter both the practice and the economics of
| exploit development. Frontier model improvement won't be a slow
| burn, but rather a step function. Substantial amounts of high-
| impact vulnerability research (maybe even most of it) will
| happen simply by pointing an agent at a source tree and typing
| "find me zero days"._
| cartoonworld wrote:
| I feel like the dream of static analysis was always a pipe.
|
| When the payment for vulns drops i'm wondering where the
| value is for hackers to run these tools anymore? The LLMs
| don't do the job for you, testing is still a LOT OF WORK.
| zar1048576 wrote:
| My sense is that the asymmetry is non-trivial issue here. In
| particular, a threat actor needs one working path, defenders
| need to close all of them. In practice, patching velocity is
| bounded by release cycles, QA issues / regression risk, and a
| potentially large number of codebases that need to be looked
| at.
| Veserv wrote:
| When did we enter the twilight zone where bug trackers are
| consistently empty? The limiting factor of bug reduction is
| remediation, not discovery. Even developer smoke testing
| usually surfaces bugs at a rate far faster than they can be
| fixed let alone actual QA.
|
| To be fair, the limiting factor in remediation is usually
| finding a reproducible test case which a vulnerability is by
| necessity. But, I would still bet most systems have plenty of
| bugs in their bug trackers which are accompanied by a
| reproducible test case which are still bottlenecked on
| remediation resources.
|
| This is of course orthogonal to the fact that patching systems
| that are insecure by design into security has so far been a
| colossal failure.
| reactordev wrote:
| That might have been true pre LLMs but you can literally
| point an agent at the queue until it's empty now.
| batshit_beaver wrote:
| You literally cannot, since ANY changes to code tend to
| introduce unintended (or at least not explicitly requested)
| new behaviors.
| reactordev wrote:
| I've had mine on a Ralph loop no problem. Just review the
| PR..
| k_roy wrote:
| Which still means a single person with Claude can clear a
| queue in a day versus a month with a traditional team.
| lll-o-lll wrote:
| Eventual convergence? Assuming each defect fix has a 30%
| chance of introducing a new defect, we keep cycling until
| done?
| Kinrany wrote:
| Why would it converge?
| saintfire wrote:
| Assuming you can catch every new bug it introduces.
|
| Both assumptions being unlikely.
|
| You also end up with a code base you let an AI agent
| trample until it is satisfied; ballooned in complexity
| and redudant brittle code.
| charcircuit wrote:
| You can have an AI agent refactor and improve code
| quality.
| bsder wrote:
| The fact that KiCad still has a ton of highly upvoted
| missing features and the fact that FreeCAD still hasn't
| solved the topological renumbering problem are existence
| proofs to the contrary.
| Buttons840 wrote:
| > If LLMs can really find a ton of vulnerabilities in my
| software, why would I not run them and just patch all the
| vulnerabilities, leading to perfectly secure software?
|
| Probably because it will be a felony to do so. Or, the threat
| of a felony at least.
|
| And this is because it is very embarrassing for companies to
| have society openly discussing how bad their software security
| is.
|
| We sacrifice national security for the convenience of
| companies.
|
| We are not allowed to test the security of systems, because
| that is the responsibility of companies, since they own the
| system. Also, companies who own the system and are responsible
| for its security are not liable when it is found to be insecure
| and they leak half the nations personal data, again.
|
| Are you seeing how this works yet? Let's not have anything like
| verifiable and testable security interrupt the gravy train to
| the top. Nor can we expect systems to be secure all the time,
| be reasonable.
|
| One might think that since we're all in this together and all
| our data is getting leaked twice a month, we could work
| together and all be on the lookout for security vulnerabilities
| and report them responsibly.
|
| But no, the systems belong to companies, and they are solely
| responsible. But also (and very importantly) they are not
| responsible and especially they are not financially liable.
| gruez wrote:
| >> If LLMs can really find a ton of vulnerabilities in my
| software, why would I not run them and just patch all the
| vulnerabilities, leading to perfectly secure software?
|
| >Probably because it will be a felony to do so. Or, the
| threat of a felony at least.
|
| "my software" implies you own it (ie. your SaaS), so CFAA
| isn't an issue. I don't think he's implying that vigilante
| hackers should be hacking gmail just because they have a
| gmail account.
| htrp wrote:
| Attackers only have to be successful once while defenders have
| to be successful all the time?
| joatmon-snoo wrote:
| Breaking something is easier than fixing it.
| tptacek wrote:
| People have said that for decades and it wasn't true until
| recently.
| underdeserver wrote:
| Specifically in software vulnerability research, you mean.
|
| Fixing vulnerable code is usually trivial.
|
| In the physical world breaking things is usually easier.
| charcircuit wrote:
| A proper fix maybe. But LLMs can easily make it no longer
| exploitable in most cases.
| spr-alex wrote:
| I interned for the author at 18. I assumed security testing
| worked like this:
|
| 1. Static analysis catches nearly all bugs with near-total code
| coverage
|
| 2. Private tooling extends that coverage further with better
| static analysis and dynamic analysis, and that edge is what makes
| contractors valuable
|
| 3. Humans focus on design flaws and weird hardware bugs like
| cryptographic side-channels from electromagnetic emanations
|
| Turns out finding all the bugs is really hard. Codebases and
| compiler output have exploded in complexity over 20 years which
| has not helped the static analysis vision. Todays mitigations are
| fantastic compared to then, but just this month a second 0day
| chain got patched on one of the best platforms for hardware
| mitigations.
|
| I think LLMs get us meaningfully closer to what I thought this
| work already was when I was 18 and didn't know anything.
| cartoonworld wrote:
| lots of security issues form at the boundaries between
| packages, zones, services, sessions, etc. Static analysis could
| but doesn't seem to catch this stuff from my perspective. Bugs
| are often chains and that requires a lot of creativity,
| planning etc
|
| consider logic errors and race conditions. Its surely not
| impossible for llm to find these, but it seems likely that
| you'll need to step throught the program control flow in order
| to reveal a lot of these interactions.
|
| I feel like people consider LLM as free since there isn't as
| much hand-on-keyboard. I kinda disgree, and when the cost of
| paying out these vulns falls, I feel like nobody is gonna wanna
| eat the token spend. Plenty of hackers already use ai in their
| workflows, even then it is a LOT OF WORK.
| Legend2440 wrote:
| Catching all bugs with static analysis would involve solving
| the halting problem, so it's never going to happen.
| IsTom wrote:
| A lot of software doing useful work halts pretty trivialy,
| consuming inputs and doing bounded computation on each of
| them. You're not going to recurse much in click handlers or
| keep making larger requests to handle the current one.
| badgersnake wrote:
| Another boring AI hype article.
|
| "The next model will be the one. Trust me. Just one more
| iteration."
| streetfighter64 wrote:
| > Is the Linux KVM hypervisor connected to the hrtimer subsystem,
| workqueue, or perf_event? The model knows.
|
| I asked ChatGPT and it claimed "all three". Any linux wizards who
| can confirm or deny?
|
| Anyway, in my experience using mainly the Claude chat to do some
| basic (not security) bug hunting, it usually fixates on one
| specific hypothesis, and it takes some effort to get it off that
| wrong track, even when I already know it's barking up the wrong
| tree.
| tptacek wrote:
| It's all three, I just had it on the brain when I was writing
| this.
| streetfighter64 wrote:
| Hm, kind of a strange question then, no? Is a car's engine
| connected to the fuel tank, the wheels or the accelerator
| pedal?
| tptacek wrote:
| I don't know, maybe it is? My point is just that frontier
| models start off with latent models of all the
| interconnectivity in all the important open-source
| codebases, to a degree that would be infeasible for the
| people who learned how all the CSS object lifecycles and
| image rendering and unicode shaping stuff worked well
| enough to use them in exploits.
| jgeralnik wrote:
| The wonderful thing though is that you can just run the model
| multiple times (even in parallel). Some instances might get
| stuck but as long as some find the bug and you have a good way
| to filter outputs (e.g. with another llm that tries to create
| concrete exploits) even a very small success rate on stage 1
| can lead to reliable exploits
| staticassertion wrote:
| > Everything is up in the air. The industry is sold on memory-
| safe software, but the shift is slow going. We've bought time
| with sandboxing and attack surface restriction. How well will
| these countermeasures hold up? A 4 layer system of sandboxes,
| kernels, hypervisors, and IPC schemes are, to an agent, an
| iterated version of the same problem. Agents will generate full-
| chain exploits, and they will do so soon.
|
| I think this is the interesting bit. We have some insanely
| powerful isolation technology and mitigations. I can put a
| webassembly program into a seccomp'd wrapper in an unprivileged
| user into a stripped down Linux environment inside of
| Firecracker. An attacker breaking out of that feels like science
| fiction to me. An LLM could do it but I think "one shots" for
| this sort of attack are extremely unlikely today. The LLM will
| need to find a wasm escape, then a Linux LPE that's reachable
| from an unprivileged user with a seccomp filter, then once they
| have kernel control they'll need to manipulate the VM state or
| attack KVM directly.
|
| A human being doing those things is hard to imagine. Exploitation
| of Firecracker is, from my view, extremely difficult. The bug
| density is very low - code quality is high and mitigation
| adoption is a serious hurdle.
|
| Obviously people aren't just going to deploy software the way I'm
| suggesting, but even just "I use AWS Fargate" is a crazy barrier
| that I'm skeptical an LLM will cross.
|
| > Meanwhile, no defense looks flimsier now than closed source
| code.
|
| Interesting, I've had sort of the opposite view. Giving an LLM
| direct access to the semantic information of your program, the
| comments, etc, feels like it's just handing massive amounts of
| context over. With decompilation I think there's a higher risk of
| it missing the intention of the code.
|
| edit: I want to also note that with LLMs I have been able to do
| sort of insane things. A little side project I have uses iframe
| sandboxing _insanely_ aggressively. Most of my 3rd party
| dependencies are injected into an iframe, and the content is
| rendered in that iframe. It can communicate to the parent over a
| restricted MessageChannel. For cases like "render markdown" I
| can even leverage a total-blocking CSP within the sandbox.
| Writing this by hand would be silly, I can't do it - it's like
| building an RPC for every library I use. "Resize the window" or
| "User clicked this link" etc all have to be written individually.
| But with an LLM I'm getting sort of silly levels of safety here -
| Chrome is free to move each iframe into its own process, I get
| isolated origins, I'm immune from supply chain vulnerabilities,
| I'm immune to _mostly_ immune to XSS (within the frame, where
| most of the opportunity is) and CSRF is radically harder, etc.
| LLMs have made adoption of Trusted Types and other mitigations
| insanely easy for me and, IMO, these sorts of mitigations are
| more effective at preventing attacks than LLMs will be at finding
| bypasses (contentious and platform dependent though!). I suppose
| this doesn 't have any bearing on the direct position of the blog
| post, which is scoped to the new role for vulnerability research,
| but I guess my interest is obviously going to be more defense
| oriented as that's where I live :)
| MajesticHobo2 wrote:
| > With decompilation I think there's a higher risk of it
| missing the intention of the code.
|
| I'm not sure but suspect the lack of comments and documentation
| might be an advantage to LLMs for this use case. For
| security/reverse engineering work, the code's actual behavior
| matters a lot more than the developer's intention.
| staticassertion wrote:
| I think the other side of that is that mismatches between
| intention and implementation are exactly where you're going
| to find vulnerabilities. The LLM that looks at closed source
| code has to guess the intention to a greater degree.
| moyix wrote:
| This is true for a lot of things but for low-level code you
| can always fall back to "the intention is to not violate
| memory safety".
| staticassertion wrote:
| That's true, but certainly that's limiting. Still, even
| then, `# SAFETY:` comments seem extremely helpful. "For
| every `unsafe`, determine its implied or stated safety
| contract, then build a suite of adversarial tests to
| verify or break those contracts" feels like a great way
| to get going.
| moyix wrote:
| It's limiting from the PoV of a developer who wants to
| ensure that their own code is free of all security
| issues. It is not limiting from the point of view of an
| attacker who just needs one good memory safety vuln to
| win.
| rubiquity wrote:
| I was distracted by the picture of the ingredients to a Final
| Ward being at the top of the page.
| narginal wrote:
| Just like how fuzzers will find all the bugs, right? Right??
| There's definitely infrastructure at these big companies that
| isn't sitting in a while loop 'fuzzing' right? Why is it news
| that vulnerability research will continue to get harder, exactly?
| It has always been this way, exploits will get more expensive,
| and the best researchers will continue with whatever tools they
| find useful.
| tptacek wrote:
| It's a good question. Fuzzers generated a surge of new
| vulnerabilities, especially after institutional fuzzing
| clusters got stood up, and after we converged on coverage-
| guided fuzzers like AFL. We then got to a stable equilibrium, a
| new floor, such that vulnerability research & discovery doesn't
| look that drastically different after fuzzing as before.
|
| Two things to notice:
|
| * First, fuzzers also generated and continue to generate large
| stacks of unverified crashers, such that you can go to archives
| of syzkaller crashes and find crashers that actually work. My
| contention is that models are not just going to produce
| hypothetical vulnerabilities, but also working exploits.
|
| * Second, the mechanism 4.6 and Codex are using to find these
| vulnerabilities is nothing like that of a fuzzer. A fuzzer
| doesn't "know" it's found a vulnerability; it's a simple
| stimulus/response test (sequence goes in, crash does/doesn't
| come out). Most crashers aren't exploitable.
|
| Models can use fuzzers to find stuff, and I'm surprised that
| (at least for Anthropic's Red Team) that's not how they're
| doing it yet. But at least as I understand it, that's generally
| _not_ what they 're doing. It something much closer to static
| analysis.
| staticassertion wrote:
| I suspect we'll see combinations of symbolic execution +
| fuzzing as contextual inputs to LLMs, with LLMs delegating
| highly directed tasks to these external tools that are
| radically faster at exploring a space with the LLM guiding
| based on its own semantic understanding of the code.
|
| I'm with you, I expected this to be happening already. Funny
| enough, I guess even a hardened codebase isn't at that level
| of "we need to optimize this" currently so you can just throw
| tokens at the problem.
| tptacek wrote:
| Right, so that's exactly how I was thinking about it
| _before_ I talked to Carlini. Then I talked to Carlini for
| the SCW podcast. Then I wrote this piece.
|
| I don't know that I'm ready to say that the frontier of
| vulnerability research with agents is modeling, fuzzing,
| and analysis (orchestrated by an agent). It may very well
| be that the models themselves stay ahead of this for quite
| some time.
|
| That would be a super interesting result, and it's the
| result I'm writing about here.
| narginal wrote:
| I have just seen too much infrastructure set up to 'find
| bugs,' effectively sitting and doing nothing- either the
| wrong thing gets audited, or tons of compute gets thrown at a
| code base and nobody ever checks in on or verifies.
|
| This seems like a human/structural issue that an AI won't
| actually fix - attackers/defenders alike will gain access to
| the same models, feels a little bit like we are back to
| square one
| tptacek wrote:
| If that's true, and if patches can effectively be pushed
| out quickly, then the results of this will be felt mostly
| by vulnerability researchers, which is the subject of the
| piece. But those are big "ifs".
| stackghost wrote:
| I was doing TryHackMe's "advent of cyber" sidequest last
| christmas and used a process very much like Carlini's that is
| outlined in TFA.
|
| >I'm doing a CTF. I popped a shell on this box and found this
| binary. Here is a ghidra decompilation. Is there anything
| exploitable in $function?
|
| You can't just ask Claude or ChatGPT to do the binex for you, but
| even last year's models were really good at finding heap or stack
| vulns this way.
| thadt wrote:
| So the intersting question: are we long term safer with "simpler"
| closer to hardware memory unsafe(ish) environments like Zig, or
| is the memory safe but more abstract feature set of languages
| like Rust still the winning direction?
|
| If a hypothetical build step is "look over this program and
| carfully examine the bounds of safety using your deep knowledge
| of the OS, hardware, language and all the tools that come along
| with it", then a less abstract environment might be at an overall
| advantage. In a moment, I'll close this comment and go back to
| writing Rust. But if I had the time (or tooling) to build
| something in C and test it as thoroughly as say, SQLite [1], then
| I might think harder about the tradeoffs.
|
| [1] https://sqlite.org/whyc.html
| love2read wrote:
| What about this article raises this question? If anything, this
| article makes it pretty clear that memory safe languages are a
| win. It seems like a serious disadvantage to require a
| nondeterministic program to evaluate your code's safety.
| tonymet wrote:
| I agree AI makes exploits more accessible, it also makes pen-
| testing and finding vulns more accessible, in both early and late
| stages of product development.
|
| AI has saved me a ton of money and time auditing. Mostly because
| I'm tired / lazy.
|
| It's both a black pill & white pill, and if we have the right
| discipline, a tremendous white pill. Engineers can no longer
| claim to be "cost effective" by ignoring vulns.
| rkrbaccord94f wrote:
| The pipewire-libs package local address function refers to
| alsa_output.pci
|
| Driver benchmarking the pipewire script calls three local ports:
|
| local.source.port = 10001
|
| local.repair.port = 10002
|
| local.control.port = 10003
| samuelknight wrote:
| LLMs are expert hackers because: 1) They are expert coders,
| including a decently comprehensive CVE knowledge 2) They know
| every programming language/framework/stack 3) They know every
| human language
|
| They already have super human breadth and attention. And their
| depth is either super human or getting there.
|
| The state of the security industry through 2025 was expensive
| appsec human reviewers or primitive scanners. Now you can spend a
| few dollars and have an expert intelligence scrutinize a whole
| network.
| gdulli wrote:
| So much of the current internet is posts that read as a
| superposition of sincere and parody, and until that's resolved
| how do you know how to respond?
| saltcured wrote:
| Just wait until you see the same showing up in compliance
| realms...
|
| Edit: to be slightly less implicit, consider the cargo cult
| madness that erupts from people thinking they can address
| risk management and compliance by auto-generating
| documentation and avoid really doing the legwork.
| samuelknight wrote:
| If that was a jab it my writing then yes, I am absolutely
| being sincere because I am an expert on this topic. LLMs went
| from being ok at one-shoting a function a to being so good at
| hacking that it's difficult to evaluate them. Prospective
| customers get back to us after a demo and tell us about the
| exploits it found on their services that are so vague and
| technical that they wouldn't think to look for them.
| vibe42 wrote:
| If everyone is running the same models, does this not favour
| white hat / defense?
|
| Since many exploits consists of several vulnerabilities used in a
| chain, if a LLM finds one in the middle and it's fixed, that can
| change a zero day to something of more moderate severity?
|
| E.g. someone finds a zero day that's using three vulns through
| different layers. The first and third are super hard to find, but
| the second is of moderate difficulty.
|
| Automated checks by not even SOTA models could very well find the
| moderate difficulty vuln in the middle, breaking the chain.
| anematode wrote:
| Ya, I tend to believe that (most) human VR will be obsoleted well
| before human software engineering. Software engineering is a lot
| more squishy and has many more opportunities to go off the rails.
| Once a goal is established, the output of VR agents is
| verifiable.
| GTP wrote:
| > The new models find real stuff. Forget the slop; will projects
| be able to keep up with a steady feed of verified, reproducible,
| reliably-exploitable sev:hi vulnerabilities?
|
| If LLMs are as capable as said in the article, there will be an
| initial wave of security vulnerabilities. But then, all
| vulnerabilities will be discovered (or at least, LLMs will not
| find any more), and only new code will introduce new
| vulnerabilities. And everyone will be using LLMs to check the new
| code. So, regardless of what they say is correct or not, the
| problem doesn't really exist.
| m132 wrote:
| A hard read for a skeptic like me. A lot of speculation and
| extrapolation of a trend, not to say outright exaggeration, but
| very little actual data. Let's not forget that we're at the tip
| of an economic bubble, and what you're writing about is at the
| very center of it!
|
| For what it's worth, I read Anthropic's write-up of their recent
| 0-day hunt that most of this post seems to be based on, and I
| can't help but notice that (assuming the documented cases were
| the most "spectacular") their current models mostly "pattern-
| matched" their ways towards the exploits; in all documented
| cases, the actual code analysis failed and the agents redeemed
| themselves by looking for known-vulnerable patterns they
| extracted from the change history or common language pitfalls.
| So, most of the findings, if not all, were results of rescanning
| the entire codebase for prior art. The corporate approach to
| security, just a little more automated.
|
| Hence I agree with "the smartest vulnerability researcher"
| mentioned near the end. Yes, the most impactful vulnerabilities
| tend to be the boring ones, and catching those fast will make a
| big difference, but vulnerability research is far from cooked. If
| anything, it will get much more interesting.
| miki123211 wrote:
| I think our saving grace is the fact that, especially in these
| hardened environments, it's a lot easier to find exploitable bugs
| than to actually exploit them.
|
| As the defenders will have access to the same agents as the
| attackers, everybody will (mostly) find the same bugs. If recent
| trends continue[1], it's likely that major labs will make new
| models available to defenders first, making the attackers' jobs
| even harder.
|
| What really worries me is models quickly developing exploits
| based on freshly-released patches, before most people had a
| chance to update. Big cloud vendors will likely have the ability
| to coordinate and deploy updates before the commits hit Github,
| smaller enterprise on-prem environments won't have that luxury.
___________________________________________________________________
(page generated 2026-03-30 23:01 UTC)