Cloud security finding prioritisation
by blast radius, not by CVSS alone, so the queue ordering matches the actual cloud risk distribution

The team queues by CVSS base score and a privilege escalation on an isolated sandbox reads at the same priority as a privilege escalation on the production payments cluster because the rule pack assigns identical base scores. CVSS captures the technical severity of the vulnerability class but it never captures the identity reach, the network exposure, the data classification, or the workload tier of the affected resource. The queue ordering pretends the cloud estate is uniform when the actual blast radius distribution is anything but.

A scanner fires a finding at high severity and the team agrees verbally that on this asset the severity should be medium because the resource is in a contained subnet with no production data. The verbal calibration never lands on the record, the next ingestion overwrites the severity, and the audit lookback reads a contradictory queue ordering with no documented rationale. Severity calibration that should be a recorded state event drifts into oral tradition that does not survive the next personnel rotation.

The routing decision reads the cloud account or subscription identifier and stops there. A finding on a production account routes to the cloud team and a finding on the sandbox account also routes to the cloud team, but the priority order inside the queue does not reflect that the production account hosts the customer database while the sandbox account hosts a developer sandbox. The cloud account is a routing primitive, not a prioritisation primitive, and treating it as both buries the actually critical findings.

The triage step records the initial compromise but the trust paths an attacker reaches after the foothold are never written down. The next red team exercise demonstrates a path from a low-priority finding on a build runner to the production KMS key, and the post-exercise review asks why the prioritisation queue did not surface the lateral reach. The reach was always derivable from the IAM trust graph and the Kubernetes RBAC graph, but nobody recorded it as a structured field on the finding.

The cloud platform team knows which buckets hold PCI data, which subscriptions hold PHI, and which secrets protect customer-trust pillars. The knowledge lives in the heads of three engineers and in a wiki page nobody updates. When a finding lands on a resource that the wiki forgot to tag, the prioritisation queue inherits the default severity and the PCI-relevant exposure ages alongside the marketing-asset exposure because the classification never reached the record.

The quarterly cloud posture briefing presents the open finding count by severity and the CISO reads a number. The number does not say how many of the highs touch production cardholder data, how many of the criticals carry cross-account assume-role reach, or how many sit on workloads that fail customer-facing traffic if compromised. The leadership view loses the prioritisation context that the operational queue depends on, and the resource allocation conversation defaults to the headline count.

A structured field on the finding capturing the IAM identity the affected resource carries, the trust boundary that identity crosses (single account, cross-account assume-role, cross-region, cross-organisation), and the set of downstream resources the identity can reach. The summary is captured at triage and updated when the identity boundary changes. The record holds the calibration rationale rather than a generic severity adjective.

Whether the affected resource is internet-facing, peered to other internal networks, reachable from on-premises through a hybrid connection, reachable from a partner or supplier network, or contained to a private subnet. The exposure profile is confirmed by an external scan probe where it is plausibly reachable from the internet so the calibration reads the runtime reach rather than the IaC intent.

The regulated and contractual data classification of the affected resource: PCI cardholder data, PHI, regulated PII, source code, customer-trust secrets, business-confidential, or non-sensitive. The classification inherits from the engagement record and the resource tag set, and the calibration narrative cites the data-classification source so the audit lookback reads a defensible rationale rather than a guess.

The workload tier the affected resource serves (production customer-facing, production internal, staging, sandbox, dev) and the dependent business processes that degrade if the workload is compromised. The tier feeds the SLA window the finding inherits and the routing priority the queue applies. A finding on the production payments workload and a finding on the developer sandbox carry the same vulnerability class at different priority because the workload context is different.

A short narrative captured at triage describing the trust paths an attacker reaches after the initial compromise: which other identities the foothold can assume, which downstream APIs the workload can call with stored credentials, which secrets the workload can decrypt, which Kubernetes namespaces the service account reaches. The narrative makes the second-order exposure explicit so the prioritisation queue ordering reflects the lateral reach rather than just the initial compromise.

The final calibrated priority and SLA tier the finding lands at, alongside a short cited rationale that names the dimensions used to recalibrate from the scanner default. The cited rationale is the audit-ready answer to why the queue ordering diverges from a CVSS-only sort. When a finding moves between calibrated tiers later, the state event lands on the activity log with the user attribution and the cited rationale rather than as an inline edit nobody can reconstruct.

Blast-radius calibration depends on cloud security assessment for the broader programme, CSPM finding remediation for the operational lifecycle on the engagement record, asset criticality scoring for the workload-tier and data-classification inheritance, asset ownership mapping for the named owner the calibrated priority routes to, CVE and EPSS enrichment for the exploitation likelihood dimension that pairs with blast radius, scanner result triage for the per-detection lifecycle inside the cloud queue, Kubernetes security finding remediation for the per-cluster reach calibration, and vulnerability prioritisation for the general prioritisation reference that names CVSS, EPSS, and asset criticality as inputs.

Calibrated priority feeds security finding ownership and routing for the named owner assignment, vulnerability SLA management for the time-bound resolution discipline, vulnerability acceptance and exception management for the compensating-control downgrade flow, control mapping cross-framework crosswalks for the framework evidence package, security leadership reporting for the cadence that reads weighted exposure as a leading indicator, and audit evidence retention and disposal for the long-tail evidence chain.

The six dimensions land as structured metadata on the finding record at triage. The queue ordering reads against the calibrated priority rather than against the scanner default, and the leadership view derives the weighted exposure from the same record the team triages against.

Identity reach is derived from the IAM trust graph and the Kubernetes RBAC graph for the affected resource. Network exposure is confirmed by an external scan probe. Both land on the record so the calibration narrative cites the source rather than relying on tribal knowledge.

Every recalibration that diverges from the scanner default lands on the activity log with cited rationale and named user. Compensating-control downgrades ride on the structured override workflow with cited approver, target resource scope, and expiry. The audit lookback reads the calibration trail rather than reconstructing it.

The quarterly cloud posture briefing reads open count by workload tier, by data classification, and by identity reach band. The CISO sees the weighted-exposure distribution rather than an unweighted open count that hides the prioritisation context.