Amazon Inspector is enabled in your AWS account, but it reports no findings for a fleet of long-running EC2 instances. What are the likely causes, and what does Inspector need in order to scan an instance at all?

## Why an empty findings list is a smell A fleet of long-running EC2 instances almost certainly has *some* vulnerable package, because CVEs are published constantly against exactly the base images those instances were built from. So the first hypothesis is never "we are clean"; it is "Inspector cannot see them". ## What Inspector needs on EC2 Inspector builds a software inventory and matches it against vulnerability data. On EC2 that inventory comes through **AWS Systems Manager**. For an instance to be scanned it must: - run the **SSM Agent** (pre-installed on Amazon Linux and recent Windows AMIs, but not on every image), - have an **instance profile** with the Systems Manager permissions the agent needs, - have **network reachability** to the SSM service endpoints — a route through a NAT gateway, or interface VPC endpoints for `ssm`, `ssmmessages` and `ec2messages` in a private subnet with no egress, - and run a **supported operating system and platform**. If the agent cannot register, the instance is not a managed node, Inspector has no inventory, and it never enters coverage. Inspector also offers agentless EC2 scanning based on EBS snapshots for supported cases, which removes the agent dependency but has its own eligibility rules — so the practical check is always the coverage list, not an assumption about mode. ## The other layers of "enabled" Inspector's enablement is more granular than a single switch: - It is **per account and per Region**. Instances in an unmonitored Region are invisible. - **Scan types are enabled independently**: EC2, ECR container images, and Lambda functions. Someone may have enabled only ECR. - In an Organization, a **delegated administrator** enables Inspector for members, with auto-enable for new accounts. Without it, an account created last month may never have been switched on. ## Diagnosing it in order ```bash # 1. Is the account/Region actually scanning, and for what? aws inspector2 batch-get-account-status # 2. Which resources are in coverage, and with what status? aws inspector2 list-coverage \ --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' # 3. For instances missing from coverage: are they managed by SSM at all? aws ssm describe-instance-information ``` An instance that is absent from `list-coverage` and absent from `describe-instance-information` is an SSM problem — agent, instance profile, or network path — not an Inspector problem. An instance present in coverage but with an inactive status usually points at a stale agent or an unsupported platform. ## What Inspector actually reports when it is working Findings carry the CVE identifier, a severity and score, the affected package and version, and whether a fix is available — which is the field that makes remediation triage tractable, since "critical with no vendor fix" needs a different response from "critical, patched upstream last week". Scanning is **continuous**: Inspector re-evaluates existing inventory when new vulnerability data lands, so findings appear on instances nobody has deployed to in months. For ECR it can scan on push and re-scan images for a configured window; for Lambda it assesses function packages and, with code scanning, the function code itself. ## The wider lesson Every agent- or inventory-based security service has the same class of failure: silent non-coverage that looks identical to good news on a dashboard. The operational discipline is to alarm on **coverage**, not only on findings — compare the count of scanned instances against the count of running instances from EC2 or from your Auto Scaling groups, and treat a divergence as an incident. A clean scoreboard from a scanner nobody verified is the most expensive kind of false comfort.