Generic vulnerability scores—CVSS, EPSS, and their combinations—are useful inputs but don’t produce a prioritization order that accounts for your specific environment, your organization’s risk tolerance, or the actual execution context of your containers. A custom risk score that combines these inputs with environment-specific factors produces a prioritization order that reflects actual risk to your organization, not theoretical risk to a generic deployment.
Building a custom score requires defining what factors matter for your specific threat model and how to weight them. This is more art than science, but the discipline of defining it explicitly is itself valuable—it forces the security team to articulate what they believe drives actual exploitation risk.
Why Generic Scores Fall Short for Containers?
CVSS scores severity in a generic context. The score reflects how dangerous a vulnerability would be under ideal exploitation conditions, without considering whether those conditions apply to your specific containers.
EPSS scores exploitation probability across all environments using a given package. A CVE with high EPSS is being exploited broadly—but “broadly” means across all internet-connected environments, not necessarily yours. Your environment’s exposure profile may be materially different from the population EPSS is modeling.
Neither score accounts for the most important container-specific variable: runtime reachability. Whether the vulnerable package executes in the specific container matters more for actual risk than any generic score.
A custom risk score can incorporate reachability as a first-class input, producing a score that reflects risk in your specific containers rather than risk in a theoretical generic environment.
Components of a Container Risk Score
Base severity (from CVSS)
CVSS provides a reasonable starting point for base severity. Use the CVSS base score (0-10) as one component. The base score reflects the theoretical severity ceiling—the worst-case impact if the vulnerability is exploited under optimal conditions.
Weight: 25-30% of the composite score. High enough to capture severity distinctions; low enough to be overridden by more environment-specific factors.
Exploitation probability (from EPSS)
EPSS provides current exploitation probability data. Higher EPSS scores indicate the CVE is being exploited now or is similar to CVEs being exploited now. This is a dynamic signal—EPSS scores update daily—which means the composite risk score updates continuously as exploitation patterns change.
Weight: 25-30% of the composite score. EPSS and CVSS often diverge: high-CVSS CVEs with no exploitation activity get downweighted; low-CVSS CVEs with active exploitation get upweighted.
Runtime reachability (from profiling)
This is the environment-specific variable that generic scores don’t capture. Runtime profiling data provides a binary or tiered reachability signal:
- Not executable in this container (package not present or not loaded): Risk score multiplied by 0.1 or similar near-zero factor. The vulnerability exists on paper; it doesn’t exist in this container’s execution context.
- Executable but not in critical paths: Risk score unchanged.
- Executable in internet-facing or high-privilege code paths: Risk score multiplied by 1.5-2.0.
Weight: Implemented as a multiplier rather than an additive component. Reachability gates whether the other score components apply at their full value.
Exposure context
Network exposure adds context that CVSS and EPSS don’t capture for your specific deployment:
- Container is internet-facing with direct user input: exposure multiplier 1.5
- Container is internal-only, no external network access: exposure multiplier 0.5
- Container runs privileged or has elevated cluster permissions: exposure multiplier 1.3
Exposure context should be maintained as container metadata and applied automatically when the risk score is computed.
KEV membership
CISA KEV inclusion is a high-confidence exploitation signal that should override other score components. A binary flag—in KEV or not—applied as a score floor: any CVE in the KEV that executes at runtime receives a minimum risk score regardless of CVSS or EPSS values.
Composite Score Formula
A simple composite score for illustration:
risk_score = (cvss_weight × normalized_cvss +
epss_weight × normalized_epss) ×
reachability_multiplier ×
exposure_multiplier
if kev_member and runtime_executable:
risk_score = max(risk_score, kev_floor_score)
Where:
- cvss_weight and epss_weight are organization-defined constants summing to 1.0
- normalized_cvss is CVSS base score / 10
- normalized_epss is the raw EPSS score (already 0-1)
- reachability_multiplier is 0.1 (not reachable), 1.0 (reachable), or 1.5 (reachable in critical path)
- exposure_multiplier is defined per container deployment context
- kev_floor_score is the minimum acceptable priority score for any KEV CVE in an executable package
Connecting Risk Scores to Remediation Actions
A risk score is useful for prioritization but most effective when it drives automated actions, not just queue ordering:
High score + reachable: Create urgent remediation ticket. If the reachable package can be removed (it’s not required by the application), automated hardening removes it immediately. If the package is required, the ticket routes to the engineering team with remediation instructions.
Medium score + not reachable: Container security hardening pipeline removes the package automatically. No ticket created; the CVE is eliminated through automated removal.
Low score + not reachable: Remove the package in the next scheduled hardening cycle. Low urgency; automated.
The score-to-action mapping converts the risk score from a prioritization list into a workflow driver.
Practical Steps for Custom Score Implementation
Start with a simple formula and iterate. A three-component weighted average (CVSS + EPSS + reachability binary) is sufficient to start. Validate the score against historical CVE incidents: would the formula have correctly prioritized the CVEs that caused actual incidents? Iterate based on validation findings.
Calibrate weights against your threat model. An organization primarily concerned about exploitation of internet-facing services should weight reachability and exposure context highly. An organization primarily concerned about compliance should weight CVSS scores more heavily because compliance frameworks use CVSS for SLA assignment.
Validate against KEV retrospectively. Take the past year’s KEV catalog additions and score them with your formula. What fraction were in the top quartile of your risk scores? A well-calibrated formula should rank most KEV CVEs in the high-risk tier.
Use hardened container images as the baseline for scoring. Score CVEs against the minimized container image (after unused packages are removed), not the original image. Scoring against the original image includes CVEs that will be eliminated through automated hardening and inflates the high-risk count.
Document the formula and its rationale. A custom risk score that can’t be explained to auditors or executives isn’t credible. Document what each component measures, why it’s included, and how the weights were chosen. This documentation is also the foundation for future calibration decisions.
Frequently Asked Questions
What is a custom vulnerability risk score and why is it better than CVSS alone?
A custom vulnerability risk score is a composite scoring formula that combines multiple inputs—CVSS severity, EPSS exploitation probability, runtime reachability, and deployment-specific exposure context—into a single prioritization number calibrated to your specific environment. It outperforms CVSS alone because it incorporates the most important container-specific variable: whether the vulnerable package actually executes in the container. A high-CVSS CVE in a non-executing package scores near zero in a well-calibrated custom score; a moderate-CVSS CVE in an internet-facing, actively-called package scores high. CVSS alone cannot make this distinction.
How do you build a custom vulnerability risk score for container environments?
A practical custom vulnerability risk score combines: CVSS base score (normalized 0-1, weighted 25-30%), EPSS score (raw 0-1, weighted 25-30%), runtime reachability as a multiplier (0.1 for non-executing packages, 1.0 for executing, 1.5 for executing in critical internet-facing paths), and exposure context as a secondary multiplier (adjusted for whether the container is internet-facing, internal-only, or privileged). CISA KEV membership applies a score floor for any KEV CVE in an executing package, overriding the formula. Start simple—three components are sufficient to validate the approach—and iterate based on retrospective analysis of whether the formula correctly ranked historical incidents.
How do you validate a custom vulnerability risk scoring formula?
Validate a custom vulnerability risk score by retrospective analysis: take the past year’s CISA KEV catalog additions and score them with your formula. A well-calibrated formula should rank most KEV CVEs in the top quartile of scores for the affected containers. Additionally, review historical security incidents or near-misses at your organization and confirm those CVEs would have scored in the highest-priority tiers. Document the validation methodology alongside the formula—auditors and executives will ask how the scoring approach was tested.
How does vulnerability risk scoring connect to automated remediation actions?
A vulnerability risk score is most effective when it drives automated workflow decisions rather than just queue ordering. High-scoring CVEs in reachable packages should trigger urgent remediation tickets with specific instructions. Medium-scoring CVEs in non-reachable packages should route to automated hardening—the package is removed without creating a ticket. Low-scoring CVEs in non-reachable packages are handled in the next scheduled hardening cycle. This score-to-action mapping converts vulnerability risk scoring from a prioritization list into a workflow driver that reduces manual triage and accelerates remediation for genuinely high-risk findings.
The Benefit of Explicit Scoring
Custom risk scoring makes implicit prioritization decisions explicit. Every vulnerability management team is implicitly prioritizing—by what they work on first, by what tickets get created, by what thresholds trigger escalations. Making the scoring formula explicit creates accountability, enables calibration based on outcomes, and allows the organization to communicate its risk prioritization approach to external stakeholders.
A well-calibrated custom score that correctly identifies high-risk findings and routes low-risk findings to automated handling is more valuable than any generic score precisely because it’s calibrated to the specific environment it’s managing.