CVSS Backlog Versus Scenario-Based Risk Ranking
Meridian Pay is a payment-orchestration SaaS with 3.2 million stored customer records and 120 microservices across 14 AWS accounts. A quarterly scan produced 2,300 findings: 37 CVSS 9.8 findings on internet-facing APIs protected by a WAF, and one CVSS 7.5 flaw on an internal legacy billing server that holds tokenized card data and has no known public exploit. Month-end outages cost $85,000 per hour, and a breach involving 100,000 records would trigger notification, card-brand fines, and an estimated $6.4 million response cost. The CRO must present a risk-ranked remediation plan to the board in two weeks. Engineering can close only 20 percent of critical findings per sprint, and changing the billing server requires a four-week freeze because finance closes the ledger monthly. The WAF blocks known signatures but not business-logic abuse. No threat-intelligence subscription is in place. The board equates a CVSS 9.8 score with urgent risk.
1. How should the CRO challenge a CVSS-only ranking and build a risk-based remediation case?
Read the worked answer
CVSS measures technical severity, not business risk. The CRO should translate findings into scenarios that combine threat likelihood, exposure, control effectiveness, asset criticality, and impact. The 37 CVSS 9.8 API findings are not automatically the top 37 risks: some may be false positives, require authentication, or be mitigated by the WAF for known signatures. But the WAF does not stop business-logic abuse, so API findings that enable object-level authorization bypass or mass data access deserve high weight. The internal CVSS 7.5 billing flaw has lower reachability and no known public exploit, which lowers likelihood. However, tokenized card data, financial-close dependency, and a four-week change freeze raise impact and mean an attacker who reaches the internal network could cause a costly month-end outage. Build two scenarios: API authorization bypass leading to 100,000-record breach, and billing-server compromise leading to ledger downtime. Estimate frequency and loss ranges, then rank by risk reduction per engineering day. State explicitly that CVSS is an input, not the output, and show the board the assumptions behind likelihood and impact.
2. Recommend a two-sprint remediation plan and interim treatment for the billing server.
Read the worked answer
Sprint 1 should validate and close the API findings most likely to permit real data access or business-logic abuse, not merely the highest scores. Use WAF virtual patching, stricter schema validation, rate limiting, and anomaly monitoring as interim controls while engineering fixes root causes. Prioritize findings with public exploit code, no authentication, or access to customer records. Sprint 2 should address the remaining criticals by risk tier and add threat-intelligence feeds or exploitability data so the next cycle is not score-driven. For the billing server, the four-week freeze prevents a normal change, so use compensating controls: segment the server, restrict access through a hardened jump host with MFA, deploy file-integrity monitoring and enhanced logging, verify backups, and prepare an emergency change trigger if exploit activity appears. The CRO and CFO should sign a time-bound risk acceptance stating the residual risk and the conditions that would force an emergency change. Report to the board the residual risk by scenario, not a count of CVSS 9.8 findings, and track remediation capacity against the 20 percent constraint.