Ninety-Six Scanner Highs, One Real Customer Invoice, and a Report Due Friday
Two days before the report deadline you have 1,400 pages of scanner output, 96 items the scanner labelled High, and your own manual notes. Three findings compete for the top of the executive summary. (a) An unauthenticated IDOR at GET /api/invoices/{id} with sequential IDs: you fetched 40 invoices belonging to your seeded test accounts and, while stepping through IDs, one belonging to a real customer. (b) A scanner-reported SQL injection on ?sort=: you confirmed the only response is a WAF 403 page that reflects your payload, with no time or boolean differential. (c) TLS 1.0 and a SHA-1 certificate on promo.example.com, a static marketing microsite with no login and no data. The CISO wants "the CVSS score" for each and asks why the scanner's 96 Highs are not in your report.
1. Rank the three findings and justify each score.
Read the worked answer
The IDOR is the top item and the only one that belongs in the executive summary. AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5, and that is the base score; the environmental picture (sequential IDs, no authentication, regulated customer invoice data, trivial automation) argues for scoring it at the top of the client's own risk scale rather than discounting it. The impact statement should quantify: IDs are sequential, so the entire invoice table is enumerable with a single loop.
The ?sort= item is a false positive, not a finding. The scanner matched its own payload inside a WAF block page; your control request (?sort=name versus ?sort=name') produces the same 403, and there is no timing or boolean differential. Score: none - close it with the evidence.
The TLS item is real but low: TLS 1.0 and SHA-1 are hygiene, not an exploitable server-side flaw. AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N ≈ 3.7 is a defensible figure, and it belongs in a hardening section, not beside a data-exposure bug. Putting it in the summary dilutes the one thing the CISO must act on.
2. You accidentally retrieved one real customer's invoice. What do you do, and what appears in the report?
Read the worked answer
Treat it as a personal-data incident caused during testing, because that is what it is. Stop enumerating immediately - do not fetch "just one more" to confirm the pattern, you already have 40 test-account records and a single out-of-scope record as proof.
In the report, the finding is described as "40 records from seeded test accounts, plus one out-of-scope record retrieved inadvertently and handled under the incident process" - with no customer name, address, amount, or full invoice ID reproduced. If a screenshot is needed, mask the identifier to the first and last two characters. The point of the finding is enumeration, not the content.
Separately and immediately, notify the client's DPO or incident contact through the agreed channel, ahead of the report, with the timestamp, the request, and the confirmation that the response was deleted from your workstation (and from backups/trash, stated explicitly). Log the notification and deletion in the engagement record, and offer the client the option to treat it under their own breach process. The remediation is unchanged: replace sequential IDs with unguessable ones and enforce object-level authorisation - the IDOR is the vulnerability; your access to one record is a symptom of it.
3. How do you answer the CISO's question about the 96 missing scanner Highs without appearing to have done less work?
Read the worked answer
Reframe the deliverable: the scanner produced 1,400 pages of output; your job produced a set of validated findings. Then show the work rather than asserting it.
Include an appendix table mapping every scanner High to a disposition - true positive (merged into a finding), duplicate of another item, or rejected - with a one-line reason and the request/response pair that justifies it. The WAF-reflection example belongs there in full: the two control requests and the identical 403 body make it self-evidently a false positive and let the client reproduce your reasoning without trusting you.
The framing that lands with a CISO is that an unvalidated 96-item list is not more thorough, it is unusable: it cannot be prioritised, it will be triaged by the client's own team at cost, and the three items that actually matter get lost in it. Offer the raw scanner export as an attachment so nothing is hidden, and state the counts explicitly: "96 scanner Highs reviewed; N confirmed, M duplicates, K rejected as false positives." That table is a credibility asset - it shows you validated and were willing to discard, which is the opposite of padding.