AMI Scanning

The AMI Scanning capability extends the Praetorian Guard Platform (PGP) AWS integration to identify operating-system-level vulnerabilities inside Amazon Machine Images (AMIs). PGP reads the AMI's underlying EBS snapshot, extracts the package manifest, matches each installed package against Amazon Linux Security Advisories (ALAS), enriches CVEs with EPSS exploitation probability, and flags issues listed in CISA's Known Exploited Vulnerabilities (KEV) catalog -- all without launching the instance.

Overview

AMI Scanning gives security teams a way to catch vulnerable operating-system packages baked into machine images before those images are used to launch production workloads. Rather than scanning a running instance, PGP reads directly from the AMI's EBS snapshot using the AWS EBS Direct API, extracts the RPM database, and surfaces vulnerable packages as risks linked to the AMI asset.

This capability is opt-in and is not enabled by default. It requires additional read-only AWS permissions beyond the base AWS integration, which is why customers must explicitly enable it during integration setup.

What AMI Scanning Provides

  • Pre-deployment vulnerability detection: Identifies vulnerable OS packages in AMIs before they are used to launch instances

  • No instance launch required: Reads directly from EBS snapshots -- no compute cost, no production impact, no agent to install

  • Threat-intelligence enriched findings: Each CVE is enriched with EPSS exploitation probability and cross-referenced against the CISA KEV catalog

  • Asset-level visibility: Findings are attached directly to the AMI asset in PGP, so you can see exactly which images contain which vulnerabilities

How AMI Scanning Works

When you trigger an AMI scan, PGP performs the following sequence:

  1. Describe the AMI: PGP calls ec2:DescribeImages and ec2:DescribeSnapshots to read the AMI's metadata, including its root device, owner, encryption state, and underlying snapshot ID.

  2. Read the snapshot blocks: Using the EBS Direct API (ebs:ListSnapshotBlocks and ebs:GetSnapshotBlock), PGP reads only the blocks of the snapshot it needs -- typically the filesystem metadata and the RPM database -- without copying the snapshot or launching an instance.

  3. Extract the package manifest: PGP parses the filesystem (ext4 or XFS) and reads the RPM database (/var/lib/rpm/Packages) to enumerate every installed package and its version.

  4. Match against ALAS: PGP fetches the latest Amazon Linux Security Advisories and matches each package against advisories that affect that package's version on the AMI's distro (Amazon Linux 2 or Amazon Linux 2023).

  5. Enrich with EPSS: For every CVE produced by the ALAS match, PGP queries the EPSS feed to attach an exploitation probability score and percentile.

  6. Cross-reference KEV: PGP cross-references each CVE against the CISA Known Exploited Vulnerabilities catalog and flags those known to be actively exploited.

  7. Emit risks: Each vulnerability is emitted as a risk attached to the AMI asset, with severity, EPSS score, and KEV status preserved.

What Gets Scanned

AMI Scanning is designed for RPM-based Amazon Linux AMIs. Specifically:

  • Amazon Linux 2 (AL2) -- fully supported

  • Amazon Linux 2023 (AL2023) -- fully supported

  • Custom AMIs derived from AL2 or AL2023 -- supported, provided the RPM database is intact and the root filesystem is ext4 or XFS

What Cannot Be Scanned

Some AMIs cannot be peeled by design. PGP surfaces these as coverage findings on the AMI asset rather than failing silently, so the gap is visible in your inventory:

  • AWS Marketplace AMIs: Sealed by an AWS-owned KMS key that customers cannot grant access to. PGP cannot read them.

  • Instance-store AMIs: AMIs without an EBS-backed root volume have no snapshot to read.

  • Oversized AMIs: AMIs whose root volume exceeds the configured size limit (default 256 GB) are skipped to bound scan cost. The limit is configurable per scan.

  • Non-RPM AMIs: AMIs based on Debian, Ubuntu, Windows, or other non-RPM operating systems are not currently supported.

Required Permissions

AMI Scanning requires four additional AWS IAM actions beyond the base AWS integration. These are read-only and limited to AMI metadata and EBS snapshot blocks:

  • ec2:DescribeImages -- Read AMI metadata (name, owner, root device, encryption status)

  • ec2:DescribeSnapshots -- Read snapshot metadata (encryption state, KMS key, size)

  • ebs:ListSnapshotBlocks -- Enumerate the populated blocks of a snapshot

  • ebs:GetSnapshotBlock -- Read individual snapshot blocks (the underlying mechanism for snapshot peeling)

These permissions are granted via a conditional block in the PGP CloudFormation and Terraform templates that is emitted only when image scanning is enabled. PGP does not request kms:Decrypt -- the EBS Direct API decrypts customer-managed-key snapshots transparently when the role has implicit access to the underlying key. PGP cannot read AMIs encrypted with AWS-owned keys (Marketplace AMIs).

Enabling AMI Scanning

The path to enabling AMI Scanning depends on whether you are setting up a new AWS integration or already have one connected to PGP.

Important -- existing integrations must be redeployed. If your AWS integration was set up before AMI Scanning was available, your deployed CloudFormation stack or Terraform configuration does not include the four additional permissions. Toggling AMI scanning on in the PGP UI alone is not enough -- you must regenerate the integration template with image scanning enabled and redeploy it to your AWS environment, or AMI scans will fail with AccessDenied errors at runtime. The reintegration steps below preserve your existing integration's history and findings; you do not need to delete and recreate the integration.

For New AWS Integrations

  1. Begin a new AWS integration by following the Amazon Web Services - IaC Deployment (Recommended) guide or the Amazon Web Services - Manual Deployment guide.

  2. In the AWS integration setup modal, check the Enable image scanning toggle. This signals PGP to include the AMI scanning permissions in the generated CloudFormation, Terraform, or manual policy template.

  3. Deploy the generated template (or apply the manual policy) as you would for any AWS integration. The template will include the four AMI scanning permissions in addition to the base integration permissions.

  4. Click Finish to complete the integration. PGP validates that the assumed role has the required permissions before saving.

For Existing AWS Integrations

If you already have an AWS integration with PGP and want to add AMI Scanning, you must regenerate and redeploy your integration template:

  1. Navigate to Integrations in your PGP dashboard and locate your existing AWS integration.

  2. Re-run the AWS integration wizard with the same scope (Organization-level or individual account) and the same Account ID and Target Root or OU IDs as your existing integration.

  3. Check the Enable image scanning toggle in the integration setup modal.

  4. Download the regenerated CloudFormation or Terraform template, or copy the updated inline policy from the manual instructions.

  5. Update your existing deployment -- do not create a new stack:

    • CloudFormation: In the AWS CloudFormation console, locate the existing PGP stack (or StackSet for Organization-level deployments), click Update, and provide the regenerated template. AWS CloudFormation will detect the additional permissions on the existing IAM role and apply them in place.

    • Terraform: Replace your existing PGP integration .tf file with the regenerated one and run terraform apply. Terraform will update the inline policy on the existing role.

    • Manual: In the AWS IAM console, edit the inline policy on the existing PGP-integration-role and append ebs:GetSnapshotBlock, ebs:ListSnapshotBlocks, ec2:DescribeImages, and ec2:DescribeSnapshots to the existing Action list. For Organization-level integrations deployed manually, repeat this step in every member account.

  6. Wait for the deployment to reach a successful state (CloudFormation: UPDATE_COMPLETE; Terraform: clean apply with no errors; Manual: policy saved).

  7. Return to the PGP integration modal and click Finish. PGP will revalidate the integration and confirm the new permissions are in place.

Updating the IAM role in place preserves the integration's history, scan results, and findings -- there is no need to delete or recreate the AWS integration in PGP.

Running an AMI Scan

AMI Scanning is triggered manually on a per-AMI basis. PGP does not automatically scan every AMI in your environment because EBS Direct API reads incur AWS data-transfer and block-read charges; operators decide which AMIs to scan and when.

Step 1 - Locate the AMI Asset

  1. In PGP, navigate to Assets.

  2. Filter or search for assets of type AWS::EC2::Image. AMIs are discovered automatically by the base AWS integration as part of resource enumeration.

  3. Click on the AMI you want to scan to open its asset detail view.

Step 2 - Trigger the Scan

  1. From the asset detail view, choose the option to run a capability against this asset.

  2. Select caligula-ami (AMI Scanning) from the capability list.

  3. Optionally adjust scan parameters (described below).

  4. Submit the scan. PGP queues the job and begins reading the AMI's snapshot via the EBS Direct API. Scan duration depends on AMI size and the density of the package database; typical AL2 / AL2023 AMIs complete in a few minutes.

Scan Parameters

  • min_severity: Minimum severity threshold for vulnerability findings. Valid values: low, medium, high, critical. Default: low. Coverage findings (Marketplace, oversized, instance-store) are always emitted regardless of this setting.

  • kev_only: When set to true, only emit vulnerability findings whose CVE appears in the CISA KEV catalog. Useful for prioritizing actively-exploited vulnerabilities for emergency response. Default: false.

  • max_ami_size_gb: Skip AMIs whose root volume exceeds this many gigabytes. Bounds the cost of scanning unusually large images. Default: 256.

Findings

AMI Scanning produces two categories of findings, both attached to the AMI asset.

Vulnerability Findings

Each vulnerable package produces a vulnerability finding with:

  • CVE ID and ALAS advisory ID

  • Severity: Mapped from the ALAS advisory rating (low / medium / high / critical)

  • EPSS score and percentile: Probability the CVE will be exploited in the next 30 days, when EPSS is reachable

  • KEV flag: Indicates whether CISA has observed the CVE being actively exploited in the wild

  • Affected package and version: The exact RPM package and version installed in the AMI

  • Source AMI: The AMI ID and region of the image where the vulnerability was found

Coverage Findings

When PGP cannot fully scan an AMI, it emits a coverage finding so the gap is visible in your inventory rather than silently absent. Coverage findings include:

  • Marketplace AMI: AMI is sealed by AWS-owned KMS encryption

  • Instance-store AMI: No EBS snapshot to read

  • Oversized AMI: Root volume exceeds the configured size limit

  • Access denied: PGP role lacks permission to describe the AMI or its snapshot (typically a cross-account share where access was not granted)

  • Enrichment unavailable: ALAS, EPSS, or KEV upstream service was unreachable; vulnerability findings may still be emitted but with reduced threat-intelligence enrichment

Enrichment failures do not stop the scan -- vulnerability findings are still produced where the ALAS match succeeded. The coverage finding documents which feeds were unavailable so you know whether to re-run the scan once the upstream service recovers.

Limitations

  • RPM-based Amazon Linux only: AMIs based on Debian, Ubuntu, Windows, or other non-RPM operating systems are not supported. Support for additional distributions is on the roadmap.

  • AWS Marketplace AMIs: Cannot be peeled because they are sealed by an AWS-owned KMS key.

  • Manual trigger only: AMI scans must be initiated explicitly per AMI; PGP does not automatically scan every AMI it discovers.

  • Cost considerations: EBS Direct API charges per block read. Snapshot peeling typically reads only the filesystem metadata and the RPM database, not the entire image, but per-scan AWS cost still scales with the size and density of each image.

Troubleshooting

Scan fails with AccessDenied on ebs:ListSnapshotBlocks or ebs:GetSnapshotBlock: Your deployed PGP integration role does not have the AMI Scanning permissions. Follow the For Existing AWS Integrations instructions above to regenerate and redeploy your template.

Scan emits a "Marketplace AMI" coverage finding: This is expected for AWS Marketplace images. They cannot be peeled. Refer to the publisher's vulnerability guidance for Marketplace images you are using.

Scan emits an "Oversized AMI" coverage finding: The AMI's root volume exceeds the configured size limit. Re-run the scan with a higher max_ami_size_gb value if you want to scan larger images.

Scan emits an enrichment-unavailable finding: One of the threat-intelligence feeds (ALAS, EPSS, or KEV) was unreachable when the scan ran. Vulnerability findings will still be emitted but may lack EPSS or KEV enrichment. Re-run the scan to retry the enrichment.

No findings emitted on a known-vulnerable AMI: Confirm the AMI is RPM-based Amazon Linux. For non-RPM AMIs, no advisory matching is performed. If the AMI is RPM-based and the scan completed without findings, the installed packages may be at the latest patched versions.

Support

If you encounter issues enabling or running AMI Scanning, please reach out to our support team at support@praetorian.com. Including the AMI ID, the AWS region, and the time of the scan helps us trace the request and accelerate diagnosis.