U.S. Government Disclosed 39 Zero-Day Vulnerabilities in 2023, First-Ever Report
zetter-zeroday.com
zetter-zeroday.com
when you disclose vulnerabilities and exploits, you effectively take cannons off both sides of the metaphorical battle field. it actively makes society safer.
(vuln mgmt in finance is a component of my day gig)
The longstanding objection to this is that secretly holding a gun doesn't intrinsically make everyone less safe, and there's a sense in which not disclosing a vulnerability does. That argument made more sense back in and before 2010; it doesn't make much sense now.
If an important factor is the ratio of exploits A and B have, then publishing their hidden but common exploits the ratio does not remain the same.
The ratio is interesting because potential exploitation rate is proportional zero days (once used, the "zero" day is revealed and remediated after a certain time span).
Arguably US as a nation state has the very best LLMs in the world, which is why I personally think they have been running weak AGI for few years, e.g. for autonomous malware analysis, reverse-engineering, and tailored malware generation & testing capability. Because they can actually store the personal data long term, without habing to delete it, this may be of gigantic strategic advantage due web being highly "polluted" after 2020-2021.
I would from this guess US has bet on AI research since end of WWII, and especially within last 30 years, noting the rather highly remarkable possibility that Surveillance Capitalism is actually part of the nation's security effforts. The warehouses of data they have built are warehouses of gold, or rather, gold mixed in sand since of course lots of it is also garbage.
Or if the people who worked at the agency are still there.
Also, not a joke, this program contains the word "equity" ("the Director of National Intelligence is required to annually report data related to the Vulnerabilities Equities Process") so it will probably be frozen or cancelled.
I’m sure the really juicy zero days they’ve discovered in-house are kept out of reports like these
They've just determined these ones are either no longer useful to them, or adversaries have discovered and began using them.
There's a lot of arrogance and hubris with the idea of NOBUS, and they often make things worse assuming only they know...
A 0-day is present in every instance of the software it can exploit.
You hoard knowledge by writing it down somewhere and then hoarding the places it's written down. Whether that's books, microfilm, hard drives, what have you
When you hoard something, your possession of that thing effectively takes access to that thing away from everyone else.
You can't keep access to a vulnerability away from anyone!
https://www.wired.com/2015/12/researchers-solve-the-juniper-...
https://en.wikipedia.org/wiki/Dual_EC_DRBG
https://en.wikipedia.org/wiki/Juniper_Networks#ScreenOS_Back...
The real downsides here are probably economic and have to do with how this shifts incentives for everybody in the industry. But, at the same time, every big tech company with a desktop/mobile footprint has invested mightily on staff to counter LE/IC/foreign CNE, which is something that might not have happened otherwise, so it's all complicated.
People write as if the disclosure of a bunch of IC zero days is like some kind of movie-plot "Broken Arrow" situation, but it's really mostly news for message boards. Organizations that need to be resilient against CNE are already in a state of hypervigilance about zero-days; adversaries absolutely have them, no matter what "NSA" does.
My understanding of VEP is that the default is supposed to be to disclose immediately unless an agency has a really good reason not to, presumably because they want to use it soon. Don't hoard, only keep things that you're actually going to use.
When I say "burn", I mean that something has happened to increase the likelihood that an exploit chain is detectable. That could be them being done with it, it could be independent discovery, it could be changes in runtime protections. It's not "we use it a couple times and then deliberately burn it", though.
We should stop talking about "NSA", because this is basically a universal LE/IC practice (throughout Europe as well).
A lot of things can be understood better through the lens of "what reduces truck rolls".
Their charter was to take over COMINT from the military into a new joint administrative agency. Their work includes securing communications between allies as much as it does breaking communications from our belligerents. This work necessarily provides them with the types of knowledge and experience that would be highly valuable in securing infrastructure against similar attacks.
Likewise they've involved themselves in both improving and harming civilian cryptography systems and research for years. They're a complex agency and the value of COMINT can be realized under many different root paradigms. It's absurd to think otherwise.
All major governments hoard 0days or buy them to use for espionage. I dont see this being some kind of "turning point" and more of a feel good easy PR win for the US gov but really they are still using many 0days to spy.
The lesson is that our desktop software is garbage and the vendors are not properly held to account.
If I know you always disclose, and I find something you haven't disclosed, I know I have an edge. That incentivises using it because I know you can't retaliate in kind.
The hoarding of vulns is a stability-instability paradox.
Same way you know if they don't have nukes. Based on what they say and your best guess.
The first hint would be the agency stating that they have a policy of always disclosing. You would of course not believe that because you are a spy with trust issues. But then you would check and hear from all kind of projects and companies that they are receiving a steady stream of vulnerability reports from the agency. You could detect this by compromising the communications or individuals in the projects receiving the reports, or through simple industrial rumours. That would be the second hint.
Then you would compromise people in the agency for further verification. (Because you are a spy agency. It is your job to have plants everywhere.) You would ask these people “so what do you do when you find a vulnerability?” And if the answer is “oh, we write a report to command and we sometimes never hear about it again” then you know that the stated policy is a lie. If they tell you “we are expected to email the vulnerable vendor as soon as possible, and then work with them to help them fix it, and we are often asked to verify that the fix is good” then you will start to think that the policy is actually genuine.
There are known exploits to get root access to every phone or laptop in the world. But researchers won't disclose these to the manufacturers when they can make millions of dollars selling them to governments. Governments won't disclose them because they want to use them to spy on their citizens and foreign adversaries.
The manufacturers prefer to fix these bugs, but aren't usually willing to pay as much as the nation states that are bidding. All they do is drive up the price. Worse, intelligence agencies like the NSA often pressure or incentivize major tech companies to keep zero-days unpatched for exploitation.
It's a really hard problem. There are a bunch of perverse incentives that are putting us all at risk.
Classify them as weapons of mass destruction. That's what they are. That's how they should be managed in a legal framework and how you completely remove any incentives around their sale and use.
Otherwise corporations will be incentivized (even more than they are now) to pay minimal lip service to security - why bother investing beyond a token amount, enough to make PR claims when security inevitably fails - if there is effectively no penalty and secure programming eats into profits? Just shove all risk onto the legal system and government for investigation and clean up.
Seriously HN? Your Netflix password being compromised is equivalent to thermonuclear war?
By this definition trucks are WMDs because they, too, can blow up a dam.
Hyperbolic comparisons undermine the speaker’s authority. Zero Days aren’t WMDs.
We’ve created such a house of cards. I hope when it all comes crashing down that the species survives.
Apologies for the dismissive snark; perhaps you could provide me some examples of how this would help?
We got Mark Dowd to record an episode with us to talk through a lot of this stuff (he had given a talk whose slides you can find floating around, long before) and I'd recommend it for people who are interested in how grey-market exploit chain acquisition actually works.
Hard problems are usually collective-action problems. This isn't one. It's a tragedy of the commons [1], the commons being our digital security.
The simplest solution is a public body that buys and releases exploits. For a variety of reasons, this is a bad idea.
The less-simple but, in my opinion, better model is an insurance model. Think: FDIC. Large device and software makers have to buy a policy, whose rate is based on number of devices or users in America multiplied by a fixed risk premium. The body is tasked with (a) paying out damages to cybersecurity victims, up to a cap and (b) buying exploits in a cost-sharing model, where the company for whom the exploit is being bought pays a flat co-pay and the fund pays the rest. Importantly, the companies don't decide which exploits get bought--the fund does.
Throw in a border-adjustment tax for foreign devices and software and call it a tariff for MAGA points.
Security is in general non-excludable (vendors typically patch for everyone, not just the discoverer) and non-rival (me using a patch doesn't prevent you from using the patch): that makes it a public good [1]. Whether it can be depleted is irrelevant. (One can "run out" of security inasmuch as a stack becomes practically useless.)
[1] http://www.econport.org/content/handbook/commonpool/cprtable...
Yeah, sure. But that doesn't make it a resource. It's an abstract idea that we can have more or less of, not a raw physical quantity that can utilize directly, like space or fuel. And yes, it is relevant that it can't be depleted, because that's what the term "tragedy of the commons" refers to.
I think you're using an overly-narrow definition of "tragedy of the commons" here. Often there are gray areas that don't qualify as fully depleting a resource but rather incrementally degrading its quality, and we still treat these as tragedy of the commons problems.
For example, we regulate dumping certain pollutants into our water supply; water pollution is a classic "tragedy of the commons" problem, and in theory you could frame it as a black-and-white problem of "eventually we'll run out of drinkable water", but in practice there's a spectrum of contamination levels and some decision to be made about how much contamination we're willing to put up with.
It seems to me that framing "polluting the security environment" as a similar tragedy of the commons problem holds here, in the sense that any individual actor may stand to gain a lot from e.g. creating and/or hoarding exploits, but in doing so they incrementally degrade the quality of the over-all security ecosystem (in a way that, in isolation, is a net benefit to them), but everyone acting this way pushes the entire ecosystem toward some threshold at which that degradation becomes intolerable to all involved.
Uh, intellectual property. Also land ownership is an abstract idea. (Ownership per se is an abstract idea.)
Stocks. Bonds. Money, for that matter. These are all "abstract idea[s] that we can have more or less of, not a raw physical quantity." We can still characterise them as rival and/or excludable.
Secure use of any device requires a correct specification. These should be available to device buyers and there should be legal requirements for them to be correct and complete.
Furthermore, such specifications should be required also for software-- precisely what it does and legal guarantees that it's correct.
This hasn't ever been more feasible, also considering that we Europeans are basically at war with the Russians, it seems reasonable to secure our devices.
You're still left with a massive enforcement problem nobody wants to own. Like, "feds sued your kid's avourite toy maker because they didn't file Form 27B/6 correctly" is catnip for a primary challenger.
They way I imagine it: no sales of this kind of thing to ordinary people, only to sophisticated entities who be expected to deal with the incompletely specified source code, so if a software firm wants to buy it that's fine, but you can't shrink wrap it and sell it to an ordinary person.
However, large commercial IT vendors such as Microsoft and Cisco were unable to achieve the minimum security requirements demanded for high criticality deployments, so the US government had to lower the minimum requirements so their bids could be accepted.
At this point, all vendors just specify and certify that their systems have absolutely no security properties and that is deemed adequate for purchase and deployment.
The problem is not lack of specification, it is that people accept and purchase products that certify and specify they have absolutely zero security.
So I mean an internal specification of all hardware interfaces and a complete description of software-- no source code, but a complete flow diagram or multi-process equivalent.
One possible reason: knowing about a vulnerability is a relatively small amount of the work in providing customers with a working exploit chain, and an even smaller amount of the economically valuable labor. When you read about the prices "vulnerabilities" get on the grey market, you're really seeing an all-in price that includes value generated over time. Being an insider with source code access might get you a (diminishing, in 2025) edge on initial vulnerability discovery, but it's not helping you that much on actually building a reliable exploit, and it doesn't help you at all in maintaining that exploit.
This is a bit of a prisoner's dilemma. The world would be better off if everyone disclosed every such exploit for obvious reasons. But if government A discloses everything and government B reserves them to exploit later, then government B has a strong advantage over government A.
The only responses then are war, diplomacy, or we do it too and create yet another mutually assured destruction scenario.
War is not going to happen because the cure would be worse than the disease. The major players are all nuclear powers. Diplomacy would be ideal if there were sufficient trust and buy-in, but it seems unlikely the U.S. and Russia could get there. And with nuclear treaties there's an easy verification method since nuclear weapons are big and hard to do on the sly. It'd be hard to come up with a sufficient verification regime here.
So we're left with mutually assured cyber destruction. I'd prefer we weren't, but I don't see the alternative.
LE: law enforcement, a major buyer of CNE tooling.
IC: the intelligence community, the buyer of CNE tooling everyone thinks about first.
"Penetrate and Patch" is about as effective for software security as it is for bulletproof vests. If you randomly select 10 bulletproof vests for testing, shoot each 10 times and get 10 holes each, you do not patch those holes and call it good. What you learned from your verification process is that the process that lead to that bulletproof vest is incapable of consistently delivering products that meet the requirements. Only development process changes that result in passing new verification tests give any confidence of adequacy.
Absent actively, or likely actively, exploited vulnerabilitys, the government should organize vulnerabilitys by "difficulty" and announce the presence of, but not disclose the precise nature of, vulnerabilitys and demand process improvement until vulnerabilitys of that "difficulty" are not longer present as indicated by fixing all "known, but undiclosed" vulnerabilitys of that "difficulty". Only that provides initial supporting evidence that the process has improved enough to categorically prevent vulnerabilitys of that "difficulty". Anything less is just papering over defective products on the government's dime.
For this amount of bureaucracy, the government should just hire all coders and write all software.
1) Government already has vulnerabilitys.
2) Government identifies vulnerabilitys they already own by "difficulty to discovery".
3) Government selects the lowest "difficulty to discover" vulnerabilitys they already own.
4) Government announces products with known "lowest difficulty to discover" vulnerabilitys are vulnerable, but does not disclose them.
5) Government keeps announcing those products continue to be the most "insecure" until all vulnerabilitys they already own at that level are fixed.
6) Repeat.
The government has vulnerabilitys in stock that they already verify function as intended. They already regularly verify these vulnerabilitys continue to function with each update cycle. They already quantify these vulnerabilitys by ease-of-discovery, impact, etc. so they can prioritize utilization. They already determine vulnerabilitys to disclose.
Assuming that the vulnerabilitys they disclose are not entirely "actively under exploit", the only difference in my proposed policy is that they do not disclose the details to the vendors so they can paper over them. Instead, they publicly announce the presence of vulnerabilitys and then keep verifying as they already do until the vulnerabilitys no longer function.
You seem to think I am arguing that the government should create a new organization to look for vulnerabilitys in all software everywhere and then act as I stated.
Yes. This is difficult. Particularly given you need to do it fairly and thus comprehensively.
You can not change the parameters of my proposal to explicitly require a gigantic bureaucracy then argue that it is a poor idea because the gigantic bureaucracy you added is a problem. You could have argued that my proposal is untenable because it would be "unfair" and the only way to make it fair would be to do it comprehensively which would be too hard.
To which I would state:
1) That means we as a society care more about being "fair" to companies with inadequate software security than demanding adequate software security. Could be the case, but then everything other than roll over and accept it is off-the-table.
2) The government already requires certification against the Common Criteria for many software products in use by the government. You could restrict this policy to just systems that are used and require certification before use. Thus being applied "fairly" to government procurement and incentivizing improvements in security for procured systems.
3) This should actually just be general policy for everybody, but only the government, currently, has enough leverage to really pull off publicly announcing a problem and the vendor not being able to just shove it under the rug.
And, even if you disagree with those points, I am also making the point that the current policy of disclosing the vulnerability so the vendor can make a point-patch to resolve it instead of fixing their overall security process is a failed security policy at the societal level. We need mechanisms to encourage overall security process improvement. Currently, the only thing that does that is the exponentially increasing amount and severity of hacks, and it would be nice to get ahead of it instead of being purely reactionary.
I recommend, in the future, that if you want to pursue a security policy angle in discussions online with people, you avoid using that term.
In fact, all of points except “Hacking is Cool”, are largely well supported. The common thread being that all the other points are about “designing systems secure against common prevailing threat actors” (i.e “defense”) and only that point is about “development of adversarial capabilitys” (i.e. offense) which they wrongfully undervalue and even associate criminality with; misunderstanding the value of verification processes.
And besides, the entire modern science of software security is, objectively, terrible at “designing systems secure against common prevailing threat actors”. What it is pretty good at is the “development of adversarial capabilitys” which has so far vastly outstripped the former and demonstrates quite clearly that prevailing “defense” is grossly inadequate by multiple orders of magnitude.
“Default Permit”, “Enumerating Badness”, “Penetrate and Patch”, “Educating Users” were the norms of the time and still, largely, are. And that is part of why “defense” is so grossly inadequate against common prevailing threat actors.
I prefer the norms of high security software which include, but do not consist exclusively of, most of the stated ideas.
1) The post was made to vilify independent security research.
2) The post argues against "the entire modern science of software security".
3) The norms of 1997 are worse than the norms of 2025 and that my support for the argument that "Penetrate and Patch" is a poor security policy is somehow indicative that I prefer the norms of 1997 even though "Penetrate and Patch" was and continues to be the prevailing norm.
To which I argue:
1) Maybe so. However, the arguments against most of the stated practices, in particular everything except idea #4, stand on their own and have stood the test of time.
2) Given the contents of the rest of that post, this is almost surely a statement that idea #4 was wrong which I have agreed was incorrect. I also, separately, argue that "the entire modern science of software security" is basically useless at producing systems secure against common prevailing threat actors as is demonstrated daily. This is distinct from the high level of capability in producing systems and processes that can identify and exploit vulnerabilitys which is a clear win for the "the entire modern science of software security". However, such capability is not very helpful in achieving the former which is the thing usually desired from "security".
3) I am just baffled. I have to assume that you just misread my position. Otherwise you are arguing that the systems of 1997 were default deny, explicit whitelists, engineered for security from the start, and operate in a secure configuration by default. Or that the security processes of 2025 are that way. Both of which are laughable. I guess you could also argue that those principles are bad, but I am pretty sure even the sorry state of affairs that passes for "software security" these days recognizes those are correct principles even if they utterly fail to even attempt them.
So, either they form a department of viability or they lose it all.
For example in 2018 Tencent (basically, China) withdrew from hacking competitions like pwn2own taking along with them the disclosures that proceeded.
Other countries doing the same thing is an argument about whether the thing is actually bad, and could be valid.
For example, when someone accuses you of taking money out of the register, it would be an example of whataboutism to point that the person accusing you does it too. The X in "what about X?" doesn't need to be something fundamentally different, it just needs to be something that distracts from the original criticism.
If the real argument is that not disclosing vulnerabilities is not actually a bad thing, then the fact that China also doesn't do it is completely irrelevant.
I don't think it would. Or at least, I don't think it necessarily would. "You do it, therefore it's not bad, therefore I'm not wrong" is a reasonable argument that is not distraction. "All these other people also do it and it is treated as de minimis at worst, and yet you're singling me out for inappropriate reasons" may be reasonable depending on context or may be somewhat abusive... but it is a different argument than "Whataboutism". Bringing up that you do it, too, purely (or mainly?) as a distraction can probably reasonably be accounted Whataboutism, but it's a distractingly noncentral example because of its proximity to those other arguments.
> If the real argument is that not disclosing vulnerabilities is not actually a bad thing, then the fact that China also doesn't do it is completely irrelevant.
Other agents having made the same decision is perhaps some evidence that it was a reasonable decision, although it very much depends on context.
The purpose of government is to take and maintain power and prevent any other organization from displacing them. It involves citizens only as a means to an end.
It would be a failure of government to place citizen safety over continuity of government.
Well, the calculus didn't change in 2023 if the report was only released a month or so ago. And in fact, in May 2024:
DHS, CISA Announce Membership Changes to the Cyber Safety Review Board https://www.dhs.gov/archive/news/2024/05/06/dhs-cisa-announc...
So some new people came in and decided that more public information was better.
> On January 21, 2025, it was reported that the Trump administration fired all members of the CSRB.
Ah, well, never mind then
> This lack of transparency could become a greater issue under the Trump administration, which has vowed to ramp up the government's cyber offensive operations, suggesting that the government demand for zero-day vulnerabilities may increase over the next four years. If this occurs, the government’s previous statements that the VEP favors disclosure and defense over withholding and offense may no longer be true. ...
> “The VEP and that number of 90 percent was one of the few places where the president and the White House could set the dial on how much they liked defense vs offense,” says Jason Healey, senior research scholar at Columbia University’s School of International and Public Affairs and former senior cybersecurity strategist for CISA. “[The Trump administration] could say we’re disclosing too [many vulnerabilities]. If the default [in the past] was to disclose unless there is a reason to keep, I could easily imagine the default is going to be to keep unless there is a reason to disclose.”