Vulnerability Management Best Practices Framework Using Amazon Inspector

Goals and Objectives

This framework aims to establish a balanced and effective vulnerability management approach. The primary objectives are to:

1. Create sustainable governance that balances a zero-vulnerability goal with practical operational considerations
2. Establish risk-based prioritization to focus remediation efforts on vulnerabilities that pose the greatest actual risk, moving beyond a one-size-fits-all approach
3. Implement strategic remediation processes that minimize operational impact while systematically reducing the vulnerability backlog
4. Optimize vulnerability detection by configuring Amazon Inspector settings to reduce finding noise while maintaining comprehensive coverage
5. Enhance visibility and reporting to provide actionable insights for both technical teams and business leadership

Amazon Inspector Overview

Amazon Inspector is an automated vulnerability management service that continually scans AWS workloads for software vulnerabilities and unintended network exposure.

Key Capabilities

• Operating System Vulnerability Assessment: Identifies vulnerabilities in OS packages by comparing against multiple CVE databases
• Programming Language Dependency Analysis: Detects vulnerabilities in application dependencies (Python, Java, JavaScript, etc.)
• Network Reachability Analysis: Identifies potential network paths that could expose vulnerable resources
• Container Image Scanning: Detects vulnerabilities in container images stored in Amazon ECR
• Lambda Function Scanning: Identifies vulnerabilities in Lambda function code and dependencies
• Administration can be controlled from the management account or a delegated administrator account - See: Amazon Inspector integration with AWS Organizations

Integration Points

• AWS Security Hub: Centralizes findings across accounts
• AWS Systems Manager: Enables automated patch/remediation workflows
• Amazon EventBridge: Triggers automated responses to new findings
• Amazon QuickSight: Powers customizable dashboards and reporting

Value Proposition

• Continuous Assessment: Automatically evaluates resources as they change
• Contextual Risk Scoring: Prioritizes vulnerabilities based on exploitability and exposure
• Consolidated View: Provides unified visibility across accounts and resource types
• Automated Remediation: Enables integration with patching workflows

Common Challenges

Organizations typically face these challenges with vulnerability management at scale:

1. Zero-vulnerability goals that treat all severity levels equally across environments
2. Growing vulnerability counts making it difficult for application teams to patch effectively
3. Diverse infrastructure including ephemeral big data clusters, container images, and Lambda functions
4. EMR on EC2 vulnerability multiplication effect — When a single vulnerability exists on an EC2 instance AMI and that AMI is used across multiple nodes in an EMR cluster (e.g., 10 nodes), the same vulnerability is reported 10 times. This multiplication effect artificially inflates vulnerability counts and creates remediation challenges for large clusters.
5. Inconsistent scanning approaches (EC2 agent-based vs. agentless)
6. Limited visibility into vulnerability trends and prioritization

Additionally, each EMR release comes with a list of CVEs that don't impact EMR clusters running on recommended configurations. Example: EMR 7.2.0 CVEs

Amazon Linux prioritizes fixes for security issues based on their severity. The impact of the fix on users, testing requirements, and complexity can also influence the release schedule.

Best Practices Framework

1. Vulnerability Scanning Optimization

EMR/EC2 Instance Scanning

Amazon EC2 scanning extracts metadata from your EC2 instance before comparing it against rules collected from security advisories. Amazon Inspector performs network reachability scans once every 12 hours and package vulnerability scans on a variable cadence depending on the scan method.

EC2 Scanning Methods:

• Agent-based scanning (near real-time): Uses SSM Agent for inspection. Also provides Amazon Inspector Deep Inspection for eligible instances.
• Agentless scanning (24-hour cycle): Provides coverage for instances without SSM Agent installed.

Note: When scanning Linux instances for application programming language package vulnerabilities, the agentless method scans all available paths, whereas agent-based scanning only scans the default paths and additional paths you specify. This may result in the same instance having different findings depending on the scan method.

Deep Inspection:

Amazon Inspector expands EC2 scanning coverage to include deep inspection, detecting package vulnerabilities for application programming language packages in Linux-based EC2 instances. See: Deep Inspection documentation

Recommended Configuration:

For a hybrid scanning approach, implement prioritization as follows:

• Agent-based scanning for critical production systems (near real-time visibility)
• Agentless scanning for ephemeral clusters and lower environments (24-hour cycle)
• Configure instance lifecycle policy to terminate (not just stop) ephemeral instances after use

EMR-Specific Recommendations:

• Implement managed scaling for EMR clusters on task nodes (after thorough testing) to minimize active nodes during low workload periods
• For ephemeral clusters, ensure proper termination rather than stopping to reduce vulnerability count persistence
• Tag all EMR on EC2 instances with consistent metadata to enable filtering and reporting:
  • Identify the top 3 clusters/workflows contributing to the most findings within an AWS account
  • Identify the top 3 vulnerability types across all EMR clusters
  • Implement cluster-aware reporting that de-duplicates identical vulnerabilities across nodes in the same cluster
    • Reporting must include both unique vulnerabilities and total reported vulnerabilities
• More information on visibility and reporting, refer to section Enhanced Visibility and Reporting with Prioritization

ECR Image Scanning

Amazon ECR enhanced scanning integrates with Amazon Inspector to provide vulnerability scanning for container images, covering both operating system and programming language package vulnerabilities.

Recommended Configuration:

• Optimize scan frequency based on image usage:

  • When image re-scan mode is set to "Last pull date," reduce the image pull-date window from 90 days to 30–45 days depending on image usage cycle. This ensures stale or unused images don't inflate vulnerability counts.
  • Consider "last in-use date" mode for more accurate active usage tracking.

• Enforce ECR lifecycle policies to automatically clean up unused images:

  • Prune images older than 60 days
  • Retain only the latest 2–3 versions of each image
  • See: ECR Lifecycle Policies

• Implement repository filtering to focus scanning on critical repositories:

  • Scanning all images in all repositories continuously (using * in scanning configuration) can lead to unnecessary scan noise
  • Apply filters to limit scanning to vital repositories only: Image Scanning Filters

• Leverage ECR-to-container mapping: Amazon Inspector maps ECR images to running containers on EKS and ECS, enabling prioritization based on images currently running in your environment. See the cluster ARN, number of EKS pods or ECS tasks where an image is deployed.

  • Blog: Amazon Inspector enhances container security by mapping ECR images to running containers

Lambda Function Scanning

Lambda scanning has two modes: standard scanning (package vulnerabilities) and code scanning (code vulnerabilities).

Recommended Configuration:

• Tag Lambda functions by criticality to enable prioritized remediation
• Shift-left approach: Code remediation suggestions are powered by automated reasoning.Always review code remediation suggestions before adopting them. You might need to edit them to make sure your code performs as intended. For more information, see the AWS Responsible AI Policy.
  • For code vulnerabilities, Inspector uses internal detectors developed in collaboration with Amazon Q to identify policy violations and vulnerabilities

Note: Deactivating Amazon Inspector Lambda standard scanning will also deactivate Lambda code scanning.

2. Migration to AWS Managed Solutions

• Migrate workloads from EMR on EC2 to EMR Serverless — the Serverless deployment model means infrastructure is managed by AWS: EMR Serverless Vulnerability Configuration
• Conduct thorough testing (performance, functional, integration, cost) before migrating to EMR Serverless, with leadership sign-off based on benchmarking reports.
  • This is a Governance Framework that enables Enterprise to migrate from EMR on EC2 to EMR Serverless: Implementing a Governance Framework for Migrating from Amazon EMR on EC2 to EMR Serverless
• Consider natively available AWS services like OpenSearch Serverless in place of deploying Elasticsearch on EC2

3. AMI Management Strategy

Golden AMI Approach

• Develop application-team-specific Golden AMIs for:
  • Standard EC2 instances
  • EMR clusters with pre-installed big data components
• Enable versioning and rollback capabilities for all Golden AMIs

Custom EMR AMI Considerations

• Document testing procedures for custom AMIs
• Establish regular update cadence aligned with AWS releases
• Balance between security patching and AWS support requirements

4. Shifting Vulnerability Detection Left

Shifting security left means catching vulnerabilities during development — before they reach production scanning. Multiple AWS tools work together across the SDLC to provide defense in depth:

Security Tools Across the SDLC Lifecycle

Security Tools Across the SDLC Lifecycle

	Design	Development	Merge / CI (Deep Analysis)	Merge / CI (Breadth Scanning)	Production
Tool(s)	AWS Security Agent	Kiro IDE	AWS Security Agent	Amazon Inspector Code Security	Amazon Inspector + AWS Security Hub
Capabilities	• Design Security Reviews • Threat Modeling	• Steering • Spec-Driven Development • Skills • Agent Hooks • MCP + Powers	• PR scanning + fix PRs • Full repo code review • Simulated validation • Pen testing	• SCA (dependencies) • SAST (code vulns) • IaC scanning (CFN, Terraform configs)	Inspector: • EC2/EMR scanning • ECR image scanning • Lambda scanning • Network reachability • Continuous assessment • Risk scoring Security Hub: • Compliance framework mapping (CIS, FSBP, NIST, PCI) • Exposure Findings with attack path correlation • Unified security scoring
Outcome	Catch insecure designs before code exists	Prevent vulnerable patterns during coding	Deep reasoning-based analysis — understands architecture, trust boundaries, and data flows to find complex vulnerabilities	Broad coverage — catches known dependency CVEs, code vulnerabilities, and IaC misconfigurations at scale	Detect and prioritize vulnerabilities in live workloads with compliance and exploitability context

← EARLIEST (cheapest to fix) · · · · · · · · · · · · · · · · · · · · · · · · · · · · LATEST (most expensive) →

The cost of fixing a vulnerability increases exponentially as it moves right through the lifecycle. By layering AWS Security Agent (design + merge), Kiro (development), Amazon Inspector Code Security (merge/CI), and Amazon Inspector runtime scanning (production), organizations can catch issues at every stage — with the goal of eliminating as many as possible before they reach production.

Do I need both tools at Merge/CI? Not necessarily — they solve different problems. Amazon Inspector Code Security provides broad, automated coverage: it catches known CVEs in dependencies (e.g., a vulnerable log4j version in a transitive dependency), common code vulnerabilities via SAST, and IaC misconfigurations in CloudFormation or Terraform. Start here for CI/CD baseline coverage. AWS Security Agent adds depth: it reasons about architecture, trust boundaries, and data flows to find complex vulnerabilities that pattern-matching misses — for example, identifying that a custom authentication middleware incorrectly validates JWT tokens, allowing privilege escalation across microservices. Add Security Agent when applications have complex business logic, custom auth flows, or regulatory requirements that demand proof of exploitability.

How Kiro and AWS Security Agent Work Together

Aspect	Kiro (Agentic IDE)	AWS Security Agent
When	Real-time during coding	On-demand or automated (PR, full repo, pentest)
Focus	Prevent vulnerabilities from being introduced	Find, validate, and remediate vulnerabilities that exist
Approach	Guides the developer via Steering rules, Specs, and Hooks	Analyzes full codebase context, architecture, trust boundaries
Output	Inline prevention — secure code generated from the start	Findings with severity, exploitability proof, and fix PRs
Scope	Single file/feature level	Full repository, design documents, live applications

They are complementary: Kiro prevents vulnerable patterns at development time, while AWS Security Agent performs deep reasoning-based analysis to catch what slipped through — then generates validated fixes.

Kiro — Prevention During Development

Kiro is an Agentic IDE that prevents vulnerabilities from being introduced in the first place:

• Agent Steering: Define security standards and conventions for your codebase. Kiro's agent follows these rules during code generation, preventing vulnerable patterns from being introduced.
• Spec-Driven Development: When building new features, Kiro generates requirements, design, and task specs before writing code — security considerations are embedded in the design phase, not bolted on after.
• Skills: Create custom agent capabilities (e.g., a "security scan" skill) that automatically run vulnerability checks as part of the development workflow.
• Agent Hooks: Configure automated triggers that invoke security scanning after agent actions — for example, automatically running dependency checks whenever new packages are added.
• MCP Integration: Connect Kiro to AWS Security Agent via Model Context Protocol to surface findings directly in the IDE without context switching.
• Powers: Install the AWS Security Agent Power to trigger threat modeling, code reviews, and finding remediation inline during development.

AWS Security Agent — Deep Analysis and Remediation

AWS Security Agent is a frontier security agent that proactively secures applications throughout the development lifecycle:

• Design Security Review: Upload architecture documents for analysis against organizational security requirements — catch insecure designs before code is written.
• Threat Modeling: Analyzes source code and design documents to generate STRIDE-classified threats with severity levels and actionable recommendations. Each threat links back to evidence in your source code.
• Code Security Review: Performs deep, reasoning-based analysis on pull requests and full repositories to identify complex vulnerabilities beyond pattern-matching. Generates fix commits and remediation guidance directly in GitHub, GitLab, or Bitbucket.
• Simulated Validation: Validates findings in simulated environments to demonstrate proof of exploitability — reducing false positives.
• On-Demand Penetration Testing: Discovers and validates exploitable vulnerabilities in live web applications through multi-step attack scenarios, then generates code fixes.

Integration with Kiro: The AWS Security Agent Kiro Power and MCP integration allow you to run code reviews, generate threat models, and remediate findings directly from Kiro — results surface inline without context switching.

Resources:

• AWS Security Agent documentation
• AWS Security Agent adds threat modeling, Kiro Power, and MCP integration
• Beyond compute: Shifting vulnerability detection left with Amazon Inspector code security
• AWS re:Invent 2024 - Amazon Inspector & AI remediation for secure SDLC (DOP213)

Note: For a list of Amazon Inspector code scanning supported languages, see the Amazon Inspector User Guide. Amazon Inspector code scanning uses these detectors to scan Lambda functions. Change log here

5. Automated Remediation

Patch Management

Implement automated patching workflows using AWS Systems Manager Patch Manager:

• Integration with Amazon Inspector findings

• Scheduled maintenance windows by environment

• Pre/post-validation checks

• Detailed walkthroughs:

  • Automate vulnerability management and remediation — Part 1
  • Automate vulnerability management and remediation — Part 2

• Patch testing pipeline for critical systems:

  • Test environment validation
  • Functional testing automation
  • Define rollback procedures

Note: AWS doesn't test patches before making them available in Patch Manager. It is applicable only for SSM agent-based instances, not agentless.

EMR-Specific Remediation

• For ephemeral clusters: Ensure latest EMR AMI is used at launch time
• For long-running clusters: Scheduled rotation during low-usage periods

6. Risk-Based Vulnerability Management

Severity Classification

Implement a risk-based approach to prioritize patching. Test in lower environments first, then patch production. Example timeline:

Severity	Production SLA	Non-Production SLA
Critical	14 days	7 days
High	21 days	14 days
Medium	28 days	21 days
Low	40 days	30 days

Auto-Suppression Logic

Implement contextual suppression based on:

• EMR CVEs that do not affect clusters when configured correctly as documented in release notes for each version and for example in EMR 7.12.0 here
• Document all suppression with justification and review date
• Consider suppressing based on criteria like environment, finding criticality, or workload tags

Best practices for suppression rules: Amazon Inspector suppression rules best practices for AWS Organizations

7. Enhanced Visibility and Reporting with Prioritization

Analyze vulnerability data across multiple severities to support your security posture goals. Prioritization is key — understanding criticality, workload sensitivity, and updating patch cycles accordingly.

Findings can be consolidated using:

• Amazon Inspector Console
• AWS Security Hub
• Amazon QuickSight

Integration with Security Standards and Frameworks

Amazon Inspector findings automatically flow into AWS Security Hub, where they can be evaluated against industry-standard compliance frameworks including:

• CIS AWS Foundations Benchmark - Maps infrastructure vulnerabilities to CIS controls (e.g., patching requirements, network exposure rules)
• AWS Foundational Security Best Practices - AWS-curated controls that flag deviations from recommended security posture, including checks that correlate with Inspector findings (e.g., EC2 instances with known vulnerabilities, ECR images with critical findings)
• NIST, PCI DSS, and other frameworks available as Security Hub standards

This integration enables organizations to:

• Correlate vulnerabilities with compliance posture — A critical CVE on a PCI-scoped workload carries different remediation urgency than one on a dev sandbox
• Unified compliance scoring — Security Hub's security score aggregates Inspector findings alongside other control failures, giving leadership a single compliance metric
• Automated control mapping — Inspector findings automatically map to relevant controls within enabled standards, eliminating manual cross-referencing

For organizations with regulatory requirements (financial services, healthcare), this mapping provides auditable evidence that vulnerability management processes align with mandated frameworks without maintaining separate tracking.

Exposure Findings in AWS Security Hub — Prioritization Through Correlation

Beyond raw vulnerability counts, Security Hub Exposure Findings automatically correlate signals from Amazon Inspector, GuardDuty, Macie, and Security Hub CSPM to identify compound security risks — where individually low-risk issues combine to create exploitable attack paths. This enables proper prioritization by surfacing the vulnerabilities that actually matter based on real-world exploitability.

Key capabilities for prioritization:

• Automated correlation: Combines vulnerability data, network reachability, IAM permissions, and threat detection signals into a single contextualized finding — eliminating the need to manually cross-reference multiple consoles
• Attack path visualization: Interactive diagrams showing how an attacker could move from an exposed resource through to sensitive data — helping teams prioritize based on actual exploitability, not just CVSS scores
• Contextual traits (blast radius): Shows unused IAM permissions on vulnerable resources — a vulnerable EC2 instance with an over-privileged role has higher blast radius than one with least-privilege. IAM Access Analyzer unused access data appears as contextual traits for EC2, Lambda, ECS, EKS, and IAM users.
• Severity classification: Based on ease of discovery, ease of exploit, likelihood of exploit, public awareness, and potential impact — not just the CVE score alone

Why this matters for EMR/EC2 environments: A single CVE on an EMR node may or may not be exploitable depending on network exposure, security group configuration, and IAM roles attached. Exposure findings surface the real risk rather than inflated raw counts from vulnerability multiplication. This directly supports proper prioritization — patch the exploitable vulnerabilities first, not necessarily the highest CVSS score.

See: Exposure findings in Security Hub

Recommended Dashboard Hierarchy

Build a consolidated dashboard with drill-down capability:

1. Vulnerability count per AWS Organization
2. Per AWS account → per Business Unit → per SDLC stage (Prod, Pre-Prod, Test, Dev) → per workload → per compute type (EC2, EMR, Lambda, ECR)
3. Filter by Inspector score or rating (Critical, High, Medium, Low, Informational)
4. Under EC2, identify scan type (agent-based vs. agentless) using the ListCoverage API
5. For EMR workloads, distinguish unique vulnerabilities per workload/cluster (deduplication)

Additional Dashboard Elements

• Age of vulnerabilities
• Remediation progress tracking
• Daily refresh cadence

Software Bill of Materials (SBOM)

Beyond vulnerability counts, understand which CVEs, operating systems, and packages are most affected across workloads using SBOM — a nested inventory listing the ingredients that make up software components.

• Amazon Inspector SBOM Export Capability
• SBOM Generator documentation

Executive Metrics and KPIs

• Mean Time to Remediate (MTTR) by severity
• Vulnerability density (findings per resource)
• Patch compliance percentage
• Risk reduction trend over time

Prioritization guidance: Resources in public subnets should be prioritized over those in private subnets. Resources with more open internet access have increased scope for DoS, DDoS, spoofing, malware, and ransomware.

Note on finding closure: When a resource is deleted, terminated, or no longer eligible for scanning, Amazon Inspector automatically closes findings and deletes them after 3 days. Findings closed for other reasons are deleted after 30 days. Amazon Inspector will reopen a remediated finding within 7 days if the vulnerability reoccurs.

8. Governance and Compliance

Policy Framework

• Clear SLAs for remediation by severity and SDLC environment
• Exception process with appropriate approvals
• Regular review cycles for suppressed vulnerabilities
• Compliance mapping to regulatory requirements

Roles and Responsibilities

Role	Responsibility
Central Vulnerability Management	Platform configuration, reporting, governance
Security Team	Risk assessment, exception approval
Application Teams	Remediation execution, testing

Conclusion

This framework provides a balanced approach to vulnerability management that respects a zero-vulnerability goal while implementing practical measures to make remediation manageable for application teams. By optimizing scanning configurations, implementing risk-based prioritization, enhancing automation, and shifting security left in the development lifecycle, organizations can significantly reduce the operational burden while maintaining a strong security posture.

Appendix

• Amazon Linux Security General FAQs
• Amazon Linux 2023 FAQs
• Amazon Inspector FAQs