Your advisory's CVSS base score assumes an authenticated admin, but a consumer recomputes it far higher. Who is right?

## What you are actually asserting when you publish a score A CVSS base score is a compression of eight metric choices - attack vector, attack complexity, privileges required, user interaction, scope, and the confidentiality, integrity and availability impacts - into one number. Every one of those choices is a judgment about the flaw as it exists in the product, and several of them are only meaningful relative to an assumed deployment. Base metrics deliberately exclude anything about a specific consumer's environment: how the software is deployed, what compensating controls sit in front of it, how valuable the data behind it is, and whether anyone is currently exploiting it. That is by design - the base score is meant to be the stable part that everyone starts from. The trouble is that 'the product as it exists' is not a single thing when you ship a library or an SDK into other people's products. ## The worked case Take a multi-tenant SaaS SDK with a bug reachable only by a caller holding the tenant-administrator role. Money and customer records sit behind it. Your product managers describe tenant admin as a privileged, contractually provisioned role; you score privileges-required as high and publish a moderate number. One of your consumers embeds the SDK in a product with self-serve signup. Anyone with an email address becomes an admin of their own tenant in ninety seconds. In that product the vulnerable path is reachable by any member of the public who is willing to click 'sign up' - and if the bug crosses tenants, that is every customer's data reachable by an anonymous internet user for the price of a free account. They recompute privileges-required as low and get a much higher number. Neither party miscalculated. You each scored a different product. The one thing that would have made this visible immediately is the vector string: it shows PR:H sitting there as the assumption doing all the work, and the consumer can point at that single metric and say 'not in our deployment'. ## What the publisher owes Three things, and they are cheap. **Publish the vector, not the number.** A bare 6.5 is a lossy hash of eight decisions. The vector string - the full `CVSS:3.1/AV:.../PR:.../...` form - lets a reader see which decision is load-bearing. Advisory formats carry severity as a vector for exactly this reason. **State the assumptions in prose.** Which role, which configuration, which entry point, which trust boundary you took as the perimeter. One sentence: 'scored assuming the tenant-administrator role is provisioned by a privileged operator; consumers who grant this role through self-service should treat privileges-required as low'. That sentence pre-empts the entire dispute and is the single highest-value thing in most vendor advisories. **Expect and welcome recomputation.** Downstream databases and consumers will produce their own numbers, and divergence is normal rather than an attack on your competence. What you want is for the divergence to be explainable from your own published data. ## When a consumer disputes your score Ask which metric they would change and why. Then one of three things is true. They are right about a supported configuration - the role really is self-serve in a way your product supports, or the entry point is reachable pre-authentication on a path you forgot. Revise the vector, reissue the entry with a note about what changed, and say plainly that the original assumption was wrong. Advisory entries are living documents; correcting one costs you far less than defending a wrong one. They are right about *their* deployment but not about yours. Say so publicly - 'in deployments where X is self-service, treat PR as low' - and let them carry their own number. That is not a concession; it is the assumption sentence you should have written in the first place. They are wrong, and you can show why from the code path. Explain the reachability, in public, on the advisory. A dispute answered with reasoning is fine. A dispute answered with authority is how vendor scores lose their standing. ## The incentive trap There is constant pressure to score low: a high number triggers customer escalations, contractual notification clauses, and awkward questions. Vendors who yield to it are noticed within about two incidents, after which consumers apply a mental multiplier to everything that vendor publishes, and the careful scoring you do on the next flaw buys nothing. Similarly, do not discount for prevalence - 'hardly anyone enables that feature' is not a base metric, it is a sentence for the details field. The reputational asset here is not being scored low. It is being scored the same way every time, with the assumptions written down, so that a consumer who disagrees can see exactly where the disagreement starts.