There Is Assume Breach, and There Is Oh C'mon. One Question Tells You Which One You Are Looking At.
"Assume breach" is good advice. It is also, increasingly, the sentence people say instead of fixing something cheap.
Those are two different postures wearing the same words, and after a week of measuring patch-effect gaps we think there is a single question that separates them.
The question
Was the fix cheap, known, and uncounted?
If an organization has done the expensive work — segmentation, least privilege, identity, logging that someone actually reads — and is still humble because a sufficiently motivated adversary gets a vote, that is assume breach. Earned humility. It is the correct posture and nobody should be mocked for holding it.
If the expensive work is undone, or the cheap work is undone, and "we assume breach anyway" is the reason given, that is the other thing. Humility used as a hiding place. Our shorthand for it this week, borrowed from a conversation and not improved upon: oh c'mon.
The distinguishing feature is not severity. It is whether the thing left undone was cheap, already known, and measured by nothing. Those three together are the signature of a fix that never wins a sprint — not because anyone decided against it, but because no dashboard goes red when it is missing and no customer asks for it in a procurement questionnaire. Attention is the scarce resource, not money and not competence.
We ran the question against sixteen companies
We picked three controls that are cheap, public, and machine-checkable from outside, then measured fifteen security vendors and one surveillance vendor against them. Every figure below came from a primary source: the CVE Program's own list of 559 Numbering Authorities, a request to each /.well-known/security.txt path, and a DNS lookup of each _dmarc record.
The result surprised us, and we are reporting it rather than the version we expected.
The security industry largely passes. Fourteen of fifteen are CNAs — issuing your own CVE identifiers is the expensive, thankless half of product security and almost all of them do it. Eleven of sixteen enforce DMARC at p=reject, with three more at quarantine. We went looking for p=none, the deployed-but-not-enforcing shape, and did not find a single one.
Four are CNAs with no security.txt: Palo Alto Networks, Check Point, Zscaler, Proofpoint. All four run product security teams and accept reports. What is missing is the standardized, discoverable path — RFC 9116 has been a standard since 2022, and without it a researcher has to go hunting. That is friction, and friction matters more for a security vendor than for anyone else, because a vendor is the most concentrated fan-out on the board. An unreported flaw in a security product is an unreported flaw in every network behind it. One file, one afternoon, and it protects the entire customer base. By our own test it is cheap and known and uncounted — but the expensive work is unmistakably done, so this is assume breach with a paperwork gap, not the other thing.
One is the other thing. Motorola Solutions is not a CNA and publishes no security.txt — the only organization of the sixteen missing both. We wrote about them separately today: seven CVEs on license plate readers holding criminal justice information, remediation asserted as complete with no fixed version number published, never appearing in the federal exploited-vulnerabilities catalog, 505 subdomains in certificate transparency of which 124 name their own non-production tier, and a federal staging administrative portal resolving on the public internet. Every one of those gaps is cheap, known and uncounted.
And one honest curiosity. Medtronic is a CNA with DMARC at reject — the expensive work is done. But their web tier returns HTTP 200 for every path under /.well-known/, including a nonsense path we invented to check. That is a soft 404: a catch-all that reports success for things that do not exist. It is not a vulnerability. It is a tell, and it means any scanner — theirs or anyone else's — gets a false positive on every probe it sends there.
Why the cheap ones are the ones left undone
This is the part worth internalizing, because it is not a character flaw.
A security.txt file generates no revenue. No customer requires it. No auditor asks for it. No dashboard turns red without it. It competes, in a sprint planning meeting, against a feature somebody has promised. It loses, every time, to things that are measured.
The same mechanism explains everything else we measured this week. A firmware blocklist nobody updates, because patch reports count patches and not their effect. A fix that shipped on September 11 and did not reach the federal exploited list until October 23, because nothing measures the gap between shipped and listed. A certificate authority's keys revoked by every browser within hours while the command-line tools on the same machine still trust them a full operating-system version later, because nothing measures whether a revocation arrived.
None of that required anyone to be negligent. It required only that the fix be cheap and the absence be uncounted. Those two properties together are the most reliable predictor we have found of what will still be broken next year.
Pointing it at ourselves, because otherwise this is just a scoreboard
We cap every confidence claim at 95 percent. That is a real discipline and it is one bad habit away from being the same hiding place.
"We guarantee five percent of this is wrong, here is today's five percent, dated, with the original claim visible beside the retraction" is the honest form. "We cap at 95 percent, so do not hold us to anything" is oh c'mon with better manners. The entire difference is whether the five percent gets named.
So here is today's, unabridged. We published a correction stating that an unauthenticated call to our own indicator feed returns HTTP 200 with zero rows — a silent empty success. It does not. It returns 401 with a plain-language registration note. We had sourced that claim from our own internal documentation, in a correction whose entire argument was that you must test the artifact rather than trust the document. One command would have caught it; we ran it afterwards. All three affected posts now carry the tested behavior.
And separately: this morning a redirect whose working-directory change had failed overwrote our own project README with a third party's file. It sat wrong for nine hours. The command that caught it was git status, which takes one second and which nothing obliged us to run.
Both of those were cheap, known, and uncounted. By our own test they belong in the second column, and the only thing keeping them out of it is that they got named at all.
What to actually do with this
If you are deciding where to spend the next hour of attention, sort your undone work by the three properties rather than by severity score:
Is the fix cheap? Hours, not quarters.
Is it already known? Nobody needs to discover anything.
Does anything measure its absence? If no instrument goes red, nothing will ever prompt you.
Everything that scores yes, yes, no is sitting in the gap this whole week lived in. That is the list. It is usually short, it is usually boring, and it is the only list where an afternoon buys a disproportionate amount.
Assume breach, by all means. Just make sure it is the posture and not the excuse.
If you close one of these because of this post, or if we have scored your organization wrong — the measurements above are all reproducible in about five minutes and we would rather be corrected than right — the rating widget below reaches us.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=there-is-assume-breach-and-there-is-oh-c-mon-one-question-tells-you-which-one-you-are-looking-at
Comments