返回资讯中心
外部精选
软件工程
#开发者实时流

This is not sustainable

huh? High fives all around—October is

Hacker News 最新BrunoBernardino2026/10/28 · 7 天前22 分钟阅读

以下正文同步自 Hacker News 最新,版权归原站所有,已转换为易读排版。

What a week, huh? High fives all around—October is "Cybersecurity Awareness Month", and I think we've all done a stellar job. If both the New York Times and NPR report on one of the at least four or five concurrent fires I'm fighting, then I think we can say that yeah, people are aware of cybersecurity. Mission accomplished, so... could we maybe turn it down a bit?

The current situation is not sustainable: 0-days are dropping left and right, pre-notifications and embargoes are broken for marketing purposes, AI companies compete first on who commits the most crimes and then pretend to sell you protection in the form of a DoS on the Open Source community. "Nice project you got there. Be a shame if somebody dropped an 0-day on it."1

Companies are not staffed for this, and no matter what the industry wants to tell you, you can't AI your way out of this. Vulnerability discovery has fundamentally changed, disclosure processes are effectively broken, and patch management has been a losing proposition for years now. Severe vulnerabilities are identified and disclosed at a pace that defenders are unable to keep up with.

This is because it still takes significant resources to accurately assess the feasibility of a given vulnerability within your environment; it takes time to discover your attack surface relevant to the given attack vector, and it takes even more time to deploy a fix. As I've said before, development of the fix is not the bottleneck. Let me illustrate with examples from the last couple of days:

Initially disclosed as a "KVM escape", this vulnerability also applies to other virtualization as well as containers, although that angle hasn't really gotten much attention. You now need to assess which possible mitigations might be in place across your fleet of systems, then determine whether you can livepatch your kernels with the custom patches you pull from upstream or if you want to wait for your upstream OS provider to deliver a new kernel2 and then all you have to do is reboot a few thousand systems.

How does AI help you here? Maybe you spend a few thousand dollars on tokens to use the most advanced cyber cyber models to develop your own exploit, but in the end, that doesn't really tell you anything you didn't already know, and your defensive position and tasks at hand remain the same.

This one's fun, isn't it? Sure, browsers were all set quickly, but guess what, there's a few other things that might use TLS in your environment. Like... everything. So again, having the fix is not the bottleneck. Waiting for upstream packages to release an update only blocks you if you actually know that you need to pull in that update.

Oh, you have a detailed package inventory or, dare I say it, SBOMs? That's really nice. Do show me where that lists the various vendored or hard-coded CA trust bundles. Yeah, I didn't think so.3

(At least this incident was not AI generated, detected, or triggered. Just one of your wholesome, classical, a-human-going-"huh" kind of discoveries. It's almost reassuring that we still get these, too.)

The PHP vulnerability that supposedly affects "over 70% of websites" (a widely quoted, but never attributed statistic) was disclosed under embargo to several organizations. If you were part of this inner circle, then this should have reduced your panic-mode somewhat, buying you at least some time to deploy protections for your customers and do the tedious work of sifting through your inventory and, again, identify the attack surface, affected systems, possible local mitigations, etc. etc. The usual.

Unless the embargo is broken. Then you get to scramble again. And you need to keep up to date with all the rapidly published (and increasingly verbosely AI polluted) breathless blog posts driven by cyber security vendors' marketing teams eager to beat each other as the first to detect4, first to exploit, first to brag, all of which adds to the distraction.

And of course you still need to do the actual work of determining the accuracy of the various exploits floating around the internet, some put together by people with a clue and many, many slopped together by those lacking a full understanding of the bug5. (More on that below.)

And then, by the time Thursday rolls around, people start to see a NodeJS security advisory, which includes as the third "high" severity vulnerability an issue with the "Node.js Brotli decoder". Alright, attack surface enumeration, software inventory check, start to deploy updated packages,... the usual.

Except, of course, once you take a closer look, it begins to dawn on you that this goes well beyond just Node.js6. And so once again, having the upstream fix available is absolutely not your bottleneck, because you still need to find the plethora of frankenstances of brotli across all of your stacks first.

Of course at that point in time OpenAI starts to go "Us! It was us! We found it!" even though the issue was fixed back in February and Mozilla noted the critical security impact as far back as April. It seems there's no vulnerability, no compromise, no cyber crime AI companies are not willing to claim as their credit.

All of this was going on over the course of one week, and doesn't even account for the previous set of weekly Linux local privilege escalation vulnerabilities7. And no doubt there will be more such disclosures—many more.

AI companies are incentivized to continue the onslaught, with the most benevolent interpretation of mass disclosures of findings being a canonical example of "verschlimmbessern", with less friendly interpretations observing that it's profitable for a company to create the disease for which they're selling you to treatment (and never the cure). They've got a new toy, it's a hammer, and by golly they're gonna swing it.

Millions of dollars have been spent on identifying vulnerabilities using so-called "frontier AI models", and we know that adversaries are feeding, e.g., the Linux kernel commit messages into their models to analyze them for exploitable vulnerabilities on the fly. Today, vulnerabilities are found independently by multiple parties on a regular basis, so you already have to assume that a disclosure embargo only contains the massive exploitation by opportunistic adversaries at best.

At the same time, I'm observing a worrying trend on the defensive side of cyber security, which mirrors the same de-skilling trend across the industry: AI generated vulnerability reports are often much, much too verbose to be digested easily by human readers. They drown you in details, overwhelm your attention with unnecessary information. Because defenders don't fully understand the vulnerabilities described here, they tend to believe the generally exaggerated severity claims, and feed the full report into their AI to reproduce or generate a proof of concept.

Several thousand tokens later, you end up with a binary handed to you by a meat-proxy that's supposed to trigger the vulnerability, but nobody actually understands why it works. Which, more often than not, it actually doesn't, because your environment is different, your AI was missing context the meat-proxy didn't (know to) provide, because the code base differs from upstream, or who knows what else. When you ask for clear instructions on how to run the exploit, what pre-conditions need to be met, and how it works—you know, the kind of one-pager that offensive engineers used to be able to produce—you get back, you guessed it, an AI-vomited 7,000 word README.md.8

Fighting one fire at a time is taxing enough. Each one of the above examples would have been a once-a-year incident not too long ago. Having multiple such incidents at the same time is burning out all your incident response staff, your engineers, your comms and legal teams.

(And it always is more or less the same set of people driving each incident. I have not seen organizations properly staffed and not relying on the same set of ghostbusters—the heroes and company-elders with the required tribal knowledge to make up for the gaps in your software inventory, attack surface enumeration, and documentation, because who else are you gonna call?)

Context switching between each of these incidents means you can't focus on any one of them, making you more likely to miss important information, to fall for sensationalistic headlines, to succumb to pressure and to rush fixes you don't understand for vulnerabilities that might not apply in your environment. Which, in turn, makes more people more susceptible to the appealing lure of quick and confident answers from the bot, and subject-matter non-experts start to paste their prompt results into incident response channels.

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →