A CVE against your appliance is tagged DISPUTED by the vendor — how do you judge your exposure?

## What the marker actually is When a published record is contested, the contest is recorded on the record. The record stays public, keeps its identifier, and keeps its description; it gains a note that a party disputes it. This is deliberately different from withdrawal. A **withdrawn** (rejected) record is one the assigner has retracted — a duplicate, not a vulnerability at all, or issued in error — and it carries a stated reason. A **disputed** record is one that two parties disagree about *in public*, with both positions visible and neither erased. The single most common mistake is to collapse those two into 'it is not real, close it'. They are opposite situations: withdrawal is a decision, dispute is the absence of one. ## Nobody is the referee Candidates often assume some body adjudicates. It does not work that way. The scheme's job is naming, and it has no mandate to rule on whether a behaviour constitutes a vulnerability. Escalating to the assigner's root can resolve *process* questions — whether the issue was in scope, whether it duplicates another identifier, whether the assigner followed the rules — but it cannot resolve the substantive question of whether documented behaviour is a defect. That question has no central answer, because 'vulnerability' is defined relative to a security model, and the vendor's model and yours may genuinely differ. ## The usual grounds for a dispute, and what each implies - **'It is documented and intended.'** A support account, a debug interface, a permissive default that the manual describes. The vendor's position is that a documented behaviour cannot be a flaw. The practical consequence for you: it will not change. - **'It requires privileges the model already grants.'** The reporter demonstrated something from an account that, in the vendor's design, is already trusted. Whether this matters depends entirely on whether *your* deployment grants that account to people you would not trust with the result. - **'It is only reachable in an unsupported configuration.'** Then the question is simply whether you are in that configuration. - **'The affected component is not ours.'** A packaging or attribution dispute — the behaviour may be entirely real, in somebody else's code. Notice that every one of those, decoded, is a question about *your* deployment rather than about the record. ## How to reach a defensible position 1. **Read the description, ignore the label.** What behaviour, reachable by whom, under what precondition? 2. **Test the precondition against your estate.** Is the interface exposed? Is the account issued to anyone? Is the option enabled? A dispute changes nothing about whether the precondition holds for you. 3. **Ask what changes if both parties are right.** Very often the vendor is right that it is intended *and* the reporter is right that it is dangerous. Both can hold. Your decision does not require picking a winner. 4. **Decide the handling class.** If a fix might come, it is a patching item. If the vendor calls it intended, it is a design item: compensate around it with placement, network position, credential handling or an access boundary — or accept it with a named owner and a review date. 5. **Write the decision down once.** A disputed record does not vanish. It will keep reappearing in whatever lists your organisation maintains, and re-arguing it every quarter is pure cost. A recorded decision with its reasoning ends that. ## What the dispute does not change It does not remove the identifier, which stays permanent and citable. It does not stop downstream databases carrying the record. It does not make the described behaviour go away, and it does not make it dangerous either — plenty of disputed records describe behaviours that really are intended and really are harmless. ## The senior signal The answer an interviewer wants is the refusal to let a metadata label make a technical decision. A weak candidate treats the tag as a verdict in either direction — closes it because it is disputed, or escalates it because a vendor is being defensive. A strong one says: the label records a disagreement, the behaviour is what matters, the precondition is checkable in my own environment, and the vendor's position mainly tells me whether to expect a fixed version.