6.2 Amazon Inspector Vulnerability Management & Patch Automation

6.2 Amazon Inspector Vulnerability Management & Patch Automation

Traditional vulnerability management relied on periodic network port scans and manual agent-based assessment windows scheduled during off-peak hours. In dynamic cloud environments—where auto-scaling instances launch and terminate in minutes, container images are continuously deployed, and serverless functions run ephemerally—periodic scanning creates dangerous blind spots. A vulnerability introduced minutes after a weekly scan window remains invisible to security operations for days.

Amazon Inspector delivers continuous, automated, and context-aware vulnerability management across compute workloads. Integrated natively with AWS Systems Manager Patch Manager, Amazon EventBridge, and developer tooling like Amazon Inspector code security (the successor to Amazon CodeGuru Security) and Amazon Q Developer, security teams can establish end-to-end vulnerability discovery, risk prioritization, and automated remediation.

---

Evolution of Vulnerability Management: Inspector Classic vs Inspector v2

The SCS-C03 exam focuses heavily on the modern architecture of Amazon Inspector (often referred to as Inspector v2). Understanding the shift from legacy Inspector Classic to Inspector v2 is essential for selecting correct architectural solutions:

Loading diagram...

---

Amazon Inspector Continuous Scanning Across Compute Targets

Inspector v2 continuously inventories and scans three distinct compute tiers:

1. Amazon EC2 Scanning (Agent-Based & Agentless Hybrid)

Inspector scans EC2 instances for software vulnerabilities (Common Vulnerabilities and Exposures - CVEs) and unintended network exposure:

• Agent-Based Scanning (SSM Agent): For instances managed by AWS Systems Manager, Inspector continuously collects an inventory of installed application and operating system packages via the SSM Agent. No scanning binaries execute on the target host; inventory telemetry is processed out-of-band by Inspector against continuously updated CVE databases.
• Agentless Scanning (EBS Snapshot Analysis): For EC2 instances that lack the SSM Agent, have outdated agents, or reside in restricted network segments without SSM connectivity, Inspector provides Agentless Scanning. Inspector takes an ephemeral, point-in-time EBS snapshot of the root volume, mounts it to an isolated scanning environment managed by AWS, inspects installed packages, and immediately deletes the snapshot. Organizations can enable Hybrid Mode, which prioritizes SSM Agent-based scanning where available and automatically falls back to agentless snapshot scanning for unmanaged nodes.
• Network Reachability Analysis: Inspector evaluates whether an EC2 instance is reachable from the public internet by analyzing VPC route tables, Internet Gateways (IGWs), Elastic IP addresses, Security Groups, and Network Access Control Lists (NACLs) using technology derived from the VPC Reachability Analyzer.

2. Amazon ECR Container Image Scanning

When Enhanced Scanning is enabled in ECR, Inspector scans container images stored in private repositories:

• Continuous Rescanning: Unlike basic scan-on-push, Inspector continuously rescans images whenever new vulnerabilities are published in CVE databases. If an image was pushed 6 months ago and a zero-day vulnerability is announced today, Inspector identifies the vulnerability without requiring the image to be rebuilt or re-pushed.
• Scanning Duration Rules: Organizations can configure scan duration settings to optimize costs:
  • You choose how long Inspector keeps rescanning an image after it is pushed or last pulled, from a short window (for example, 14 or 30 days) up to the image's lifetime, so dormant images stop generating findings.
• Language Dependency Scanning: In addition to Linux OS packages (Alpine, Debian, RPM), Inspector scans programming language packages, including Python (pip), Node.js (npm), Java (maven), Go, and Ruby (gem).

3. AWS Lambda Function & Layer Scanning

Inspector automatically discovers and assesses all AWS Lambda functions and associated Lambda Layers within an account:

• Lambda Standard Scanning: Analyzes application package dependencies included directly in the Lambda deployment package or imported via Lambda Layers (e.g., outdated Python requests or Java log4j libraries).
• Lambda Code Scanning: Performs static application security testing (SAST) on custom application code written inside the Lambda function. It identifies code-level security flaws including hardcoded AWS credentials, SQL injection, cross-site scripting (XSS), path traversal, and insecure deserialization.

---

Inspector Score vs Base CVSS Scoring

A critical conceptual area on the AWS Certified Security – Specialty exam is the fundamental distinction between a Base CVSS Score and the Inspector score.

The Failure of Raw CVSS in Production Prioritization

The Common Vulnerability Scoring System (CVSS) calculates a static mathematical score (ranging from 0.0 to 10.0) based on the intrinsic technical characteristics of a vulnerability (Attack Vector, Attack Complexity, Privileges Required, Scope, Confidentiality/Integrity/Availability Impact). However, CVSS evaluates vulnerabilities in a complete operational vacuum:

• A vulnerability with CVSS 9.8 (Critical) present on an EC2 instance located in an isolated, private subnet with zero internet routing, no inbound ports, and no available public exploit code represents a low real-world operational risk.
• Conversely, a vulnerability with CVSS 6.5 (Medium) on an internet-facing web server possessing active, weaponized exploit code in the wild (e.g., listed in CISA's Known Exploited Vulnerabilities catalog) represents an imminent, catastrophic operational threat.

How the Inspector Score Is Calculated

To eliminate alert fatigue and ensure security teams remediate actual attack vectors first, Amazon Inspector calculates an Inspector score for EC2 findings: a CVSS-style 0–10 value that re-scores the base metrics using your environment, mapped to Low, Medium, High, and Critical severity.

Loading diagram...

The calculation synthesizes three core inputs:

1. Base CVSS Score: The foundational severity baseline provided by the National Vulnerability Database (NVD).
2. Exploit Availability & Threat Intelligence: Inspector ingests real-time threat intelligence feeds, including the CISA Known Exploited Vulnerabilities (KEV) catalog, Exploit-DB, and internal AWS Security Intelligence. If active, weaponized exploit code exists, the risk score is drastically elevated.
3. Network Path Exposure: Inspector queries VPC routing topology. If an instance has an open security group port and a route to an Internet Gateway, the score increases. If the instance is strictly private with no path from the internet, the score is adjusted downward.

Exam Tip: When an exam question asks how to prioritize remediation across thousands of EC2 and container findings without exhausting engineering bandwidth, the correct answer is to sort by the Inspector score and its vulnerability intelligence (known exploitation), not the raw CVSS score. The Inspector score accounts for actual network reachability and exploitability.

---

AWS Systems Manager Patch Manager & Automated Remediation

Discovering vulnerabilities is futile without automated remediation. AWS Systems Manager Patch Manager automates the patching of operating systems and application packages across EC2 instances and on-premises virtual machines at enterprise scale.

1. Patch Baselines

A Patch Baseline defines which patches are approved for installation across target instances:

• Default Baselines: AWS provides predefined patch baselines for each supported operating system (e.g., AWS-AmazonLinux2DefaultPatchBaseline, AWS-UbuntuDefaultPatchBaseline). Default baselines automatically approve all security-related operating system patches classified as Critical or Important after an auto-approval delay.
• Custom Patch Baselines: Organizations create custom baselines to define precise enterprise compliance criteria:
  • Auto-Approval Rules: Specify patch approval conditions based on Product (e.g., Amazon Linux 2023), Classification (e.g., Security, Bugfix), and Severity (e.g., Critical, Important, Medium).
  • Auto-Approval Delay (Days): A mandatory waiting period (e.g., 7 days) before newly released vendor patches are approved. This "soak period" prevents zero-day patch regressions and faulty vendor updates from corrupting production fleets.
  • Compliance Severity Level: Assigns a compliance status (e.g., CRITICAL, HIGH) if an approved patch is missing from an instance during compliance audits.
  • Explicit Approval & Rejection Lists: Allows whitelisting specific mandatory patches or blacklisting specific broken package versions (e.g., rejecting a kernel version that conflicts with proprietary drivers).

2. Patch Groups

To prevent applying identical patching schedules across development and production environments, Patch Manager utilizes Patch Groups:

• A Patch Group is established by tagging target managed nodes with the key Patch Group or PatchGroup (case-sensitive; use PatchGroup when instance metadata tags are enabled) and a designated string value (e.g., Key=Patch Group, Value=Production-Tier1 or Key=Patch Group, Value=Development).
• A custom Patch Baseline is then registered to that specific Patch Group string.
• AWS now recommends patch policies (Quick Setup) for patching across accounts and Regions; patch groups remain supported and are still tested.
• When a patching task executes, Patch Manager evaluates the node's Patch Group tag and applies exclusively the baseline registered to that group.

3. Maintenance Windows

A Maintenance Window defines an authorized operational window for executing disruptive actions (patch installation, rebooting) across instances:

• Schedule: Defined via a CRON or Rate expression (e.g., cron(0 2 ? * SUN *) for Sundays at 02:00 UTC).
• Duration & Cutoff: Specifies total window runtime (e.g., 4 hours) and a Cutoff (e.g., 1 hour before window close). Patch Manager will not initiate new tasks once the cutoff is reached, ensuring tasks do not bleed into business operating hours.
• Registered Targets: Specifies target instances by Resource Tags (e.g., Environment=Production), Resource Groups, or explicit Node IDs.
• Registered Tasks: Executes the SSM document AWS-RunPatchBaseline with parameters:
  • Operation: Scan: Evaluates patch compliance without modifying installed packages, emitting compliance telemetry to Systems Manager Compliance.
  • Operation: Install: Downloads approved missing patches, applies updates, and reboots the instance if required (RebootOption: RebootIfNeeded or NoReboot).

Loading diagram...

---

Shift-Left Code Security: Inspector Code Security, CodeGuru Security & Amazon Q Developer

While Inspector and Patch Manager secure deployed runtime infrastructure, resolving vulnerabilities in production is orders of magnitude more expensive than preventing them during development. Modern AWS security architectures "shift left" by embedding static application security testing (SAST) directly into developer IDEs and continuous integration/continuous delivery (CI/CD) pipelines.

From CodeGuru Security to Amazon Inspector Code Security

The exam guide names Amazon CodeGuru Security, a static application security testing (SAST) service for source code. AWS discontinued CodeGuru Security on November 20, 2025. Its role now belongs to Amazon Inspector code security (generally available since June 2025), which connects to GitHub or GitLab repositories and runs SAST, software composition analysis of dependencies, and infrastructure-as-code scans. The capabilities to know are the same:

• Pipeline Integration: Scans on push, on pull or merge requests, and on a schedule for connected repositories, so findings appear before code merges.
• Vulnerability Coverage: Detects the OWASP Top 10 web application risks, including SQL injection, Command Injection, Cross-Site Scripting (XSS), Path Traversal, and Server-Side Request Forgery (SSRF).
• Credential Leakage Prevention: Identifies plaintext AWS access keys, database connection strings, API tokens, and private cryptographic keys embedded in source code.
• Remediation Guidance: Findings include recommended fixes that developers can apply before merging.

Amazon Q Developer (Security Scanning)

Amazon Q Developer extends security analysis into the software engineer's IDE (Visual Studio Code, JetBrains IntelliJ) and the AWS Management Console:

• Inline Code Review: Analyzes code in real time as developers write, flagging insecure library dependencies, vulnerable API calls, and logic flaws prior to repository commit.
• Autonomous Code Transformation: Automatically upgrades legacy application runtimes (e.g., upgrading Java 8/11 applications to Java 17/21) while refactoring deprecated security APIs and unpatched framework dependencies.

---

Specialty Exam Pitfalls & Operational Traps

1. The Inspector Agentless Scanning Misconception: Candidates often assume Inspector v2 requires the SSM Agent under all circumstances. While the SSM Agent provides deeper, near-instantaneous package telemetry, Inspector v2 supports Agentless Scanning for EC2 via EBS snapshot copies. An unmanaged instance without an SSM agent is still scanned if agentless mode is enabled.
2. Patch Baseline Auto-Approval Delay Pitfall: In regulated environments, approving patches with an auto-approval delay of 0 days can cause widespread outages if a vendor releases a flawed patch. Standard exam-tested practice mandates configuring an auto-approval delay (typically 5 to 10 days) to allow upstream vendor validation, combined with an explicit approved patch list for emergency zero-day hotfixes.
3. Patch Group Tag Naming Requirements: The tag key must be exactly Patch Group or PatchGroup (case-sensitive). Variants such as patch-group or Patch-Group do not match, so the instance falls back to the default patch baseline for its operating system.
4. Lambda Standard vs Lambda Code Scanning: Standard Lambda scanning inspects third-party package dependencies bundled in the deployment zip or imported via Lambda Layers. However, standard scanning does not inspect custom developer-written application logic. To detect SQL injection, hardcoded secrets, or insecure input handling inside the Lambda function handler itself, you must enable Amazon Inspector Lambda Code Scanning.