--- title: Building a Vulnerability Management Program on AWS: CVSS, KEV, and Reachability description: How to build a vulnerability management program that scales beyond CVE-counting. Inspector v2 deployment, CVSS + CISA KEV + reachability for risk-based prioritization, container and IaC scanning in CI/CD, and remediation SLAs that survive audits. url: https://www.factualminds.com/blog/aws-vulnerability-management-program-cvss-kev-prioritization/ datePublished: 2026-04-27T00:00:00.000Z dateModified: 2026-06-11T00:00:00.000Z author: Palaniappan P category: Security & Compliance tags: vulnerability-management, aws-security, inspector, cvss, cve, compliance, security, aws --- # Building a Vulnerability Management Program on AWS: CVSS, KEV, and Reachability > How to build a vulnerability management program that scales beyond CVE-counting. Inspector v2 deployment, CVSS + CISA KEV + reachability for risk-based prioritization, container and IaC scanning in CI/CD, and remediation SLAs that survive audits. 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](/amazon-inspector-v2-container-lambda/), CI/CD integration, and SLA design. [Talk to our team](/contact-us/). ## The Vulnerability Management Maturity Model Most organizations sit somewhere on this curve: | Stage | What it looks like | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | **0 — Reactive** | Patches happen when something breaks; no scanning; no inventory | | **1 — Scanning** | Some scanner runs; findings inbox accumulates; nobody triages | | **2 — Triaged** | Findings are reviewed; CVSS-based prioritization; manual remediation; backlog grows | | **3 — Risk-based** | CVSS + KEV + reachability for prioritization; SLAs defined; tracked monthly | | **4 — Continuous** | CI/CD blocks builds with critical issues; reachability analysis cuts noise; auto-remediation for known patterns; SBOMs maintained | 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: ```yaml - 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: | Severity | Definition | SLA | Notes | | ------------ | ---------------------------------------------- | ----------- | ----------------------------- | | **Critical** | KEV-listed + reachable, or priority_score ≥ 12 | 7 days | Includes weekend; pages owner | | **High** | CVSS ≥ 7 + reachable, or priority_score 8–12 | 30 days | Standard sprint | | **Medium** | CVSS 4–6.9, or unreachable high | 90 days | Quarterly batch | | **Low** | CVSS < 4 | Best effort | Batched annually | ### 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 | Framework | Requirement | | ---------------------------- | ------------------------------------------------------------------------------ | | PCI DSS 4.0 Req 6.3 | Identify and rank vulnerabilities; remediate critical and high in 30 days | | PCI DSS 4.0 Req 11.3 | External and internal vulnerability scans quarterly + after significant change | | SOC 2 CC7.1 | Detection and monitoring of vulnerabilities | | ISO 27001 A.8.8 | Management of technical vulnerabilities | | HIPAA §164.308(a)(8) | Technical evaluation including vulnerability assessment | | NIST CSF 2.0 ID.RA, PR.PS-06 | Vulnerability identification and software updated | | FedRAMP RA-5 | Vulnerability scanning | ## 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. ## Application-logic layer (May 2026) Inspector and CVE prioritization cover **package and infrastructure exposure**. They do not catch unsafe trust boundaries or data paths across the application. Layer **[AWS Security Agent full-repository code review](/blog/aws-security-agent-full-repository-code-review/)** under the same VM program: Inspector for inventory, Security Agent for architectural defects, pipeline SAST for per-PR gates. ## Related Resources - [Inspector v2 Production Setup](/amazon-inspector-v2-container-lambda/) — deep dive on Inspector v2 deployment - [AWS Security Agent full-repository code review](/blog/aws-security-agent-full-repository-code-review/) — trust-boundary analysis complement to CVE scanning - [AWS Penetration Testing](/services/aws-penetration-testing/) — the offensive complement to defensive vulnerability management - [AWS Managed SOC & MDR](/services/aws-managed-soc-mdr/) — operational layer that triages findings 24/7 - [Cloud Compliance Services](/services/cloud-compliance-services/) — broader compliance program work - [Drift Detection on AWS](/aws-infrastructure-drift-detection-terraform/) — 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 →](/contact-us/) ## FAQ ### What is the difference between vulnerability management and penetration testing? Vulnerability management (VM) is continuous and breadth-focused — automated scanning across your entire environment, looking for known vulnerabilities (CVEs) at scale. Penetration testing is periodic and depth-focused — manual exploitation of specific systems by skilled testers, finding business logic flaws and chained exploits scanners cannot. They complement each other: VM tells you what known issues exist; pen testing tells you what attackers can do with them. PCI DSS, SOC 2, ISO 27001, and HIPAA all require continuous VM AND periodic pen testing — they are different controls satisfying different requirements. ### Should I use Inspector v2 or third-party tools like Qualys/Tenable/Wiz? Inspector v2 (Amazon's native service) is the right starting point for AWS-only environments — it's agentless, integrated with AWS Organizations, and covers EC2, ECR, and Lambda with risk scoring. Third-party tools (Qualys VMDR, Tenable.io, Wiz, Lacework, Orca) add value when: (a) you have multi-cloud environments, (b) you need application-layer scanning beyond what Inspector covers, (c) you require specific compliance reports their platforms generate, or (d) you have on-premises infrastructure to consolidate. Most mid-market AWS-native organizations get 80% of value from Inspector v2 + ECR scanning + Trivy in CI/CD; enterprise environments often layer one third-party tool on top for cross-cloud visibility. ### How does CVSS differ from EPSS and CISA KEV — and which should I use for prioritization? CVSS (Common Vulnerability Scoring System) is a severity scale (0–10) based on theoretical impact — useful but flawed because most CVEs are theoretically severe and impossibly high CVSS counts overwhelm teams. EPSS (Exploit Prediction Scoring System) estimates the probability of exploitation in the next 30 days based on observed exploit activity. CISA KEV (Known Exploited Vulnerabilities) catalog is a list of CVEs with confirmed real-world exploitation. Best practice: use KEV as the top-priority filter (any vulnerability on KEV with internet-reachable exposure is critical regardless of CVSS), EPSS for relative prioritization within the rest, and CVSS for severity context. CVSS-only prioritization is what produces 50,000-row remediation backlogs nobody can act on. ### What is "reachability" in vulnerability prioritization? Reachability analysis asks: can an attacker actually reach this vulnerable code path? A CVE-rated 9.8 in a library function never called by your application is theoretically critical but practically irrelevant. Modern vulnerability management tools (Inspector v2 for Lambda, Snyk, GitHub Advanced Security) increasingly do reachability analysis — only flagging vulnerable functions that are actually invoked by your code path. Combined with network reachability (is the vulnerable resource internet-exposed, or only reachable from a single tightly-controlled VPC?), reachability cuts vulnerability backlogs by 70–90% for most organizations. ### What remediation SLA should I use? A common starting framework: Critical (KEV-listed + internet-reachable, or CVSS ≥9.0 with reachable code path) — 7 days. High (CVSS 7.0–8.9, internet-reachable) — 30 days. Medium (CVSS 4.0–6.9 or non-reachable high) — 90 days. Low — best effort, batched. PCI DSS specifically requires high-risk vulnerabilities patched within 30 days for in-scope systems. Document your SLA in your vulnerability management policy; track exception requests with named risk-acceptance owners; and report SLA performance monthly to leadership. Auditors care less about the specific number and more about whether you consistently hit the number you set. ### How do I handle vulnerabilities in third-party container images and base images? Container vulnerabilities are dominated by base image issues — the Alpine, Ubuntu, or Debian image you built on top of. Strategy: (1) Choose minimal, hardened base images (distroless, Chainguard, AWS-published images with active patching), (2) Pin to specific image digests, not floating tags, (3) Re-build images on a schedule (weekly or daily for critical apps) so new patches flow through automatically, (4) Scan during CI (Trivy / ECR scanning / Inspector v2) and block on critical findings, (5) Maintain an SBOM (Software Bill of Materials) for each image — required by US government EO 14028 and increasingly demanded by enterprise customers. Most container vulnerabilities resolve themselves through regular re-builds; the residual work is updating the application's own dependencies. --- *Source: https://www.factualminds.com/blog/aws-vulnerability-management-program-cvss-kev-prioritization/*