A vendor that is its own CVE Numbering Authority reports zero CVEs — what does that prove?

## What a count is actually counting For an identifier to exist against a product, four independent things must happen: 1. **Somebody looks and reports.** Nothing crawls the world's firmware issuing identifiers. A product nobody researches accumulates zero forever. 2. **The product falls inside a CNA's declared scope.** Every numbering authority publishes what it is entitled to number. A vendor that is its own CNA writes that boundary itself. 3. **The assigner counts the issue as a vulnerability.** This is a judgment, not a measurement. 'Documented in the manual', 'requires an already-trusted operator', 'a hardening improvement rather than a flaw' are all ordinary reasons an assigner declines. 4. **A record is published**, rather than left allocated but unpublished. When the vendor is the assigner it controls items 2, 3 and 4. The count therefore measures the vendor's own paperwork, filtered through whoever bothered to look. That is why 'zero identifiers' is not a claim about code, and why a buyer who accepts it has learned nothing. ## The worked case: a flat office segment Picture a small office segment carrying a dozen network cameras, two badge printers and a door controller — no adversary in this story at all, just an estate. The camera firmware ships a vendor support account with a fixed password, described in the installation guide under 'remote assistance'. It is a real, serious property of the estate: anyone on that segment who has read a manual available online can authenticate to every camera. What happens to it in the naming scheme? The vendor is its own CNA. Its scope covers its camera line, so item 2 is satisfied. But on item 3 the vendor's position is that a documented, intended account cannot be a vulnerability — so it declines to assign. Nobody outside has published research on this model, so nothing forces the question. The result is a genuine flaw that will never carry an identifier, sitting on a segment whose owner has been told there are zero CVEs against the product. Both statements are true simultaneously, which is the whole lesson. ## The other direction, which people forget The inverse error is just as common: treating a long list of identifiers as evidence of bad engineering. A vendor with many published records is usually one that receives reports, runs a disclosure process, counts flaws separately rather than bundling them, and publishes what it fixes. A mature programme manufactures identifiers. Comparing two vendors by count therefore rewards silence and punishes transparency — the exact opposite of what a buyer wants. ## What escalation does and does not fix A reporter who is refused by a vendor can escalate to that assigner's root, which may assign an identifier for a product outside any other authority's scope or where the responsible authority declines or does not respond. So the door is not sealed. But somebody still has to walk through it, and for an unglamorous appliance in an unglamorous market, usually nobody does. 'It could have been escalated' does not turn a zero into evidence. ## What to ask instead of a number These are the questions that have observable answers and that a vendor either commits to or visibly does not: - Do you publish a security note for **every** fix, whether or not an identifier was assigned? This is the single most informative question, because it detaches disclosure from counting. - Will you request identifiers for externally reported issues, and what is your stated response time to a report? - What is your published contact route for reporting, and has anyone ever used it? - Which firmware versions are still supported, and until when? An out-of-support appliance is one where the count is guaranteed to stop growing for reasons that have nothing to do with quality. - Do your release notes state the fixed version plainly, so a buyer can tell whether their estate is current? ## Saying it from the vendor's side of the fence If you are the vendor's product-security engineer and a procurement reviewer opens with 'how many CVEs have you had?', the honest and far more persuasive answer is to explain what the number would and would not measure, then offer the things that are actually checkable: the disclosure policy, the support lifetime, the commitment to publish notes for every security fix. A vendor who volunteers that a low count is uninformative is telling the buyer something real about how it operates. A vendor who leans on the zero is telling them something too.