Asterrr's Handbook
3 · Infrastructure security

Vulnerability and patch management

Amazon Inspector for EC2, ECR, Lambda and code repositories, GuardDuty Runtime Monitoring, Systems Manager Patch Manager and State Manager, and security scanning inside CI/CD pipelines with Amazon Q Developer and Inspector.

Exam tasks: 3.2 (scan compute for known vulnerabilities with Inspector and GuardDuty; deploy patches with Patch Manager and validate continuously; discover and remediate vulnerabilities in a pipeline)

The decision: where do you find the vulnerability first (in code, in the image, or in the running resource), and what closes the loop automatically so a finding becomes a patch or a blocked deployment?

The vulnerability lifecycle

The earlier a flaw is caught, the cheaper it is to fix. The exam still expects controls at every stage, because new CVEs appear for software that passed every earlier check.

Amazon Inspector

  • Turn it on for the whole organization from a delegated administrator account, with auto-enable for new accounts. It discovers resources itself: there are no assessment templates or schedules to set up.
  • Findings go to the Inspector console, EventBridge and Security Hub CSPM. Each has an Inspector score, the CVSS base score adjusted for your environment (for example, lowered when no network path exists).
  • Suppression rules hide accepted findings. SBOM export produces CycloneDX or SPDX inventories for audits.
  • A fixed finding closes automatically on the next scan.
ResourceHow it's scannedFindsRescans when
EC2, agent-basedSSM Agent and Inspector associations. Instance must be SSM managedOS packages, plus language packages with deep inspection (Linux)New package installed, new CVE published, inventory changes
EC2, agentlessEBS snapshots read through EBS direct APIs, used in hybrid mode for instances that aren't SSM managedOS and language packagesAbout every 24 hours
EC2 network reachabilityConfiguration analysis, no agentPorts reachable from outside the VPCAbout every 12 hours
ECR (enhanced scanning)Image layers, on push and continuouslyOS and language packagesNew CVE, for the rescan duration you set
Lambda standardFunction and layer dependenciesVulnerable packagesDeploy, update, new CVE
Lambda code scanningYour function codeInjection, data leaks, weak crypto, hard-coded secretsDeploy, update
Code securityGitHub and GitLab repositoriesSAST, SCA and IaC issuesPush, pull request or schedule
  • CIS benchmark assessments check OS configuration of managed EC2 instances against CIS, on demand or on a schedule.
  • Exclude a resource with the InspectorEc2Exclusion tag (EC2) or tags on Lambda functions. Lambda functions encrypted with a customer managed key aren't scanned.
  • ECR basic scanning (AWS native, OS packages only, on push or manual) remains the free option. Enhanced is Inspector.

Exam signal

"Find vulnerabilities on EC2 instances that don't have the SSM Agent" means Inspector hybrid scan mode (agentless, from EBS snapshots). "Detect vulnerable Java libraries, not just OS packages" means enhanced ECR scanning or EC2 deep inspection. "Find hard-coded credentials in Lambda code" means Inspector Lambda code scanning.

Legacy: use Amazon Inspector (v2) instead

Older material describes assessment templates, assessment targets, rules packages and a separate Inspector agent. That's Inspector Classic, which reached end of support on May 20, 2026. Current Inspector is always on, uses the SSM Agent or snapshots, and has no templates. An answer that says "create an assessment template and schedule it weekly" is outdated.

GuardDuty Runtime Monitoring

Inspector finds known flaws before exploitation. GuardDuty Runtime Monitoring watches behaviour during execution: a managed agent (EKS add-on, Fargate sidecar for ECS, or SSM-deployed agent on EC2) reports process, file and network events, and GuardDuty raises findings such as reverse shells, crypto miners or container escapes. Details are in Threat detection.

Patch Manager

  • Patch baselines decide which patches are approved:
    • Predefined AWS baselines per OS (for example critical and important security updates approved 7 days after release for Amazon Linux).
    • Custom baselines with auto-approval rules (classification, severity, days after release), explicit approved and rejected lists, and a compliance level reported for missing patches.
    • Reject a patch that broke an app, and choose whether its dependants are blocked too.
  • Patch policies (through Quick Setup) are the recommended setup. One policy can cover every account and Region in the organization (or chosen OUs), with separate scan and install schedules and a baseline per OS.
  • Patch groups (the PatchGroup tag mapped to a baseline) and maintenance windows are the older way. They still work where they were already set up, and you'll still see them in questions.
  • Under the hood, everything runs the AWS-RunPatchBaseline document with Scan (report only) or Install, with reboot options.
  • Patch now patches on demand, in one account and Region at a time.
  • Compliance data goes to Systems Manager Compliance. Aggregate it with resource data sync to S3 and query with Athena, or use the AWS Config rule for managed instance patch compliance.

Exam signal

"Patch every instance in all accounts of the organization weekly, scan daily, with the least setup" means a Quick Setup patch policy. "Only approve security patches after 14 days of testing" means a custom baseline with an auto-approval delay. "A specific KB broke the app" means add it to the rejected patches list.

State Manager

  • An association binds an SSM document, targets (tags, resource groups, all managed nodes) and a schedule, and keeps nodes in that state: re-installs a missing agent, re-applies a hardening script, removes a banned key.
  • It reports association compliance, so drift shows up as non-compliant nodes.
  • Patch policies themselves are State Manager associations underneath.

Continuous validation

  1. Patch policy installs patches in the maintenance period.
  2. Inspector detects the new package versions and closes the related findings.
  3. Findings still open after the SLA (for example critical older than 15 days) trigger an EventBridge rule that opens an OpsCenter item or a ticket.
  4. Security Hub CSPM and Config rules show compliance across accounts.

Scanning in the pipeline

StageToolWhat it does
Developer IDEAmazon Q Developer code reviewsSAST, secrets detection, IaC issues and SCA on a file, the diff or the whole project, with suggested fixes
RepositoryInspector code securityScans GitHub and GitLab repos on push, pull request or schedule for SAST, SCA and IaC issues
BuildInspector CI/CD scanningThe Inspector SBOM generator inventories the built artifact or image, and the ScanSbom API returns CVEs. Plugins exist for Jenkins, TeamCity and others, or call it from CodeBuild
RegistryECR enhanced scanningScan on push, and EventBridge events to block promotion
Deploy gateYour pipeline logicFail the CodePipeline stage if any finding is critical or high

Legacy: use Amazon Q Developer code reviews and Amazon Inspector code security instead

Amazon CodeGuru Security reached end of support on November 20, 2025. Its console, APIs and historical findings are no longer available. Questions that name it are testing the idea of pipeline SAST: map it to Q Developer or Inspector code security. The Q Developer IDE plugins themselves are due to reach end of support in April 2027, with Kiro as the successor, but the security review capability is what the exam cares about.

12 h
Inspector network reachability scan interval for EC2.
24 h
Inspector agentless (snapshot) scan interval in hybrid mode.
90 days
Lambda functions not invoked or updated in this long drop out of Inspector scanning.
Scan / Install
The two operations of AWS-RunPatchBaseline.

Scenarios

Scenario
A retailer has 1,200 EC2 instances across 45 accounts. About 300 instances come from a vendor AMI where the SSM Agent can't be installed. The security team needs vulnerability findings for all instances, aggregated in one account, with the least operational effort. What should the team do?
Scenario
A SaaS company builds container images in CodePipeline and pushes them to ECR. A recent incident involved an image with a critical OpenSSL CVE that reached production. The company wants to stop images with critical findings from being deployed and to be alerted when a CVE is later published for an image already running. Which approach meets both requirements?
Scenario
An insurance company patches Windows servers in 12 accounts with maintenance windows set up separately in each account. Audit found that some accounts skipped patching for two months. The company wants one configuration that scans daily, installs patches every Sunday, applies to new accounts automatically, and approves only critical and security updates after a 5-day delay. What should the engineer do?

Further reading

Compute hardening

Golden AMIs with EC2 Image Builder, hardened container images, IMDSv2, instance profiles vs service and execution roles, Session Manager, EC2 Instance Connect and its endpoint, removing SSH keys, and host-based controls.

Generative AI guardrails

Amazon Bedrock Guardrails policies, the OWASP Top 10 for LLM Applications mapped to AWS controls, least privilege for agents, preventing data leakage, and logging model invocations.

On this page

The vulnerability lifecycleAmazon InspectorGuardDuty Runtime MonitoringPatch ManagerState ManagerContinuous validationScanning in the pipelineScenariosFurther reading