A team says "we are fully patched, so we are fine" — what does patch level not cover?

## What the claim actually asserts "Fully patched" is a statement about **versions of code you did not write**, measured against fixes their authors have published. Unpacked, it asserts three things: a defect was acknowledged by whoever owns the code; a corrected version exists; and you are running it. Every one of those steps is somebody else's act. That is why the claim is so easy to make and so easy to over-read. ## The classes the claim never touches A flaw only gets a patch level when the fix is something that ships. These do not: - **An absent authorization decision.** The export endpoint checks that a session is valid and then serves whatever identifier it is handed. Nobody will publish a fix; the fix is a code change you author. - **An identifier treated as entitlement.** Possession of a number, link or reference is being accepted as proof of the right to the thing behind it. - **A workflow whose later step can be requested directly.** Every individual endpoint behaves as specified; the specification assumed an order the protocol does not enforce. - **Permission grants that are working as intended.** A component holding far more authority than it needs is not a defect anyone will fix for you. - **Defaults left as shipped.** The vendor's code is at the newest version and the configuration is the problem, so no version bump changes anything. What unites them is that **nothing is broken in the sense a patch fixes**. There is no crash, no memory violation, no incorrect parsing. Execution follows the intended path and produces the intended result of a wrong intention. ## The inversion worth saying out loud Put the two axes together and the review gets its punchline. | Weakness class | Distance to a working attack | Covered by "fully patched"? | | --- | --- | --- | | Memory corruption in a bundled component | Long: primitive, mitigation bypasses, reliability, often a chain | Yes | | Missing tenant-ownership check | Zero: change one value in an ordinary request | No | | Guessable reference accepted as authority | Near zero once a reference is obtained | No | | Known defect in a runtime library | Long, unless someone has already converted it | Yes | Patching is most effective exactly where the attacker's cost was already highest, and mute exactly where their cost is nil. A team that treats patch level as a sufficiency claim has optimised the half of the problem an adversary was least likely to buy their way through. ## How to answer the reviewer's sentence without dismissing it Do not respond as though patching were unimportant — it retires a genuine and continuous stream of exposure, and it is the single control that keeps you out of reach of everyone using someone else's converted work. The correct response is scope, not scorn: "Fully patched answers whether we are behind on other people's fixes. It cannot answer whether our own code decides correctly who may read what, and that second question is where the flaws that need no exploit live." Then make the claim testable. Ask what statement the team could make about the second class. Usually there is none, and the absence of one is the finding — not because anyone has been careless, but because the vocabulary of patch levels does not contain a slot for a flaw that has no version number. ## The trap in the other direction The mirror mistake is treating first-party logic flaws as the only ones that matter because they are "our fault". Third-party defects with public, reliable, packaged attacks collapse to zero distance too, and at that point the patch state of your estate is the entire question. The discipline is not to prefer one class; it is to keep two separate questions separate and refuse to let an answer to one be offered as an answer to both.