Rendered at 01:32:27 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
enthuseyourcurb 22 minutes ago [-]
As someone working at a bigtech co that has spent every single working day (and many weekends) since the launch of Mythos patching serious, company-ending type of security issues, these types of posts really irk me.
Public datasets of CVEs being underwhelming doesn't mean much if all of the issues are in private company codebases that will never get a CVE number assigned and will never get a fancy blog post. You're never going to hear about them, and the people working on them probably can't tell you about them, but that doesn't mean they don't exist.
We're all worried about OSS having security issues because of how widely used things like PHP or curl are... but the same can be said about email providers, document collaboration SaaSes, payment processors, etc that millions of companies depend. Those companies will never be in datasets like this, and they'll never publicly disclose how many issues they found.
levocardia 19 minutes ago [-]
Yeah I am much more worried about some critical vulnerability in, say, the controller logic for pumps at sewage treatment facilities vs. a sandbox break in Chrome (which will be patched well before the blog post...). The broad issue is that you can turn DeepSeek-v6-unhinged loose on an arbitrary IP and exploit ~everything that is not developed and actively maintained by a billion-dollar company
swatcoder 13 minutes ago [-]
That's a very fair point that I agree a lot of people here are neglecting.
It's also fair comeuppance for 14 years of "move fast and break things". For longer than many people have been working in the industry, leading technical figures -- not just clueless executives -- were loudly encouraging terrible engineering practices as the right choice or the only choice for how to write software.
I'm sorry you have to pay your predecessor's debts, but I'm glad they're finally being paid. There are worse ways the bills could have come due.
da02 12 minutes ago [-]
Have you seen any patterns for the causes of the error you have seen? For example, more training for developers? Or maybe just systems were really very complex that led to bugs?
Choad_20261104 16 minutes ago [-]
as a bystander not even working in the sector, your witnessing is exactly what I was worried for.
if an agent is wily enough to defeat a security it should also be wily enough to cover its tracks, otherwise what's the point?
pizlonator 2 minutes ago [-]
I received 9 reports of Fil-C issues from Anthropic
All of them were real bugs. None of them were false positives.
The quality of the reports was exceptional. (My baseline is doing security defense on a browser engine, so my baseline has a large sample count and is probably representative of what experts are capable of.)
The quality of the proposed fixes was alright. I took some of the fixes verbatim. I used most of the fixes as significant inspiration for doing it myself way.
The quality of the test cases was exceptional.
Maybe I’m special somehow! But I just want to call out the enormous chasm between what I saw of anthropic’s capability and what TFA says
snowwrestler 1 hours ago [-]
The PHP2Shell vulnerability ended up being paradoxically comforting for me.
They turned frontier models loose on PHP, and the big one they found was based on a previously known logic flaw that was extremely difficult to exploit. Which makes sense: hence the need for frontier models.
And in the wild, while there have been many attempts and a few simple demo successes, the practical impact has seemed to be small, seemingly constrained by the length of the chain and the diversity of PHP configs.
In short, it was indeed a major vulnerability, but not magic (in the Arthur C Clarke sense).
I think ultimately the fear comes down to: do you believe that code can be secured. I recognize that there is probably no objective way to deductively prove it because of the Halting Problem etc. But if one believes code can be constructed to operate to spec, then there must be a limit to the damage an LLM can do, even a very smart one.
I think we are going through a phase where a lot of known triaged code shortcomings will get exposed and hopefully fixed. Sucks while it is happening. But not actually the first round of this type of evolution. And ultimately I think as before, we will come out the other side with more secure and durable technology.
Den_VR 17 minutes ago [-]
The halting problem is a product of a Turing-complete model of computation.
If we want perfectly secure systems, then perhaps we don’t want universal and general purpose ones.
soulofmischief 31 minutes ago [-]
I think the more fundamental question than "can code be secured" is something along the lines of "can we properly measure the security of the various components of a sufficiently codebase". Security consultants have workflows but ultimately everything is ad-hoc and suffers from cominatorial explosion, and what's missing is the security equivalent of Lean, a real formalized effort to prove security. There have been many attempts, of course. One of the great problems of our era.
timr 33 minutes ago [-]
Thus far, these agent vulnerabilities are all demonstrating million-monkey intelligence, rather than "super" intelligence, in the sense of some swarm of robo-Neo super hackers.
That's consistent with my experience using them for coding, where even the best models mostly work by being persistently midwit (with infinite knowledge) more than individually brilliant.
One corollary of this is probably that any project that has had an army of actual monkeys pounding on it for years is likely more resistant to LLM attack than one that has not. Everyone is worrying about individual robot geniuses finding obscure vulnerabilities in Linux, PHP, Python, etc., but they should probably be more worried about the permutations of less-known software floating around their systems.
i2talics 25 minutes ago [-]
> and hoppefully fixed.
Well, the report you're replying to doesn't make me so hopeful: "7349 findings made public, 217 (.5%) fixed"
arlattimore 1 minutes ago [-]
The post seems misguided or misdirected in my opinion. Not discounting the fact that the frontier models may find existing bugs, that some are labelled at the incorrect level, even some being a non-bug -- fact remains they are discovering vast numbers of issues. It also isn't the job of Anthropic or OpenAI to fix everyone's bugs, they are doing everyone a courtesy to spend their time identifying them in the first place. The bigger issue appears to be that they are finding more bugs than the developer capacity to can address.
rurcliped 14 minutes ago [-]
The blog is misleading because it tries to characterize Project Glasswing's effectiveness through use of a tangentially related data source. A Project Glasswing vulnerability discovery most often occurs when a Glasswing partner points a Mythos-class model at its own, often proprietary, software. The data source (aka "ledger") is only for the Anthropic coordinated vulnerability disclosure program for open source software: in other words, Anthropic itself pointing a Mythos-class model at an OSS package, and then notifying the maintainer afterward that it had done this, and had findings to share. This OSS work is certainly useful, but the number of fixes reflects - in part - limited time availability by volunteer OSS maintainers, and Anthropic sometimes working without knowledge of the OSS project's threat model (the threat model is explicitly requested in the newer oss-scanner effort). Percentage fixed is often much higher for use of Glasswing with proprietary software, e.g., https://blog.cloudflare.com/cyber-frontier-models/ "Our research with Mythos Preview was conducted in a controlled environment against our own code; every vulnerability surfaced through this work was triaged, validated, and remediated where action was needed under Cloudflare's formal vulnerability management process."
dfee 3 hours ago [-]
There's an anecdote about curl, but I'm not sure if there's enough in here to draw conclusions from. 20% of vulnerabilities have been made public, and many of those are marked as "withdrawn" or "duplicates". However, it's unclear whether the remaining 80% have not been made public because they're not fixed or real. In other words, this is analysis of survivors (public); not much can be said about those still under embargo.
ASalazarMX 1 hours ago [-]
I'd expect the remaining 80% are delayed not because there's something statistically special about them, but from the massive workload thrown at humans in the loop.
Anthropic needs to teach their systems to propose a fix too. Detecting a coding problem and proposing a patch is what we should expect from a company with supposedly the best coding LLM.
loeg 1 hours ago [-]
> Anthropic needs to teach their systems to propose a fix too. Detecting a coding problem and proposing a patch is what we should expect from a company with supposedly the best coding LLM.
Of course it's trivial to have an LLM generate a fix, too. They probably do. It doesn't mean a project (1) wants to take an LLM-generated fix at all, or (2) can immediately commit an LLM-generated fix without review (which takes time).
MBCook 28 minutes ago [-]
Maybe not. And that’s totally fine.
But right now they’re not even offering one. They’re just putting the burden on the project without even trying to help fix it.
They have all the resources in the world, and they won’t even try.
And that’s of course assuming it’s a real bug, as we’ve seen a ton of them don’t seem to be. The last time we went through this, curl reported not only that a bunch of them weren’t bugs, but some of the bugs were listed previously on their mailing list, and that’s probably where the LLM got them.
So not only is it finding small bugs. And nonbugs. It’s reporting previously found bugs.
Pilling work on maintainers. Over and over again. To help? No. To make big numbers to show off for their IPO documents.
doctorpangloss 49 minutes ago [-]
Punchline: Don't use curl.
ameliaquining 1 hours ago [-]
Claude is perfectly capable of fixing most vulnerabilities; if that's what maintainers want, they can just ask for it. If the concern is cost, Anthropic offers a Claude for OSS program.
The reason Anthropic isn't proactively sending patches is, I suspect, that those patches would not be welcomed, because trust in the models isn't currently at the point where maintainers are willing to merge them without human review, which takes approximately as much effort as writing the patches themselves. You can imagine the wailing and gnashing of teeth about "slop PRs" and "extractive contributions" that'd be all over HN.
eqvinox 25 minutes ago [-]
Anthropic's oss-scanner includes patches. We've received a batch and I'm working on some of it.
A good amount of the patches is straight garbage. It's not helped by the fact that a good amount (20~30%, maybe more) of the issues is also junk themselves.
I'll hopefully be able to share numbers (or data) after we're done with the batch.
wonnage 1 hours ago [-]
Could also be that most of the findings are low signal noise. Even the batch that was sent to curl was one medium and 39 low severity. One can only assume that the vast numbers of findings that haven’t been sent are even lower severity.
flanz_10 2 hours ago [-]
And on top of that, it's a bit negative. How many millions of dollars is one perfect-10 scoring CVSS finding, total destruction style RCE, found in curl worth? Considering how many people use it.
uptrails 2 hours ago [-]
It's worth zero millions dollars to curl. It might be worth something to attackers, but "wide use" is not the same as "the ability to compromise everyone" because most of the time, curl isn't used to automatically fetch untrusted URLs in a way that's controlled by the attacker from an environment they care about. It's worth much, much less than a 0-day in an iPhone or PHP. You'd need a buyer with a very specific itch to scratch and there won't be a bidding war.
By extension, if a vuln is worth something to attackers, it's probably also worth some fraction of it to their potential victims. But if you're an interesting target, your defense can't be based on the ability to find out about every single software defect ahead of the time. You need layers. And if you have that, the importance of proactively acquiring every 0-day is diminished.
Eridrus 2 hours ago [-]
A client-side bug in a command line utility that is mostly used as a debugging tool or glue in shell scripts where the URL is not attacker controlled? Probably close to nothing. Maybe if you can find some other software which lets you run curl with an attacker controlled URL, you could package it up as an exploit for that piece of software, but it's not a common config.
palata 2 hours ago [-]
Curl is also a library. Just saying :-).
Eridrus 59 minutes ago [-]
Fair, libcurl is pretty widely used in PHP, but it has to be in the core.
Still way less impactful than the PHP2Shell issue.
jknoepfler 1 hours ago [-]
The most likely explanation is that it isn't worth submitting a massive stack of bullshit to human review.
If they actually were sitting on a PR gold mine of vulnerabilities they wouldn't be throttled on review resources while artificially inflating/misreporting their numbers. They would be diverting resources to clear the review queue.
It's fake and it always was fake.
sigmar 8 minutes ago [-]
> So far, only 2 of the 442 have been exploited in the wild, just 0.45%.
> almost none are being exploited
Isn't the whole point of glasswing to patch stuff way before it can be exploited? If the patched code is distributed quickly- there's no opportunity (or incentive) for bad actors to craft and distribute an exploit. This reads like an attempt to spin them as not being "real" vulnerabilities.
delichon 3 hours ago [-]
It is bad if this points to a general pattern of AI being better at finding than fixing vulnerabilities. The larger that ratio, the harder to secure all the things. The current stat from this experiment is 37,966 to 217. Lots of false positives, but not enough to change the big picture. I hope they didn't apply equivalent tokens to both sides, or AI may be better at demolition than construction.
shiandow 2 hours ago [-]
So far the trend is pointing to AI being better at finding problems than designing software to avoid them.
Which I'm fine with really, but it means you need to be very careful letting it iterate on code until it finds no problems.
RugnirViking 2 hours ago [-]
If anyone here hasn't experienced agents going into a loop finding "problems" and "fixing" them by adding more brittle complexity which introduces 10 more problems I'd be surprised. It's like the biggest experience of working with agents RN
The worst part is being thorough takes so much more work - they often do raise valid problems but you just can't set them in a loop because of this tendancy so you end up with way more work and hard questions
canpan 1 hours ago [-]
It is my biggest problem now: AI is very good at adding things. It does not notice that things can be removed.
This is true for both code and prose. Even when it does notice something wrong, it wont remove it, but keep the sentence and make it longer.
"This is A" -> "This is B, not A"
It makes it incredibly hard to write plans and documents and maintain code.
When I tell it that the file is getting overlong and complex, unless I mention explicitly each single point, it just plainly doesn't see the problems and instead removes important bits. I did not yet find the right wording to express it to AI in an automated way.
radlad 1 hours ago [-]
I have a "review panel" skill, that will do multiple rounds. But after two rounds, it looks for hot spots. If hot spots are found, it triggers a "big picture" design review.
It's been helpful.
RugnirViking 1 hours ago [-]
yeah, thats similar to our current approach. It was inspired by a blog post from anthropic where they talked about the same kinda idea, where iirc after 3 rounds the author is asked to rearchitect.
The only other bit we also stole from that was the idea of only looking for issues in the original diff rather than spawning new problems from each diff fixing the previous. Of course the possibility exists of bugs being introduced while fixing others but we try to handle that with human review for the minute because its not worth getting agents to cover that bit, at least with naive approaches
senderista 1 hours ago [-]
So true, I had to learn this the hard way. I ended up doing a convergence review after each loop iteration and suggesting scope to cut where findings were diverging.
jack_pp 1 hours ago [-]
have you tried modularizing / breaking down your code into different files (ideally each having functional code so they don't depend much on anything else) as much as possible?
wasabi991011 32 minutes ago [-]
That's my biggest issue with it personally, as an academic. Way too much unnecessary indirection that makes it harder to read and understand the assumptions and parameters going into the code, and unnecessary defensive programming for code that is just going to be run a few different ways with strictly controlled inputs.
RugnirViking 1 hours ago [-]
are you suggesting this because you think I haven't tried it? I'm genuinely confused. We are professional developers working with a team of more than 1 person. Yes we have code in multiple files and have heard of the basic ideas of software architecture.
It's like being asked if i'm using source control? It's kinda a given if you're doing more than hobby projects.
jack_pp 51 minutes ago [-]
I'm saying lean more into it, to the extreme and instruct your models to do the same
wasabi991011 31 minutes ago [-]
How would that help with the raised issue?
jack_pp 17 minutes ago [-]
Smaller the function, less ways to screw it up, for humans and llms alike. I suspect humans don't code like this because it is too tedious but LLMs don't have such problems
ASalazarMX 1 hours ago [-]
Coding is hard. I wouldn't be surprised if any patch they suggest came with new bugs, as it often happens with humans.
gunalx 2 hours ago [-]
It'll never scew to far of as long as defence is a RL target. Better red team just means the blue team has stronger target environmenta to RL for.
hologramofham 3 hours ago [-]
> Of Anthropic’s 37,966 reported findings, only 7,349 (19.4%) have been made public and just 217 have been marked fixed.
So the article is making a sweeping statement based on the 19.4% of publicly disclosed CVEs?
That statistic suggests the opposite. I'm sure government is aware of many back doors they keep secret and prefer them to remain secret.
milkshakes 3 hours ago [-]
"public" here has nothing to do with government holding on to vulns. it's about landing fixes and coordinating complicated / impactful findings
Sharlin 43 minutes ago [-]
You really think Anthropic would publish stats that say "Yeah, we've found 40k vulns but are going to keep 80% of them to ourselves [and the govt] because those are all the juicy ones"?
Very interesting that the conclusion of the article is so tightly aligned with the VulnCheck's business model! It's almost as if this is just a thinly veiled advertisement...
> The CVEs are a sliver of this year's total, almost none are being exploited, fixes have stalled while duplicates and withdrawals pile up, and the triage burden is shifting onto the open source maintainers Glasswing promised to help. The receipts keep coming in. They still don't reconcile.
> VulnCheck is helping organizations not just to solve the vulnerability prioritization challenge - we’re working to help equip any product manager, CSIRT/PSIRT or SecOps team and Threat Hunting team to get faster and more accurate with infinite efficiency using VulnCheck solutions.
janalsncm 25 minutes ago [-]
Hard not to draw parallels with Deepmind’s GNoME project which found millions of new “materials” most of which turned out to already exist or be garbage basically.
The common thread is asking humans to do the verification work, which is the hard part.
fny 3 hours ago [-]
I think the most obvious chicken little sign has been that we've had no catastrophic exploits in the past year due these findings.
Sure LLMs have helped reduce the attack surface and we patch things faster too, but I was really expected a few more Supermarket-level bangers.
Lerc 24 minutes ago [-]
That seems like a damnned if you do and damnned if you don't situation.
There were conflicting claims about the degree to which the $6 Billion Binance heist was an AI thing. But either way it seems like it would be a "look what it enabled" or a look what it failed to prevent"
If nothing happens at all it's waved away as scaremongering rather than prevention.
tensor 14 minutes ago [-]
I don't understand, it seems like every week there is a new major breach. Multiple law firms have had unprecedented breaches, dev platforms, and companies of every kind. You name it, there's been a high profile breach.
At the point I wonder if there is any information left secure honestly. These are not from glasswing, but they are from LLMs.
cowlevel 2 hours ago [-]
There was that PHP thing, as well as *sshole, and how do we know the supermarket attackers didn't use AI?
plorkyeran 44 minutes ago [-]
While I'm not going to claim the PHP thing wasn't a real vulnerability, it... doesn't seem to have actually been catastrophically exploited? Maybe it's just too soon and over the next year we'll see a steady stream of people announcing leaks caused by failing to update php in time? Maybe there's a bunch of servers out there running old version of wordpress and quietly mining bitcoin because of it?
watwut 2 hours ago [-]
But PHP thing was a lot of drama over something that was not super large easy to exploit hole. Just a normal "have to patch it and bye" medium kind issue.
spartanatreyu 51 minutes ago [-]
> Just a normal "have to patch it and bye" medium kind issue.
Patching it was the issue, not the hole.
1. The patches had to be unofficially backported to the versions of php that most people were using.
2. Devs had to figure out if the unofficial backports were safe and they weren't just falling into trapped versions
3. Devs had to migrate all of their projects to unofficial versions
4. No one was ready for it to happen because there was no advance notice (someone broke the embargo) for everyone to plan maintenance windows and upgrade at the same time.
tptacek 2 hours ago [-]
People say this vulnerability was "not super large easy to exploit" because of one poorly-informed skeptical blog post that hit the top of HN, but the evidence strongly suggests that post was simply wrong, and we're just going to have to live with the misinformation until it decays.
At this point the play is simply to move the goalposts, suggesting that vulnerabilities don't matter so long as you yourself couldn't easily exploit them, regardless of what well-armed attackers can do with them. That's, obviously, not how software security works.
tialaramex 50 minutes ago [-]
> the evidence strongly suggests that post was simply wrong
What sort of evidence? What "strongly suggests" this was actually easy to exploit?
tptacek 44 minutes ago [-]
I'm not interested in arguing with you about whether e.g. Dan Guido is a credible source of exploitation information.
snowwrestler 55 minutes ago [-]
Are there better sources for understanding the scope of impact enabled by PHP2Shell? My impression from a variety of sources is that very few incidents can be clearly attributed to that vulnerability. As opposed the many other ol’ ways PHP applications get exploited.
keybored 2 hours ago [-]
But imagine the potential fallout if so many services didn’t get so scared that they preemptively took themselves offline.
Apply sarcasm or not based on sleep deprivation.
qnleigh 1 hours ago [-]
Given how fast progress has been in the last year, be careful what you wish for...
For example, as others have noted, there were no results on cryptography in OpenAI's October 6th math drop. But it seems unlikely that they didn't look at this sort of thing.
stavros 2 hours ago [-]
We've had catastrophic vulnerabilities revealed every other day for months, what are you talking about?
28 minutes ago [-]
TheCoelacanth 2 hours ago [-]
Vulnerabilities and exploits are different things.
stavros 2 hours ago [-]
You mean like Notion being breached, refrigerators being turned off, that kind of thing?
flanz_10 2 hours ago [-]
Those are exploits. They are different from vulnerabilities.
stavros 2 hours ago [-]
Yeah, I know, and we've had a deluge of both lately. I'm not sure what constructive point you're making.
beepbooptheory 2 hours ago [-]
You can have a lot of vulnerabilities without necessarily having working exploits to them, so it matters if it's just a lot of vulnerabilities without a lot of exploits.
sfink 14 minutes ago [-]
Assume the original message said "exploits" in place of "vulnerabilities". The point stands, independent of pedantic terminology corrections.
The correction is valid. It would be better if people used the right term. It's ok to correct. But it would be better if it were in addition to discussion of the actual point, not instead of it.
(And the phrase "catastrophic vulnerabilities" is pretty obviously talking about exploits anyway.)
tensor 13 minutes ago [-]
But we've had both. Soooo?
28 minutes ago [-]
greatgib 2 hours ago [-]
In my opinion, what tells a lot about AI provider AGI claims versus reality is the difficulty to have LLM provide the fix to issues.
For PHP2shell vulnerability for example, there was "patched" .deb (and equivalent) packages only for the most recent and most trendy distributions but countless older versions of distributions and php versions were like abandoned without simple solution.
I would have guess that "patches" and pre-built fixed packages would be flooding the world. And with just a prompt of one line, most servers would be properly patched. But no.
Lerc 31 minutes ago [-]
Which AGI claims are these specifically?
I find it hard to assess when people mention false claims when I can't find what the claims were to determine what about them might be false.
pratzc07 1 hours ago [-]
Expected this to happen maintainers overloaded with issues majority of which are nothing burgers.
epsteingpt 1 hours ago [-]
AI models generating slop findings? Who ever could have predicted this?!
sick_of_slop 2 hours ago [-]
[dead]
kylestanfield 45 minutes ago [-]
There was a lot of hype early this year. Mythos, openclaw, gastown. And now they’re basically completely irrelevant. Things move so fast.
y1n0 30 minutes ago [-]
They do move fast, but if anything, your examples show you can ignore a lot of it.
unethical_ban 2 hours ago [-]
Does the author expect that every company using Glasswing/AI is going to credit the AI directly? I would not expect Microsoft or Cisco to credit Anthropic if one of their internal teams uses AI to discover a CVE in their code.
tjmtjmtjm 1 hours ago [-]
Attribution/reporting is probably part of the conditions for these companies to get access.
Public datasets of CVEs being underwhelming doesn't mean much if all of the issues are in private company codebases that will never get a CVE number assigned and will never get a fancy blog post. You're never going to hear about them, and the people working on them probably can't tell you about them, but that doesn't mean they don't exist.
We're all worried about OSS having security issues because of how widely used things like PHP or curl are... but the same can be said about email providers, document collaboration SaaSes, payment processors, etc that millions of companies depend. Those companies will never be in datasets like this, and they'll never publicly disclose how many issues they found.
It's also fair comeuppance for 14 years of "move fast and break things". For longer than many people have been working in the industry, leading technical figures -- not just clueless executives -- were loudly encouraging terrible engineering practices as the right choice or the only choice for how to write software.
I'm sorry you have to pay your predecessor's debts, but I'm glad they're finally being paid. There are worse ways the bills could have come due.
All of them were real bugs. None of them were false positives.
The quality of the reports was exceptional. (My baseline is doing security defense on a browser engine, so my baseline has a large sample count and is probably representative of what experts are capable of.)
The quality of the proposed fixes was alright. I took some of the fixes verbatim. I used most of the fixes as significant inspiration for doing it myself way.
The quality of the test cases was exceptional.
Maybe I’m special somehow! But I just want to call out the enormous chasm between what I saw of anthropic’s capability and what TFA says
They turned frontier models loose on PHP, and the big one they found was based on a previously known logic flaw that was extremely difficult to exploit. Which makes sense: hence the need for frontier models.
And in the wild, while there have been many attempts and a few simple demo successes, the practical impact has seemed to be small, seemingly constrained by the length of the chain and the diversity of PHP configs.
In short, it was indeed a major vulnerability, but not magic (in the Arthur C Clarke sense).
I think ultimately the fear comes down to: do you believe that code can be secured. I recognize that there is probably no objective way to deductively prove it because of the Halting Problem etc. But if one believes code can be constructed to operate to spec, then there must be a limit to the damage an LLM can do, even a very smart one.
I think we are going through a phase where a lot of known triaged code shortcomings will get exposed and hopefully fixed. Sucks while it is happening. But not actually the first round of this type of evolution. And ultimately I think as before, we will come out the other side with more secure and durable technology.
If we want perfectly secure systems, then perhaps we don’t want universal and general purpose ones.
That's consistent with my experience using them for coding, where even the best models mostly work by being persistently midwit (with infinite knowledge) more than individually brilliant.
One corollary of this is probably that any project that has had an army of actual monkeys pounding on it for years is likely more resistant to LLM attack than one that has not. Everyone is worrying about individual robot geniuses finding obscure vulnerabilities in Linux, PHP, Python, etc., but they should probably be more worried about the permutations of less-known software floating around their systems.
Well, the report you're replying to doesn't make me so hopeful: "7349 findings made public, 217 (.5%) fixed"
Anthropic needs to teach their systems to propose a fix too. Detecting a coding problem and proposing a patch is what we should expect from a company with supposedly the best coding LLM.
Of course it's trivial to have an LLM generate a fix, too. They probably do. It doesn't mean a project (1) wants to take an LLM-generated fix at all, or (2) can immediately commit an LLM-generated fix without review (which takes time).
But right now they’re not even offering one. They’re just putting the burden on the project without even trying to help fix it.
They have all the resources in the world, and they won’t even try.
And that’s of course assuming it’s a real bug, as we’ve seen a ton of them don’t seem to be. The last time we went through this, curl reported not only that a bunch of them weren’t bugs, but some of the bugs were listed previously on their mailing list, and that’s probably where the LLM got them.
So not only is it finding small bugs. And nonbugs. It’s reporting previously found bugs.
Pilling work on maintainers. Over and over again. To help? No. To make big numbers to show off for their IPO documents.
The reason Anthropic isn't proactively sending patches is, I suspect, that those patches would not be welcomed, because trust in the models isn't currently at the point where maintainers are willing to merge them without human review, which takes approximately as much effort as writing the patches themselves. You can imagine the wailing and gnashing of teeth about "slop PRs" and "extractive contributions" that'd be all over HN.
A good amount of the patches is straight garbage. It's not helped by the fact that a good amount (20~30%, maybe more) of the issues is also junk themselves.
I'll hopefully be able to share numbers (or data) after we're done with the batch.
By extension, if a vuln is worth something to attackers, it's probably also worth some fraction of it to their potential victims. But if you're an interesting target, your defense can't be based on the ability to find out about every single software defect ahead of the time. You need layers. And if you have that, the importance of proactively acquiring every 0-day is diminished.
Still way less impactful than the PHP2Shell issue.
If they actually were sitting on a PR gold mine of vulnerabilities they wouldn't be throttled on review resources while artificially inflating/misreporting their numbers. They would be diverting resources to clear the review queue.
It's fake and it always was fake.
> almost none are being exploited
Isn't the whole point of glasswing to patch stuff way before it can be exploited? If the patched code is distributed quickly- there's no opportunity (or incentive) for bad actors to craft and distribute an exploit. This reads like an attempt to spin them as not being "real" vulnerabilities.
Which I'm fine with really, but it means you need to be very careful letting it iterate on code until it finds no problems.
The worst part is being thorough takes so much more work - they often do raise valid problems but you just can't set them in a loop because of this tendancy so you end up with way more work and hard questions
This is true for both code and prose. Even when it does notice something wrong, it wont remove it, but keep the sentence and make it longer.
"This is A" -> "This is B, not A"
It makes it incredibly hard to write plans and documents and maintain code.
When I tell it that the file is getting overlong and complex, unless I mention explicitly each single point, it just plainly doesn't see the problems and instead removes important bits. I did not yet find the right wording to express it to AI in an automated way.
It's been helpful.
The only other bit we also stole from that was the idea of only looking for issues in the original diff rather than spawning new problems from each diff fixing the previous. Of course the possibility exists of bugs being introduced while fixing others but we try to handle that with human review for the minute because its not worth getting agents to cover that bit, at least with naive approaches
It's like being asked if i'm using source control? It's kinda a given if you're doing more than hobby projects.
So the article is making a sweeping statement based on the 19.4% of publicly disclosed CVEs?
That statistic suggests the opposite. I'm sure government is aware of many back doors they keep secret and prefer them to remain secret.
> The CVEs are a sliver of this year's total, almost none are being exploited, fixes have stalled while duplicates and withdrawals pile up, and the triage burden is shifting onto the open source maintainers Glasswing promised to help. The receipts keep coming in. They still don't reconcile.
> VulnCheck is helping organizations not just to solve the vulnerability prioritization challenge - we’re working to help equip any product manager, CSIRT/PSIRT or SecOps team and Threat Hunting team to get faster and more accurate with infinite efficiency using VulnCheck solutions.
https://pmc.ncbi.nlm.nih.gov/articles/PMC11044265/
The common thread is asking humans to do the verification work, which is the hard part.
Sure LLMs have helped reduce the attack surface and we patch things faster too, but I was really expected a few more Supermarket-level bangers.
There were conflicting claims about the degree to which the $6 Billion Binance heist was an AI thing. But either way it seems like it would be a "look what it enabled" or a look what it failed to prevent"
If nothing happens at all it's waved away as scaremongering rather than prevention.
At the point I wonder if there is any information left secure honestly. These are not from glasswing, but they are from LLMs.
Patching it was the issue, not the hole.
1. The patches had to be unofficially backported to the versions of php that most people were using.
2. Devs had to figure out if the unofficial backports were safe and they weren't just falling into trapped versions
3. Devs had to migrate all of their projects to unofficial versions
4. No one was ready for it to happen because there was no advance notice (someone broke the embargo) for everyone to plan maintenance windows and upgrade at the same time.
At this point the play is simply to move the goalposts, suggesting that vulnerabilities don't matter so long as you yourself couldn't easily exploit them, regardless of what well-armed attackers can do with them. That's, obviously, not how software security works.
What sort of evidence? What "strongly suggests" this was actually easy to exploit?
Apply sarcasm or not based on sleep deprivation.
For example, as others have noted, there were no results on cryptography in OpenAI's October 6th math drop. But it seems unlikely that they didn't look at this sort of thing.
The correction is valid. It would be better if people used the right term. It's ok to correct. But it would be better if it were in addition to discussion of the actual point, not instead of it.
(And the phrase "catastrophic vulnerabilities" is pretty obviously talking about exploits anyway.)
For PHP2shell vulnerability for example, there was "patched" .deb (and equivalent) packages only for the most recent and most trendy distributions but countless older versions of distributions and php versions were like abandoned without simple solution. I would have guess that "patches" and pre-built fixed packages would be flooding the world. And with just a prompt of one line, most servers would be properly patched. But no.
I find it hard to assess when people mention false claims when I can't find what the claims were to determine what about them might be false.