When the Vendor Says False Positive and the Client Says Downgrade

The vendor is arguing about identifier entropy when the finding is about missing authorisation checks. That distinction has to be made explicit and evidenced.

The reply contains:

• The demonstration, mechanically. Recorded HTTP requests and responses for both paths, with timestamps, the two accounts used, and the exact object identifiers redacted to their first and last four characters. A GUID is only unguessable; it is not authorisation. If the server accepts any GUID the caller presents and returns the object without checking that the caller owns it, the control is absent.
• The leak path. The unauthenticated endpoint that returned GUIDs is itself part of the finding: it converts a theoretically unguessable identifier into a supplied one. Attach the response showing the enumeration.
• The fix the vendor should implement. Server-side ownership check on every object retrieval, not a longer or random identifier. Recommend the vendor test with two accounts of different tenants, both directions, including a 403/404 expectation and a note on whether 404 versus 403 leaks existence.
• A reproducibility note. Two accounts, sequence of steps, expected versus observed status codes, so an independent engineer can repeat it in ten minutes.

Keep the tone factual and non-accusatory; the goal is a fixed bug, not a won argument. Log the dispute and the vendor's response in the report's findings table under a vendor-response column so the reader sees an open disagreement rather than a silent deletion. Add a retest commitment at no cost if the vendor still disagrees, because a witnessed reproduction ends the debate faster than any wording.

Reachability is a legitimate factor, but it belongs in the environmental and threat components of the score, not in a hand-wave that erases the base severity.

My position:

• The base score reflects the intrinsic characteristics of the vulnerability: no authentication, remote code execution, high confidentiality, integrity and availability impact. That does not change because of where the service sits.
• The environmental score should reflect modified attack vector for a VPN-only service, and the threat metric should reflect whether exploitation is observed in the wild. Show both numbers rather than arguing about one.
• Then challenge the premise of the mitigation. VPN accounts are phished, replayed and MFA-fatigued, and the same endpoint may be reachable from partner or integration networks that the IT manager has not considered. Ask, in writing, whether any non-VPN path exists, and verify it if authorised, because 'it is only on the VPN' is frequently untrue.
• Note that the VPN is a compensating control whose effectiveness depends on patching, MFA enforcement and account hygiene, all of which the same assessment probably tested.

Process: present the base score, the environmental score with a stated rationale, and the residual risk. If the client still wants Medium, that is a risk decision, not a finding edit - it requires a documented risk acceptance signed by someone with the authority to accept it, referenced in the finding. I will record the disagreement in the report and defend the original in any later conversation. Silently downgrading a finding to keep a client comfortable is the one outcome that is not available.

Retest slots should follow risk and verification value, not a first-come order.

Selection criteria, applied in order:

1. Critical and High findings where a fix is claimed. Seven of these exist, so all seven go in the 10; anything still open is worse than untested.
2. Findings whose remediation is cheap to verify and high-consequence if partial: authentication bypass, the IDOR, the deserialisation RCE, exposed management interfaces.
3. Two or three Medium findings that test whether a class of problem was fixed generally rather than instance by instance - for example one SQL injection and one authorisation finding, to see whether the team applied a central fix.
4. Do not spend slots on the two ERP Criticals that cannot be patched. Instead, verify the compensating controls the client claims (network restrictions, WAF rules, monitoring), and state plainly that the underlying vulnerability remains open.

Board summary, one page:

• Four sentences of context: what was tested, when, and against what scope.
• A table of counts by severity, plus how many are fixed, in progress and open.
• The two or three findings that represent genuine business risk, written in business terms: patient or customer data exposure, payment integrity, regulatory exposure.
• What the board is being asked to decide: fund the ERP upgrade path, accept documented risk on the unpatched items, and approve a retest date.
• No tool names, no payloads, no CVE lists in the one-pager; those live in the technical annex.

Send the one-pager with the full report referenced, and offer a fifteen-minute walkthrough, because a document nobody explains gets filed and forgotten.