Building a Vulnerability Management Program on AWS: CVSS, KEV, and Reachability

Most vulnerability management programs are broken. A scanner produces 50,000 findings, the remediation team triages 200, and the rest accumulate as risk debt — until an auditor flags it or an attacker exploits one of the ignored ones. The CVE volume problem is structural: there are 30,000+ new CVEs published annually, and CVSS-only prioritization treats most of them as actionable when only a small percentage are.

This guide walks through building a vulnerability management program on AWS that scales: deploying Inspector v2 properly, prioritizing with CVSS + CISA KEV + reachability, integrating scanning into CI/CD, and setting remediation SLAs that auditors accept and engineering teams can actually meet.

Need help operationalizing vulnerability management on AWS? FactualMinds builds VM programs that move clients from CVE-counting to risk-based remediation — including Inspector v2 deployment, CI/CD integration, and SLA design. Talk to our team.

The Vulnerability Management Maturity Model

Most organizations sit somewhere on this curve:

The goal is Stage 3+. Most regulated organizations (SOC 2 / ISO 27001 / PCI DSS) need Stage 3 to pass audits. Mature security organizations operate at Stage 4.

Deploy Inspector v2 Properly

Amazon Inspector v2 is the AWS-native vulnerability scanner. It covers:

• EC2 instances — package and library vulnerabilities, network reachability assessment
• ECR container images — at push and on a continuous re-scan basis
• Lambda functions — package vulnerabilities and code analysis
• EKS / ECS — runtime monitoring (more recent capability)

Activation Pattern

Enable Inspector v2 across all accounts via AWS Organizations delegated administration:

1. Designate a security tooling account as Inspector v2 delegated admin
2. Enable Inspector v2 organization-wide
3. Configure auto-enable for new member accounts
4. Set re-scan frequency (default daily for ECR, on-demand for EC2, real-time for Lambda)

Critical Configuration

• EC2: ensure SSM Agent is installed and reporting (Inspector v2 uses SSM for inventory)
• ECR: enable enhanced scanning, not basic scanning — basic only checks OS packages
• Lambda: enable code scanning AND package scanning (separate features)
• Resource exclusion: tag resources you intentionally exclude with reasoning, don’t silently exclude

What Inspector v2 Does NOT Cover

• Application-layer vulnerabilities (your code’s own bugs) — needs SAST tools (CodeGuru Reviewer, Snyk, GitHub Advanced Security)
• Runtime vulnerabilities (live attack indicators) — needs GuardDuty Malware Protection or third-party EDR
• Configuration weaknesses (misconfigurations) — needs Config conformance packs and Security Hub standards
• Web application vulnerabilities — needs DAST tools (Burp, ZAP) and pen testing

Inspector v2 is necessary, not sufficient. A complete VM program needs SAST + DAST + dependency scanning + Inspector + IaC scanning.

Prioritization Beyond CVSS

CVSS alone produces unmanageable backlogs. Layer three additional signals:

Layer 1: CISA Known Exploited Vulnerabilities (KEV)

CISA publishes the KEV catalog — CVEs with confirmed real-world exploitation. KEV entries are the top priority regardless of CVSS score.

• KEV updates daily; integrate the feed into your prioritization
• US government Operational Directive 22-01 mandates federal agencies remediate KEV entries within tight SLAs (often 14 days)
• Inspector v2 surfaces KEV status as part of finding metadata

A CVE with CVSS 7.5 on KEV with internet exposure = critical priority. A CVE with CVSS 9.8 not on KEV in an internal-only library = lower priority than the first.

Layer 2: EPSS (Exploit Prediction Scoring System)

EPSS gives a probability score (0–1) for exploitation in the next 30 days, based on observed exploit activity. Use it to triage non-KEV findings:

• EPSS > 0.5 — high risk regardless of CVSS
• EPSS 0.1–0.5 — moderate; prioritize alongside CVSS
• EPSS < 0.1 — most CVEs land here; CVSS-based prioritization is fine

EPSS data is publicly available from FIRST.org and increasingly integrated into commercial scanners.

Layer 3: Reachability

Reachability has two dimensions:

• Code reachability: does your application actually call the vulnerable function?
• Network reachability: can an attacker reach the vulnerable resource (internet-facing, or behind multiple VPC boundaries)?

Inspector v2’s network reachability assessment for EC2 (since 2023) flags resources as internet-reachable, internally-reachable, or unreachable. Combined with code reachability tools (Snyk, GitHub, JFrog), this cuts findings by 70–90% in most environments.

The Combined Prioritization Score

A workable formula for prioritization:

priority_score = base_cvss
                * (1.5 if on_kev else 1.0)
                * (1.3 if epss > 0.5 else (1.1 if epss > 0.1 else 1.0))
                * (1.5 if internet_reachable else (1.2 if internal_reachable else 0.5))
                * (1.0 if code_reachable else 0.3)

Sort by priority_score. Top 5% become critical SLA. Top 20% become high SLA. The remainder is medium / low / batch.

Container and IaC Scanning in CI/CD

Vulnerability management has shifted left — issues caught in CI cost a fraction of issues caught in production.

Container Scanning in CI

Pipeline pattern:

1. Developer pushes code → triggers CI
2. CI builds container image
3. Trivy or Grype scans image for vulnerabilities
4. Critical findings block the build; high findings warn
5. Image pushed to ECR
6. ECR enhanced scanning runs (Inspector v2 driven)
7. ECR scan results posted to Security Hub
8. Eventbridge → Slack notification on new critical findings

GitHub Actions example for Trivy:

- name: Trivy scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ${{ env.IMAGE }}
    severity: CRITICAL,HIGH
    exit-code: '1'
    ignore-unfixed: true

ignore-unfixed: true is the productivity unlock — it skips findings without an available patch, letting you focus on actionable findings.

IaC Scanning

Infrastructure-as-code scanning catches misconfigurations before they reach production. Tools:

• Checkov — Terraform, CloudFormation, Kubernetes
• tfsec / Trivy IaC — Terraform-focused
• cfn-lint + cfn-nag — CloudFormation-specific
• kube-score / kubesec — Kubernetes manifests

Pipeline pattern: run on every PR; block merge on critical findings (e.g., S3 bucket with public-read, IAM policy with "*", no encryption configured). Findings should reference the specific control they violate (e.g., “fails CIS AWS Foundations 2.1.1”).

Dependency Scanning

For application dependencies:

• GitHub Dependabot / GitHub Advanced Security — for repos hosted on GitHub
• Snyk — language-aware SCA with reachability
• OWASP Dependency-Check — open source baseline
• AWS CodeGuru Security — AWS-integrated SAST + dependency analysis

Remediation SLAs

Document the SLA in your vulnerability management policy. A workable starting framework:

Exception Process

Some vulnerabilities cannot be remediated within SLA — vendor patch unavailable, application impact requires major refactor, business justification for risk acceptance. Exception process:

1. Risk acceptance request submitted with justification
2. Compensating controls documented (WAF rule, network isolation, monitoring rule)
3. Risk acceptance approved by named owner (CISO, product VP, etc.) with expiration date
4. Logged in risk register; reviewed at expiration

Audit-ready exception handling is non-optional for SOC 2, ISO 27001, and PCI DSS.

Reporting and Metrics

Track these metrics monthly:

• Mean time to remediate (MTTR) by severity
• SLA compliance rate by severity
• Open vulnerabilities trend (total, by severity, by reachability)
• KEV exposure — number of resources affected by KEV entries
• Patch coverage — percentage of resources with current OS / runtime / dependencies
• Container image age — average and 95th percentile of base image age in production
• Exception count — open exceptions, expired exceptions, exception trend

Report monthly to engineering leadership; quarterly to executive team and risk committee.

Compliance Mapping

Common Mistakes

After auditing many VM programs, the recurring failures:

1. CVSS-only prioritization — produces unmanageable backlogs and misses real risk
2. No reachability filter — every theoretical CVE is treated as actionable
3. CI scanning without enforcement — scans run, findings reported, builds proceed anyway
4. Manual remediation tracking — spreadsheets that go stale; findings re-discovered cycle after cycle
5. No SLA enforcement — SLAs documented but not measured; high-severity findings linger for months
6. Inspector v2 enabled but not operationalized — findings sit in Security Hub unread
7. Container base images frozen — apps run on 2-year-old base images, accumulating vulnerabilities
8. No SBOM — when a Log4Shell-class event hits, you cannot quickly identify affected systems

Getting Started

A 90-day VM program kickoff:

• Days 1–14: Inspector v2 deployed organization-wide; ECR enhanced scanning enabled; SBOM tooling stood up
• Days 14–30: CI/CD container scanning enforced; IaC scanning enforced
• Days 30–60: Prioritization model (CVSS + KEV + EPSS + reachability) implemented in Security Hub or third-party tool; remediation SLAs documented and approved
• Days 60–90: Monthly reporting cadence established; first remediation cycle complete; exception process operational

After 90 days, you have a measurable VM program. After 6 months, you have audit-ready evidence that satisfies SOC 2 / ISO 27001 / PCI DSS reviewers.

Related Resources

• Inspector v2 Production Setup — deep dive on Inspector v2 deployment
• AWS Penetration Testing — the offensive complement to defensive vulnerability management
• AWS Managed SOC & MDR — operational layer that triages findings 24/7
• Cloud Compliance Services — broader compliance program work
• Drift Detection on AWS — sister practice for configuration governance

Get Started

If your scanner inbox has 50,000 findings nobody is acting on, your auditor flagged a “vulnerability management deficiency,” or you’re spending engineering time on CVE-counting instead of real risk reduction — let us help.

Talk to our security team →