Cloud / Amazon Inspector Interview questions

Amazon Inspector is the AWS service for automated vulnerability management. It continually scans your workloads for known software vulnerabilities (CVEs) and unintended network exposure, then ranks what it finds so you know what to fix first.

You don't build scan jobs or schedules. Once Inspector is activated, it discovers EC2 instances, container images in Amazon ECR and Lambda functions on its own, and it can scan code repositories through Code Security. New resources are picked up automatically.

Findings appear in the Inspector console, flow to AWS Security Hub, and are published as Amazon EventBridge events so you can trigger tickets or patching. Inspector only detects and reports. It never patches or changes your resources.

Amazon Inspector scans four kinds of targets: EC2 instances, ECR container images, Lambda functions and code repositories. What it checks depends on the target.

Container images and SBOMs can also be scanned inside CI/CD tools before they reach ECR, which moves vulnerability checks earlier in the pipeline.

Inspector groups its coverage into scan types that you switch on per account and Region. The first time you activate it, EC2 scanning, ECR scanning and Lambda standard scanning are enabled together.

• EC2 scanning - package vulnerabilities and network reachability, collected agent-based, agentless or both.
• ECR scanning - OS and language package vulnerabilities in container images, with continuous rescans.
• Lambda standard scanning - vulnerable dependencies in functions and layers.
• Lambda code scanning - an optional extra layer that looks for flaws in your own function code.
• Code Security - source code, dependency and infrastructure-as-code scanning for repositories.

CIS configuration scans for EC2 are run separately, on demand or on a schedule.

Amazon Inspector Classic was the original version of the service. You created assessment targets and templates, installed the Inspector Classic agent, and ran assessments against rules packages. AWS ended support for it on May 20, 2026, so the Classic console and resources are no longer accessible.

The current Inspector replaced it with a continuous model. It discovers resources on its own, uses the SSM Agent or no agent at all, covers far more than EC2, and is driven through the inspector2 API. The old Classic agent is obsolete and can be removed from servers.

In interviews this usually comes up as a migration question. If you describe assessment templates or runs, say clearly that they belong to the legacy service and not to what you would build today.

In the console, open Amazon Inspector, choose Get started and then Activate Inspector. The first activation creates the service-linked role AWSServiceRoleForAmazonInspector2 and turns on the default scan types. Activation is per account and per Region.

From the CLI you can pick scan types explicitly:

aws inspector2 enable --resource-types EC2 ECR LAMBDA LAMBDA_CODE

aws inspector2 batch-get-account-status

Add CODE_REPOSITORY if you also want Code Security. Instead of repeating this account by account, most teams activate through a delegated administrator for the whole organization. New accounts get a free trial, so you can see real coverage and cost before paying.

A finding is Inspector's record of one security issue on one resource: a vulnerable package on an instance, an exposed port, or a flaw in function code.

Each finding carries a title, severity, Inspector score, the affected resource, remediation guidance, a status, and first and last observed times. Package vulnerability findings add the CVE ID, the vulnerable package and version, whether an exploit is known, the EPSS score, and whether a fix is available.

Findings are created and updated automatically. When the underlying issue goes away, for example because the package was upgraded, Inspector closes the finding without any action from you.

Inspector produces three finding types, and the type decides which remediation details you get.

Only package vulnerability findings carry CVE, EPSS and fix information. Network reachability findings instead describe the open ports and the path that allows access.

The Inspector score is a context-adjusted risk score for a package vulnerability finding. It starts from the CVSS base score of the CVE and then adjusts it using what Inspector knows about your environment, such as whether an EC2 instance is reachable from the internet.

That is why one CVE can score differently on two resources. A critical flaw in a library on an isolated instance may land below its published CVSS, while the same flaw on an internet-facing host keeps a high score. The finding's severity is derived from this score.

The finding details panel shows the score together with the CVSS vector and the adjustments applied, so you can see exactly why it moved.

Inspector uses six severity labels, mostly derived from the Inspector score.

Untriaged is the one people trip over. It does not mean harmless, it means the source has not assigned a severity yet, so it is worth a look rather than an automatic dismissal.

In agent-based scanning, Inspector uses the AWS Systems Manager (SSM) Agent already on the instance to collect a software inventory, then matches that inventory against vulnerability data. There is no separate Inspector agent.

The instance must be a managed instance in Systems Manager in the same account, run a supported OS, and have the SSM Agent online with permissions such as AmazonSSMManagedInstanceCore or Default Host Management Configuration. Inspector creates SSM associations that gather the inventory on a recurring basis.

Beyond OS packages, agent-based scanning can find vulnerabilities in programming-language packages on Linux through deep inspection. A fresh scan starts when an instance is launched, when software is installed or removed, or when a new CVE affects something already installed.

Agentless scanning assesses an instance without any software running on it. Inspector takes snapshots of the EBS volumes attached to the instance, reads the snapshot data to build a software inventory, and compares that inventory with its vulnerability intelligence.

It is useful for instances that are not managed by Systems Manager, because the SSM Agent, its IAM permissions and its network path are not needed. It only applies to EBS-backed instances, and it works on a periodic cycle of roughly every 24 hours instead of reacting immediately to each software change.

Agentless scans are used when the account is in hybrid scan mode and the instance has no working SSM Agent.

Hybrid scan mode lets Inspector use the best method per instance. It relies on the SSM Agent where the instance is managed, and automatically falls back to agentless scanning for eligible instances that have no working agent. New accounts start in hybrid mode.

You change it from the EC2 settings page or with the API:

aws inspector2 update-configuration \
  --ec2-configuration scanMode=EC2_HYBRID

Network reachability scanning finds EC2 instances that have ports reachable from outside the VPC. It analyzes your AWS network configuration, including security groups, network ACLs, route tables and gateways, instead of sending probe packets.

A finding lists the open port range, the protocol and the network path that makes it reachable, for example an internet gateway route plus a security group that allows 0.0.0.0/0 on TCP 3389. No agent is required, and the analysis repeats about every 24 hours.

These findings also feed the Inspector score, which is why an exposed instance's CVEs tend to rank higher than the same CVEs on a private one.

Enhanced scanning is the registry-level setting that hands ECR image scanning over to Inspector. Once it is on, each eligible image is scanned when it is pushed, and then rescanned whenever new vulnerability data affects a package in it.

It covers both operating system packages and programming-language packages, which basic scanning does not. Only images in ACTIVE status are scanned, and findings identify the repository, tag and digest.

You can scan every repository or use filters to include only selected ones. How long an image keeps being rescanned is controlled by the ECR rescan duration setting.

Lambda standard scanning checks the third-party packages in a function's code and layers for known CVEs. Inspector scans a function when it discovers it, when it is deployed or updated, and when new vulnerability data affects its dependencies.

A function is eligible when it uses a supported runtime, was invoked or updated in the last 90 days, and is not excluded by tag. Functions that go quiet for 90 days drop out of scanning and come back as soon as they are invoked or changed again.

Standard scanning is the default Lambda scan type and the base layer for Lambda code scanning.

Lambda code scanning analyzes the custom application code inside your Lambda functions, not just the packages it imports. It looks for issues such as injection flaws, data leaks, weak cryptography and missing encryption.

Findings are code vulnerability findings. They point to the offending lines with a snippet and can include a suggested fix, which makes them practical for developers to act on.

You must have Lambda standard scanning active first, and code scanning adds its own per-scan charge, so it is common to enable it only for production or customer-facing functions.

Code Security extends Inspector to source code repositories. It scans first-party application code, third-party dependencies and infrastructure-as-code templates for vulnerabilities and misconfigurations, using the Amazon Q Developer scanning engine.

You connect supported source providers and define scan configurations, for example scanning on pull requests or on a schedule. Findings appear in Inspector alongside runtime findings, so a team can see an issue in a repository and the deployed resource in one place.

The point is to shift left. Problems get flagged in the repository or CI/CD pipeline, before the code or template is ever deployed.

CIS scans check the operating system configuration of EC2 instances against Center for Internet Security (CIS) Benchmarks. They look at hardening settings such as SSH configuration, password policy, file permissions and disabled services, not at vulnerable software.

You can run them on demand or on a schedule, and target instances by account or tags. They rely on SSM-managed instances. Each check is reported as passed, failed or skipped, and results can be viewed per instance or downloaded as a CSV file.

CIS scans are separate from the CVE-based findings, so they answer a different question: is this host configured securely?

A suppression rule is a saved filter that automatically hides matching findings. Findings that match get the Suppressed status and drop out of the default Active view, but they are not deleted.

Typical uses are accepted risks, such as a CVE in a package that is never exposed, or noise from sandbox accounts. You build the rule from the same criteria you use to filter findings, for example a CVE ID plus a resource tag.

Suppression only changes visibility. It does not stop scanning or reduce cost, and you can edit or remove the rule to bring the findings back.

An SBOM export produces a software bill of materials, a machine-readable inventory of the packages and libraries in your scanned resources. Inspector can export it in CycloneDX 1.4 or SPDX 2.3 format.

The report is written to an S3 bucket and encrypted with a KMS key you provide. You can filter by resource type, account or tags, so you can export just the production container images, for instance.

aws inspector2 create-sbom-export \
  --report-format CYCLONEDX_1_4 \
  --s3-destination bucketName=my-sbom-bucket,keyPrefix=inspector/,kmsKeyArn=<key-arn>

Teams use SBOMs for audits, customer security questionnaires and for checking quickly whether a newly disclosed library is anywhere in their estate.

The delegated administrator is the AWS Organizations member account that manages Inspector for the whole organization. The management account designates it, and there can be only one.

From there you can activate scan types for member accounts, auto-enable Inspector for accounts that join later, see aggregated findings and coverage, and manage organization-wide settings such as the ECR rescan duration. Member accounts still own their resources, but the administrator gives security teams one place to look.

Using a dedicated security account as the delegated administrator, rather than the management account, is the usual pattern.

The Inspector VM Scanner is the newer scanning engine for agent-based EC2 scanning, introduced in May 2026. It replaces the previous agent-based scanner with an architecture tuned for performance.

AWS highlights two gains: broader detection coverage, and lower CPU use on the instance while a scan runs, which reduces impact on production workloads. You opt in from the console or the API. No additional IAM instance profile role is needed on your instances.

It is available in all Regions where Inspector runs at no extra charge, and the existing agent-based EC2 pricing still applies.

The dashboard is the starting point for seeing coverage and risk across your accounts. It summarizes findings by severity, shows the most exposed resources, and tracks which resources Inspector is and is not scanning.

The Environmental coverage panel counts the accounts, EC2 instances, ECR repositories and images, and Lambda functions being scanned, and flags resources that are not covered. Each resource that is not scanned carries a status and a reason code, such as an unmanaged instance or an unsupported OS.

Checking coverage first matters, because a clean findings list is meaningless if half the fleet is not being scanned.

Every finding is in one of three statuses.

Inspector closes findings on its own when it sees the problem is resolved. Closed findings are kept for a limited time and then removed, so export anything you need for audit history before then.

Inspector finds weaknesses that could be exploited. GuardDuty detects suspicious activity that is already happening. One is vulnerability management, the other is threat detection.

They complement each other. An internet-exposed instance with a critical CVE (Inspector) that suddenly starts beaconing out (GuardDuty) is exactly the case you want both to flag. Both send findings to Security Hub.

The current Inspector is continuous and automatic. Classic was assessment-run based and EC2-only. Classic support ended on May 20, 2026.

If a team still has Classic-era runbooks, the migration is mostly about enabling the new service, confirming coverage on the dashboard, and retiring the old agent.

Agent-based scanning collects inventory through the SSM Agent; agentless scanning reads EBS snapshots. Both end up matching a software inventory against vulnerability data, but they differ in prerequisites, speed and reach.

Hybrid mode combines them: agent where possible, snapshots for everything else.

Inspector uses Systems Manager State Manager. It creates an association, named InspectorInventoryCollection-do-not-delete, that runs the software inventory plugin on managed instances. The SSM Agent gathers installed packages and sends the result back for analysis.

sequenceDiagram
  participant I as Amazon Inspector
  participant S as SSM State Manager
  participant A as SSM Agent on instance
  I->>S: Create inventory association
  S->>A: Run software inventory plugin
  A-->>I: Installed OS and language packages
  I->>I: Match against vulnerability intelligence
  I-->>I: Create or close findings

A new evaluation starts when an instance is launched or becomes managed, when software is installed or removed, and when a new CVE matches stored inventory. Deleting the association breaks collection and the instance will show up as stale or unmanaged in coverage.

Agentless scanning turns the instance's disks into the inventory source, so nothing runs inside the guest. The flow is driven entirely by Inspector from outside the instance.

flowchart TD
  A["Hybrid mode finds EC2 instance without working SSM Agent"] --> B["Snapshot each attached EBS volume"]
  B --> C["Read snapshot data and extract OS and language packages"]
  C --> D["Build software inventory"]
  D --> E["Match against vulnerability intelligence"]
  E --> F["Create or update package vulnerability findings"]

1. Inspector identifies an eligible EBS-backed instance that is not usefully managed by SSM.
2. It snapshots each attached volume.
3. It reads the snapshot contents to list installed packages.
4. That inventory is compared with vulnerability data from many advisory sources.
5. Findings are created, updated or closed, and the cycle repeats roughly every 24 hours.

Because it never touches the running OS, the instance sees no agent CPU load, but it also cannot react to a change until the next cycle.

Inspector takes the CVSS base score for the CVE from its preferred source, such as the National Vulnerability Database or the OS vendor's advisory, and then adjusts it for your environment.

1. Identify the CVE and the base score and vector from the source advisory.
2. Look at context for the resource, most importantly network reachability findings for EC2.
3. Adjust the affected metrics, so a vulnerability that needs network access scores lower on a host with no path from outside.
4. Publish the resulting Inspector score and derive the severity from it.

The finding details show the base vector next to the adjusted one, which is what you quote when someone asks why a published 9.8 became an 8.1 in your account. Because the score is contextual, sort by Inspector score and not by the raw CVSS number when you triage.

Unmanaged means Inspector cannot use the SSM Agent on that instance. Work through the usual SSM prerequisites in order.

1. Confirm the instance is running a supported OS and the SSM Agent is installed and running.
2. Check the instance has SSM permissions, either an instance profile with AmazonSSMManagedInstanceCore or Default Host Management Configuration.
3. Verify network access to the SSM endpoints, through a NAT gateway or the ssm, ssmmessages and ec2messages VPC endpoints.
4. In Fleet Manager, make sure the ping status is Online.
5. Look for an exclusion tag such as InspectorEc2Exclusion.

To list affected instances and their reason codes:

aws inspector2 list-coverage --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}],"scanStatusCode":[{"comparison":"EQUALS","value":"INACTIVE"}]}'

Look for UNMANAGED_EC2_INSTANCE. If you cannot fix SSM on that host, hybrid mode will still cover an EBS-backed instance agentlessly.

After the initial scan on push, Inspector rescans an image whenever a new CVE affects a package in it. The rescan duration decides how long an image stays in that monitored state.

When an image has not been pushed or used within the configured window, Inspector marks it inactive with an expired reason and schedules its findings for closure. Raising the duration does not revive images that are already inactive. Set from a delegated administrator, the value applies to every member account.

Short durations suit teams that build constantly; long-lived base images need longer ones.

Basic scanning is ECR's built-in scan. Enhanced scanning hands the job to Inspector for continuous and deeper coverage.

Choose basic for low-risk or test registries where a push-time OS check is enough, and enhanced wherever images run in production and you need rescans when new CVEs appear.

A function is scanned only if it is eligible. All of these must hold:

• It uses a supported runtime.
• It was invoked or updated in the last 90 days.
• The scan targets the $LATEST version.
• It is not excluded by tag.
• It is not encrypted with a customer managed KMS key, which Inspector does not support.

Functions that go 90 days without an invocation or change are automatically excluded and resume scanning when invoked or modified. To exclude a function deliberately, add the tag InspectorExclusion with the value LambdaStandardScanning (or LambdaCodeScanning to skip only code scanning).

Check the Lambda functions tab to see each function's scan status and the reason when it is not being scanned.

A push starts a scan, and new CVE data keeps it alive afterwards.

flowchart LR
  A["Image pushed to ECR repository"] --> B["Inspector sees eligible ACTIVE image"]
  B --> C["Extract OS and language packages from layers"]
  C --> D["Match packages to vulnerability intelligence"]
  D --> E["Create findings with score and fix info"]
  E --> F["Console, Security Hub and EventBridge"]
  G["New CVE published"] --> D

1. The push makes the image a candidate if its repository is in scope for enhanced scanning.
2. Inspector builds an inventory of OS and programming-language packages from the image layers.
3. The inventory is matched with advisory data to create findings.
4. Findings are sent to the console, Security Hub and EventBridge, and shown against the image in ECR.
5. While the image is inside its rescan window, any newly published CVE that matches triggers fresh findings with no rescan of the image itself.

You designate a delegated administrator from the Organizations management account, then enable and auto-enable scanning from that account.

# management account
aws inspector2 enable-delegated-admin-account --delegated-admin-account-id 111122223333

# delegated administrator account
aws inspector2 update-organization-configuration \
  --auto-enable ec2=true,ecr=true,lambda=true

1. Activate Inspector in the management account (the console enables trusted access for you).
2. Designate the security account as delegated administrator, per Region.
3. From the administrator, turn on the scan types for existing members.
4. Set auto-enable so accounts that join later are covered automatically.
5. Configure org-wide settings, such as the ECR rescan duration, and verify coverage on the dashboard.

Repeat for every Region you use, since the service is regional.

Inspector publishes every new or updated finding to Amazon EventBridge, so a rule can route the ones you care about to a target. A common pattern is to alert on new critical findings:

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": {
    "severity": ["CRITICAL"],
    "status": ["ACTIVE"]
  }
}

• SNS or chat integrations for notification.
• Lambda to open a ticket or enrich the finding with resource tags.
• SSM Automation or Run Command to patch an instance, for example with AWS-RunPatchBaseline.

If Security Hub is enabled, findings also flow there in ASFF format, which is useful for cross-service dashboards. Keep automated patching limited to non-production or add an approval step before it touches production.

Add an exclusion tag to the resource. Excluded resources are not scanned and are not billed for scanning.

Do not confuse this with suppression. Exclusion stops scanning, so no findings are produced. Suppression keeps scanning and only hides matching findings. Use exclusion for resources that should never be assessed, such as throwaway lab instances, and suppression for accepted risks on resources you still want to monitor.

Tag hygiene matters here. A tag applied by mistake silently removes a production resource from coverage, so review excluded resources on the coverage view now and then.

Deep inspection lets agent-based scanning look beyond OS packages and find vulnerabilities in programming-language packages, such as application libraries, on Linux instances.

Inspector searches a default set of library paths, /usr/lib, /usr/lib64, /usr/local/lib and /usr/local/lib64. If your applications live elsewhere, you can add up to five custom paths:

aws inspector2 update-ec2-deep-inspection-configuration \
  --package-paths /opt/myapp/lib /srv/app/vendor

Organization administrators can set paths for all members with the org-level variant of the same API. Without the extra paths, a Java or Python dependency installed under an unusual directory is simply never inventoried, which is a classic cause of missing findings.

Generate an SBOM for the build artifact with the Inspector SBOM Generator, then submit it to the Inspector scan API to get a vulnerability report, and fail the build if it breaks your policy.

inspector-sbomgen container --image myapp:1.4 -o sbom.json

aws inspector-scan scan-sbom --sbom file://sbom.json \
  --output-format CYCLONE_DX_1_5 > report.json

1. Build the image or package in the pipeline.
2. Run the SBOM generator against it.
3. Send the SBOM to the scan API and parse the report.
4. Gate on a threshold, for example no Critical findings with a fix available.
5. Push to ECR, where enhanced scanning continues to watch it.

Plugins exist for common CI tools, so the same flow can run in Jenkins, GitHub Actions, GitLab CI and AWS CodeBuild. Pair it with Code Security for repository-level checks earlier still.

Fix the source, then let Inspector confirm it. Each resource type has a different fix path, and the finding's remediation text names the fixed package version.

Do not patch a container by logging into a running task. The image in the registry stays vulnerable and the next deployment brings the flaw back. Use suppression only for risks you have explicitly accepted.

Rank by real exploit risk and reachability, not by raw severity alone. Inspector gives you the signals in the finding itself.

1. Network exposure: is the resource internet-reachable?
2. Exploit available or observed, plus CISA data where present.
3. EPSS score, the estimated probability of exploitation in the wild.
4. Fix available (YES, NO or PARTIAL), so you start with what can be fixed today.
5. Inspector score and severity, then resource criticality from your tags.

Filters make this repeatable:

aws inspector2 list-findings --filter-criteria '{"findingStatus":[{"comparison":"EQUALS","value":"ACTIVE"}],"exploitAvailable":[{"comparison":"EQUALS","value":"YES"}],"fixAvailable":[{"comparison":"EQUALS","value":"YES"}]}'

A Medium with a public exploit on an internet-facing host often deserves attention before a Critical on an isolated one.

They answer different questions, so the real answer is usually both. Use CIS scans to verify hardening and compliance, and package vulnerability scanning to catch known CVEs.

Remember the operational difference. Package scanning runs continuously and can be agentless. CIS scans are run on demand or on a schedule and require SSM-managed instances, so they will not cover hosts where the SSM Agent is not usable.

Create a findings report with an S3 destination and a KMS key. You can choose CSV or JSON and apply the same filter criteria you use in the console.

aws inspector2 create-findings-report \
  --report-format CSV \
  --s3-destination bucketName=my-findings,keyPrefix=inspector/,kmsKeyArn=<key-arn> \
  --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}'

aws inspector2 get-findings-report-status --report-id <report-id>

The bucket policy and the KMS key policy must allow the Inspector service principal to write and encrypt, which is the most common reason an export fails. Use the status call to follow progress. For inventory instead of findings, use create-sbom-export.

Exports are point-in-time snapshots of whatever matched your filter, so schedule them from automation if auditors want a regular history.

It evaluates the AWS network configuration around the instance and checks whether a path exists from an outside source to a port on its network interface.

flowchart LR
  A["Internet or peered network"] --> B["Internet gateway or VPN gateway"]
  B --> C["Route table"]
  C --> D["Network ACL"]
  D --> E["Security group"]
  E --> F["Instance network interface and port"]

If every hop permits the traffic, Inspector raises a network reachability finding with the port range, protocol and path. Because it reads configuration rather than probing the host, an open path does not prove a service is listening, and host firewalls such as iptables are not part of the analysis.

The result is also used as context for the Inspector score of CVEs on that instance.

Choose agentless when you cannot or will not run the SSM Agent but still need vulnerability coverage.

• Third-party appliance or marketplace AMIs where you cannot manage the OS.
• Locked-down workloads with no route to Systems Manager endpoints.
• Environments that cannot tolerate any scan CPU overhead on the host.
• A quick way to get broad coverage while SSM rollout is still in progress.

Prefer agent-based where you can. It reacts faster to software changes, supports CIS scans, and gives deep inspection of language packages. Per-instance rates also differ between the two methods, so compare them on the pricing page.

In practice, hybrid mode is the answer: agent where possible, snapshots as the safety net.

Inspector is pay-as-you-go per resource scanned, with no upfront fee. Each scan type bills differently, and new accounts get a free trial.

• EC2: per instance for the time it is covered, with different rates for agent-based and agentless scanning.
• ECR: a charge for the initial scan of each image and a smaller one for rescans.
• Lambda: per function covered, with code scanning charged additionally.
• Code Security: charged by scan activity on repositories.

To control cost, exclude throwaway resources by tag, shorten the ECR rescan duration, turn off scan types you do not need, and avoid activating Regions you do not use. Check exact rates on the AWS pricing page, since they change.

Inspector scans resources that live in a Region, so activation, settings, delegated administrator and findings are all per Region. Turning it on in us-east-1 tells you nothing about workloads in eu-west-1.

1. Activate Inspector in every Region that holds workloads, ideally through infrastructure as code.
2. Designate the delegated administrator and enable auto-enable in each Region.
3. Check coverage per Region, since a missed Region is a blind spot.
4. Aggregate results with Security Hub cross-Region aggregation, or export reports to a central S3 bucket.

Many teams use a Service Control Policy to deny unused Regions, which also removes the need to scan them.

Start with coverage, because the scan status and reason code usually name the cause.

aws inspector2 list-coverage --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_ECR_CONTAINER_IMAGE"}]}'

1. Confirm the registry uses enhanced scanning. With basic scanning, Inspector is not involved.
2. Check the repository is covered by your scan filters and has no InspectorEcrExclusion tag.
3. Check the image is ACTIVE and not older than the rescan duration. SCAN_ELIGIBILITY_EXPIRED means it aged out.
4. Look for UNSUPPORTED_OS, for example a scratch or distroless base with no recognizable package manager data.
5. If the reason is PENDING_INITIAL_SCAN, give it a few minutes after the push.

If none of these explain it, check that the repository filter in the ECR scanning settings has not been narrowed to a different name pattern, which quietly leaves new repositories out.

Inspector stores the software inventory it has already collected for each resource. When its vulnerability intelligence is updated with a new CVE, it simply re-matches that stored inventory, so findings appear without running a new scan on the resource.

flowchart TD
  A["Inventory stored for each resource"] --> C[Match]
  B["New CVE added to vulnerability intelligence"] --> C
  C --> D{Resource still in scope?}
  D -- Yes --> E["New finding created"]
  D -- No --> F["No new finding"]

This is why the CVE shows up within a short time of publication even if nothing changed on the instance. It works for managed EC2 instances, eligible Lambda functions and ECR images inside their rescan window. An image that aged out, or an instance whose inventory has gone stale because the SSM Agent stopped, will not get the new finding until it is back in scope.