AWS 411: Inspector findings and remediation gates
Why this lesson matters
Amazon Inspector continuously assesses supported EC2, ECR and Lambda resources, but a finding list is not a release policy. Architects must first prove scan coverage, then combine vulnerability evidence with exploitability, reachability, workload exposure, age and business impact, route ownership, govern exceptions and verify remediation through rescanning.
Coverage before findings
Enable Inspector across required organization accounts and Regions with delegated administration and deliberate auto-enable policy. Coverage differs by resource type and prerequisite. EC2 scanning can use agent-based Systems Manager paths or agentless capabilities according to current support; ECR scans image packages; Lambda standard scanning covers package dependencies and optional code scanning has separate coverage/cost. Confirm supported OS/runtime, scan status and last scan.
An empty finding list is meaningful only when the resource is inventoried, eligible, enabled and successfully scanned with current data. Track uncovered, unsupported, stale, stopped and failed resources separately. New accounts, Regions, repositories, instances and functions must enter coverage automatically or trigger an exception.
| Evidence | Decision supported | Insufficient substitute |
|---|---|---|
| Coverage/status/reason | Was resource assessed? | Zero findings |
| Finding ARN/type/resource | Stable work identity | CVE title alone |
| Package path/current/fixed version | Concrete remediation | Severity label alone |
| Inspector/CVSS/exploit context | Technical likelihood | One score without context |
| Reachability/exposure/runtime use | Workload priority | Internet tag alone |
| First/last observed and rescan | Age and closure | Ticket marked done |
Finding interpretation and gates
Normalize each finding with account, Region, resource/digest/version, owner, environment, vulnerability, affected package/function, fixed version, score vector, exploit information, network reachability where available, first/last seen and scan coverage. One vulnerability can affect many independently owned resources; one resource can have many findings. Preserve both identities.
Use policy tiers rather than a universal severity threshold. A production release gate can reject exploitable critical/high findings with fixes, stale scans, failed coverage, forbidden packages or expired exceptions. A lower environment may warn while still producing evidence. Existing workloads need remediation SLOs by risk and exposure, not a deployment-only gate that leaves old systems vulnerable.
Inspector score and vendor/CVSS data can differ because context evolves. Do not silently select the lowest score. Record policy version and why context raised/lowered priority. A no-fix finding still needs mitigation, isolation, compensating controls, accepted risk or workload retirement.
Suppression rules reduce displayed noise but do not repair resources. Make criteria narrow and review matches, owner, rationale and expiry outside the rule when the service does not enforce expiry. Never suppress because the team cannot meet an SLO. Sample suppressed findings and alert when scope grows unexpectedly.
Remediation lifecycle
For EC2, prefer immutable replacement with patched images where architecture permits; otherwise patch under Systems Manager maintenance controls and verify application health. For ECR, update dependency/base image, rebuild once, rescan exact digest and redeploy that digest. For Lambda zip, update dependencies/code, rebuild/sign, publish a version, test and shift alias. Merely patching a source branch does not change deployed bytes.
Remediation closure requires a successful scan of the deployed resource showing the finding closed or a documented changed identity relationship, plus functional/security verification. Inspector may close a finding when a resource is terminated or image ages out; that is not proof customers run a fixed replacement. Reconcile old-to-new instance AMI, image digest or function version.
~~~bash aws inspector2 batch-get-account-status aws inspector2 list-coverage --filter-criteria file://coverage-filter.json aws inspector2 list-findings --filter-criteria file://finding-filter.json aws inspector2 batch-get-finding-details --finding-arns FINDING_ARN aws inspector2 list-suppression-rules ~~~
Workshop and failure analysis
Analyze supplied coverage for thirty resources, classify blind spots, then rank twenty findings using a written policy. Produce gates for EC2 AMIs, ECR digests and Lambda versions; design exceptions and remediation evidence; trace five replacements to runtime. Reconcile Inspector, Security Hub and ticket updates without duplicate work.
Test 22 failures: account disabled, Region missed, unsupported OS, stale agent, network prerequisite absent, Lambda scan type misunderstood, ECR scan stale, zero findings called safe, score chosen opportunistically, reachability treated as certainty, one CVE collapses distinct assets, owner missing, gate checks tag not digest, source fixed but artifact stale, no-fix ignored, suppression broad, exception no expiry, patch reboots unsafely, replacement not deployed, finding closed by resource deletion, rescan absent, and ticket closes before customer/security verification.
Cost and acceptance
Price EC2 instance scanning, ECR rescans, Lambda standard/code scanning, SSM/remediation runtime, Security Hub ingestion and logs under current pricing. This lesson creates nothing. Submit coverage ledger, finding model, prioritization/gate policy, exception register, three remediation runbooks, replacement proof, metrics and all diagnoses. Pass requires proven coverage, immutable identity, risk-context decisions and rescan-backed closure.