Amazon SCS-C02: Vulnerability, Patch & Host Security — Study Guide
Part of the AWS Security Specialty SCS-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Amazon Inspector: Enhanced Scanning Across EC2, Lambda, and ECR
Amazon Inspector is a continuous, agent-supported vulnerability management service that discovers CVEs in EC2 instances, container images stored in ECR, and Lambda functions (both application code and dependency layers). Enabling Inspector at the account level automatically enrolls eligible resources — there is no per-resource opt-in workflow — and findings are automatically pushed to AWS Security Hub in the standardized ASFF format, which is the correct integration pattern when a central security posture dashboard is required.
For EC2, Inspector uses a hybrid scanning model. The SSM Agent (with the AWS-provided association) collects a software inventory used for agentless-style network reachability and package assessment, while deep host assessment requires the agent to be running and the instance to be reachable via SSM. This is why the “agentless only” approach is a trap: without the SSM Agent path (or Inspector’s agent-based deep inspection where required), you get shallow findings — network exposure and manifest-derived CVEs — but miss runtime library inventories, unmanaged packages, and configurations. Hybrid mode is what most production estates need.
For Lambda, Inspector performs two scan types: standard (package vulnerabilities in layers and function dependencies) and code scanning (static analysis of function code for injection flaws, hardcoded secrets, and insecure APIs). A critical eligibility rule: a Lambda function must have been invoked at least once within the last 90 days to be scanned. Idle or archived functions silently drop out of Inspector’s scope. Teams that assume “Inspector is enabled, therefore every function is covered” get burned when auditors ask for evidence on rarely-executed functions. Remediation is to either invoke functions on a schedule (EventBridge) or accept the exclusion and document it.
For ECR, enhanced scanning (powered by Inspector) replaces the older basic scanning based on Clair. Enhanced scanning supports both scan on push and continuous scanning of images already in the registry, so newly disclosed CVEs against previously pushed images generate fresh findings without a re-push. Enable enhanced scanning at the registry level and configure per-repository filters (for example, prod/* continuous, sandbox/* scan-on-push only) to control cost.
Delegated Administration and Suppression
In a multi-account AWS Organizations setup, designate a delegated administrator account for Inspector from the management account. The delegated admin sees aggregated findings across member accounts and controls organization-wide scan configuration. This avoids granting cross-account IAM roles for finding retrieval and prevents the anti-pattern of enabling Inspector piecemeal per account.
Suppression rules allow a security team to filter noise without deleting findings. A rule matches on attributes such as resource tag, severity, CVE ID, or ECR repository. To keep dev/test Lambda findings off the production dashboard, apply a suppression rule keyed on the tag Environment=dev — the findings still exist in the underlying data store for audit, but they are excluded from the default views and from Security Hub if configured. Do not achieve this by disabling Inspector for dev accounts; you lose the ability to catch a dev-to-prod promotion of a vulnerable artifact.
CI/CD Gating for Image Promotion
Enhanced ECR scanning generates findings tied to an image digest (not just the tag), which is what a pipeline must query. The canonical pattern is: build image → push to ECR (triggers scan on push) → poll or wait for scan completion → fail build if High or Critical findings exist → otherwise update the ECS/EKS task/deployment.
A minimal CodeBuild step in buildspec.yml:
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
Failing to gate at this stage — trusting that “Inspector will alert us” — is the classic mistake: alerts arrive asynchronously and after the vulnerable image is already running. The gate must be synchronous with promotion. Similarly, gating only on the tag rather than the digest is unsafe because tags are mutable; two pushes with the same tag will conflate scan results.
Patch Manager, Baselines, and Patch Groups
SSM Patch Manager operates on three primitives:
Patch baseline: defines auto-approval rules, approved patches, rejected patches, and compliance level per severity/classification.
Patch group: a tag with key exactly
Patch Groupwhose value registers instances to a specific baseline.Maintenance window: the schedule during which
AWS-RunPatchBaselineexecutes Scan or Install tasks.
For an environment that requires Dev to auto-approve all security patches immediately, and Prod to auto-approve only Critical/Important after a 7-day soak while rejecting kernel packages, you create two baselines. The Dev baseline uses an approval rule with ApproveAfterDays: 0 covering all security classifications. The Prod baseline uses ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filters Classification=Security and Severity in [Critical, Important], and adds kernel* to the rejected patches list with BlockAllPatchesFromRejectedList. Instances are tagged Patch Group=Dev or Patch Group=Prod, and each patch group is registered to the corresponding baseline. Compliance rolls up via Patch Compliance reports and can be exported to S3 for central audit.
A single baseline “with logic” cannot express Dev-vs-Prod differences — baselines are static per registered group. Do not try to use different Maintenance Windows to fake this behavior; the window controls when patching runs, not which patches are approved.
Real-Time Notification Pipeline
For Slack or Microsoft Teams alerting on new findings, the operationally efficient chain is:
Inspector emits findings to EventBridge on the
aws.inspector2event source.EventBridge rule filters by severity (e.g.,
HIGH,CRITICAL) and targets an SNS topic.SNS topic has an AWS Chatbot subscription mapped to the Slack channel or Teams workspace.
Chatbot subscribes directly to SNS — do not put a Lambda in between to reformat messages, since Chatbot natively renders Inspector findings. An example EventBridge pattern:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Two traps to avoid here: routing via Security Hub adds latency and can drop severity granularity if custom insights are misconfigured; and using SES or a custom webhook Lambda increases operational overhead without adding capability that Chatbot already provides natively.
Practical Problem: Use-Case Scenario
Scenario: Meridian Financial runs a multi-account AWS organization supporting customer-facing web services, batch analytics, and serverless event processors. Their CI/CD pipelines push container images to Amazon ECR, they host EC2 fleets for legacy workloads, and use Lambda for newer services; a central security team in a security account must manage vulnerability visibility and patching across accounts.
Challenge: A recent image containing a high-severity library was promoted to production because scans were not enforced in CI/CD, and patching of EC2 instances is inconsistent across environments, leaving exposure windows and noisy findings that overwhelm the team.
Recommended Approach:
- Enable Amazon Inspector Enhanced Scanning across EC2, Lambda, and ECR from the security account by configuring delegated administration in AWS Organizations so scans, findings, and suppression rules can be managed centrally.
- Configure ECR image scanning on push and integrate scan gates into CodePipeline/CodeBuild: block image promotion until Inspector/ECR scan results meet severity thresholds and surface findings via the build step.
- Implement AWS Systems Manager Patch Manager with defined patch baselines and patch groups per environment, schedule Maintenance Windows for non-production-first rollout, and automate approval for critical CVE fixes using SSM Automation documents.
- Create a real-time notification pipeline using Amazon EventBridge to capture Inspector findings and SSM compliance events, route them to Amazon SNS and a lightweight AWS Lambda that enriches, deduplicates, and posts prioritized alerts to Slack and creates tracking tickets.
- Automate containment and remediation: use EventBridge-triggered SSM Automation or Lambda runbooks to isolate impacted EC2/Lambda versions or trigger image rebuilds, and apply Inspector suppression only for tracked false positives via the delegated admin account to reduce noise.
Rationale: Centralized Inspector management, CI/CD gating, Patch Manager baselines, and an EventBridge-driven pipeline follow AWS best practices by enforcing automated prevention, consistent patching, and prioritized, auditable response while reducing alert fatigue.
Vulnerability Discovery with Amazon Inspector
Amazon Inspector is the primary managed vulnerability assessment service on AWS, and it operates across three surfaces relevant to host security: EC2 instances, container images in Amazon ECR, and Lambda functions. When enabled at the account or Organizations level (via delegated administrator in the Inspector console), it performs continuous, agentless-or-SSM-based scanning rather than scheduled point-in-time scans. This continuous posture is important because CVE feeds change daily; a snapshot from last week may already be stale.
For EC2, Inspector relies on the SSM Agent to enumerate installed packages and kernel versions, then correlates them against vendor advisories and the National Vulnerability Database. Findings include CVE identifier, CVSS score, affected package, fixed version, and network reachability context (the network-reachability rules identify ports exposed to the internet via ENIs, security groups, NACLs, and route tables). Because scanning depends on SSM, an EC2 instance that lacks the AmazonSSMManagedInstanceCore managed policy on its instance profile will simply not appear in Inspector results — a silent failure worth remembering.
For ECR, Inspector supports two scan modes:
Basic scanning: free, uses the open-source Clair engine, runs on push or on demand only.
Enhanced scanning: Inspector-powered, continuously rescans images (both OS packages and application language packages such as Python, Node, Java) as new CVEs are published, even long after the push event.
A common trap is treating ECR scan-on-push as sufficient host security. It is not. Scan-on-push validates the image at build time, but the running container inherits the image plus any drift, and the underlying EC2 or Fargate host has its own kernel and OS packages that must be patched independently. Enhanced scanning combined with EC2 host scanning closes that gap. All Inspector findings should be routed into AWS Security Hub, which normalizes them into the ASFF format and enables cross-account aggregation, deduplication, and downstream automation via EventBridge.
Patch Manager and Fleet-wide Remediation
AWS Systems Manager Patch Manager complements Inspector by actually remediating what Inspector discovers. Whereas Inspector answers “which CVEs affect me?”, Patch Manager answers “which patches are missing, and how do I install them safely?”
Patch Manager operates through patch baselines — declarative rules that define which patches are approved, based on classification (Security, Critical, Bugfix), severity, and an auto-approval delay (for example, approve Security patches seven days after release to allow vendor stability). AWS provides default baselines per OS (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline, etc.), but production fleets typically use custom baselines tied to patch groups via the Patch Group tag on instances.
A typical scanning and patching workflow uses two operations:
Scan: reports compliance without installing anything; results appear on the Patch Manager compliance dashboard and in Config.
Install: applies approved patches and, for many OSes, reboots.
These operations are typically scheduled through maintenance windows with an AWS-RunPatchBaseline document target. For urgent zero-day scenarios, Patch Manager offers Patch Now, an on-demand action that bypasses the maintenance window schedule. The recommended pattern is to create a narrow patch baseline that approves only the specific KB or package fixing the vulnerability, target the affected patch group, run Patch Now, and stream execution output to a central S3 bucket and CloudWatch Logs group. That centralized log becomes your audit artifact — proof of remediation for auditors or incident response.
### Practical Problem: Use-Case Scenario
**Scenario:** Meridian Financial operates a multi-account AWS environment with several hundred EC2 instances (Windows and Amazon Linux) and a small EKS cluster supporting customer-facing services. They use AWS Organizations, AWS Systems Manager for operational tooling, and maintain AMIs in a shared image account, but do not have consistent automated vulnerability scanning or coordinated patch rollouts across accounts.
**Challenge:** A public CVE affecting OpenSSL is published and Amazon Inspector reports elevated findings across multiple instances, but patching has been uneven and one production service experienced a brief exploitation attempt due to delayed remediation.
**Recommended Approach:**
1. Enable Amazon Inspector across all accounts and regions to perform both image and running-instance vulnerability scans, and forward high-severity findings to AWS Security Hub and an EventBridge custom event bus.
2. Use AWS Systems Manager Inventory to identify impacted instances and tag them by criticality; create a Patch Manager baseline that includes the required OpenSSL fixes and target Windows/Linux rules.
3. Create an EventBridge rule that triggers an SSM Automation document when Inspector findings reach a defined severity, passing the list of instance IDs to an Automation runbook that invokes Patch Manager or Run Command to apply patches and reboot where needed.
4. For stateful or high-risk services, orchestrate rolling updates using EC2 Image Builder to bake patched AMIs, update Auto Scaling groups or EKS node groups with a controlled blue/green or rolling deployment, and verify service health with Route 53/ALB health checks.
5. After remediation, re-run Amazon Inspector to validate findings are resolved, update SSM Compliance reporting and send a summary to the security team through SNS; keep the Automation runbook in a Systems Manager Automation library for repeatable fleet-wide response.
**Rationale:** This approach uses Amazon Inspector for continuous discovery, Systems Manager Patch Manager and Automation for controlled, automated remediation, and image-based rebuilds for immutable infrastructure, aligning with AWS best practices for detection, automated response, and minimal blast radius.
## Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
Centralized compliance is enabled by configuring the delegated administrator account in Systems Manager Explorer and enabling resource data sync to aggregate patch compliance state from every account into a single S3 bucket, which can then be queried with Athena or visualized in QuickSight.
Session Manager for Auditable Administration
Traditional SSH-based access has three structural weaknesses: long-lived key material sits on operator laptops, port 22 must be reachable (even if only through a bastion), and shell activity is not centrally recorded without extra tooling. Session Manager eliminates all three.
Session Manager tunnels an interactive shell through the SSM Agent’s outbound HTTPS connection to the SSM endpoints. There is no inbound port, no SSH key pair, and no bastion host. Access is authorized by IAM policies (ssm:StartSession scoped by instance tag or ARN), and every session can be logged to CloudWatch Logs or S3, optionally with KMS encryption. On Linux, sessions run as ssm-user by default; sudo behavior is controlled by the instance’s sudoers configuration, not by IAM.
The correct hardening pattern for new fleets is: launch instances without an EC2 key pair, attach an instance profile with AmazonSSMManagedInstanceCore, place instances in private subnets with VPC endpoints for ssm, ssmmessages, and ec2messages, and enforce session logging at the Session Manager preferences level. Continuing to distribute SSH keys alongside Session Manager is the trap: it preserves the very attack surface Session Manager was adopted to eliminate, and it leaves an unlogged access channel. Remove authorized_keys provisioning from your AMI bake process.
Host Telemetry with the CloudWatch Agent
The unified CloudWatch agent collects OS-level metrics (memory, disk, per-process CPU) and log files that the EC2 hypervisor cannot see. It is configured via a JSON file typically stored in Parameter Store, then applied with amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux.
The most common operational failure with the agent is missing IAM permissions on the instance profile. The agent needs, at minimum:
logs:CreateLogGroup (unless the group is pre-created)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (for custom metrics)
ssm:GetParameter (to fetch the config from Parameter Store)
The managed policy CloudWatchAgentServerPolicy bundles these. When permissions are missing, the agent starts successfully and appears healthy in systemctl status, but logs never arrive in CloudWatch — the failures are visible only in /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Any host-security design that assumes centralized logs must validate delivery, not just agent status.
Bringing It Together
The defensive loop is: Inspector discovers CVEs on hosts and container images, findings flow into Security Hub for aggregation, Patch Manager remediates via scheduled maintenance windows or Patch Now for emergencies, Session Manager provides the sole administrative access path, and the CloudWatch agent streams both patching evidence and runtime logs to a centralized account. Each control assumes the others: Inspector without Patch Manager produces reports no one acts on; Patch Manager without centralized logging produces no audit trail; Session Manager without proper IAM leaves either too much or too little access; and the CloudWatch agent without correct log permissions produces the illusion of visibility.
← Governance · All domains · Container →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →