Actionable Security: Moving From 'We Have 3,847 Vulnerabilities' to 'Here's What We Do Next'

Your security programme produces impressive volumes of data. Vulnerability scans generate thousands of findings. SAST tools flag hundreds of code issues. Container scanners report dozens of image vulnerabilities per build. Runtime monitoring logs millions of events. Policy engines evaluate thousands of deployments.

And yet, when the CISO asks "are we more secure this quarter than last quarter?", nobody can answer with confidence. When an engineer asks "what should I fix first?", the answer is "everything marked critical" — which is 400 items. When the board asks "what's our risk?", the answer is a number that means nothing to anyone outside the security team.

The gap between security data and security action is where most programmes fail. This article closes that gap.

The Three Questions

An actionable security programme answers three questions, continuously:

1. What is our actual risk right now? (Not theoretical risk. Not CVSS score risk. Actual, contextualised, exploitability-weighted risk)
2. What should we do next? (Specific, prioritised, assigned actions — not a 400-item critical list)
3. Are we getting better or worse? (Trend metrics that show improvement or degradation over time)

Question 1: What Is Our Actual Risk?

Contextualised Risk Scoring

Raw CVSS scores are theoretical. Actual risk depends on context:

Risk score calculation

actual_risk = base_severity
* exploitability_factor # EPSS score (0.0 - 1.0)
exposure_factor # Internet-facing	1.0, Internal: 0.3, Air-gapped: 0.1
data_sensitivity_factor # Regulated data	1.0, Internal: 0.5, Public: 0.1
compensating_controls # WAF present	0.7, Network isolated: 0.5, None: 1.0
Example:
CVE-2026-XXXXX (CVSS 9.8)
* EPSS 0.02 (2% exploitation probability)
* Internal service (0.3)
* No regulated data (0.1)
* Behind NetworkPolicy (0.5)
= 9.8 * 0.02 * 0.3 * 0.1 * 0.5 = 0.003 → Actual risk	negligible
CVE-2026-YYYYY (CVSS 7.5)
* EPSS 0.87 (87% exploitation probability)
* Internet-facing API (1.0)
* Processes payment data (1.0)
* No WAF (1.0)
= 7.5 * 0.87 * 1.0 * 1.0 * 1.0 = 6.525 → Actual risk	HIGH, fix immediately

The CVSS 9.8 is lower actual risk than the CVSS 7.5. Without contextualisation, your team patches the wrong one first.

Risk by Business Service

Aggregate risk at the business service level, not the CVE level:

• Payment API: Risk score 2.1 (low) — 0 critical findings, 2 high with mitigations, all patches current
• Customer Portal: Risk score 5.8 (medium) — 1 critical (EPSS 0.6, internet-facing), patch in progress
• Internal Admin: Risk score 1.4 (low) — multiple CVEs but all internal, low EPSS, behind VPN

This is the view the CISO presents to the board. Specific, contextualised, actionable.

Question 2: What Should We Do Next?

The Priority Queue

Instead of a flat list of 3,847 findings, build a priority queue that always shows the highest-impact action at the top:

1. Actively exploited + internet-facing + regulated data: Fix within 24 hours (CRA notification may be required)
2. High EPSS + internet-facing: Fix within 48 hours
3. High EPSS + internal: Fix within 1 week
4. Low EPSS + internet-facing: Fix within 2 weeks
5. Low EPSS + internal: Fix within 30 days
6. Accepted risk with compensating controls: Review quarterly

The queue auto-populates from your scanning pipeline. Each item shows: what to fix, where it is, who owns it, and whether a patch/PR already exists. The engineer's workflow: look at the top of the queue, fix it, move to the next one.

Automated Action Generation

Go beyond "here's a finding" to "here's the fix":

• Dependency vulnerabilities: Renovate/Dependabot auto-creates the PR. The finding links directly to the PR. The engineer's action: review and merge
• Container base image vulnerabilities: Platform team rebuilds golden images. Downstream services pick up the fix on next build. The finding auto-closes when the patched image deploys
• Configuration issues: Policy violations link to the specific Kyverno/OPA policy and the documentation for how to comply. Not "your pod violates policy X" but "add readOnlyRootFilesystem: true to your container spec"
• Missing controls: "This namespace lacks a NetworkPolicy" links to the template repository where the engineer can copy a ready-made policy

Question 3: Are We Getting Better?

The Metrics That Matter

• Mean Time to Remediate (MTTR) by severity: The single most important metric. Are you fixing critical findings faster this month than last month? Target: <24h critical, <7d high, <30d medium
• Findings opened vs. closed per week: Is the backlog growing or shrinking? If opened > closed consistently, you have a capacity problem
• SLA compliance: What percentage of findings are remediated within their SLA? Target: 95%+. Below 80% means your SLAs are either wrong (too aggressive) or your capacity is insufficient
• Risk score trend: Is aggregate risk per business service going up or down? This is the metric for the board
• Automation coverage: What percentage of findings have automated fixes (Renovate PRs, base image updates)? Higher automation = faster remediation with less human effort
• Security gate pass rate: What percentage of deployments pass security checks on first attempt? >95% means your defaults are working. <80% means your golden paths need improvement

From Dashboard to Workflow

The actionable security programme isn't a dashboard you look at — it's a workflow that runs:

1. Scan continuously: SBOM scanning, image scanning, SAST, policy evaluation — running on every build and on a 15-minute schedule for production
2. Contextualise automatically: Enrich findings with EPSS, exposure data, data classification, and compensating controls
3. Prioritise automatically: Calculate actual risk score, populate the priority queue
4. Generate actions automatically: Create PRs, link to templates, assign to owning teams
5. Track SLAs automatically: Escalate findings approaching their SLA deadline. Auto-notify the team lead at 75% of SLA, the engineering director at 100%
6. Report continuously: Risk score per service, MTTR trends, SLA compliance — updated in real-time, not quarterly

What Open Empower Delivers

We build actionable security programmes for regulated enterprises:

• Risk contextualisation: EPSS enrichment, exposure analysis, data classification integration, and compensating control mapping
• Priority queue implementation: Automated prioritisation that always shows the highest-impact action next
• Automated remediation: Renovate/Dependabot integration, golden image pipelines, policy templates
• SLA tracking: Escalation workflows, team notifications, leadership reporting
• Trend dashboards: MTTR, SLA compliance, risk score, automation coverage — the metrics that prove improvement
• Compliance mapping: CRA, DORA, NIS2 requirements mapped to your findings and remediation evidence

Security data without action is just expensive noise. Let's turn yours into outcomes.