Scanning EC2 Machine Images for Vulnerabilities Before Launch

aws ec2 describe-images \
  --owners self \
  --query "Images[*].[ImageId,Name,CreationDate,State]" \
  --output table

AMI ID: ami-1234567890abcdef0
Name: production-web-server
State: available

aws inspector2 start-on-demand-scan \
  --resource-id ami-1234567890abcdef0 \
  --resource-type AMI

aws ec2 describe-images \
  --image-ids ami-1234567890abcdef0 \
  --query "Images[].ScanResults" \
  --output json

The ScanResults property provides an overview of the vulnerability assessment.

The summary can include:

• HighestFindingSeverityLabel
• FindingScanDate
• InformationalFixAvailableSince
• LowFixAvailableSince
• MediumFixAvailableSince
• HighFixAvailableSince
• CriticalFixAvailableSince

For example, an image might return the following summary:

[
  {
    "HighestFindingSeverityLabel": "high",
    "FindingScanDate": "2026-11-04T08:30:00Z",
    "HighFixAvailableSince": "2026-11-02T10:00:00Z"
  }
]

This is illustrative output showing the structure of a scan summary.

The highest severity helps security teams understand the most serious vulnerability identified in the image.

However, the summary alone is not sufficient for remediation. You should retrieve the detailed findings before deciding whether the image is acceptable for deployment.

Step 4: Retrieve Detailed Vulnerability Findings

Use the get-image-findings command to retrieve individual vulnerability details.

aws ec2 get-image-findings \
  --image-id ami-1234567890abcdef0

The response can contain information such as:

{
  "ImageFindings": [
    {
      "Title": "CVE-2026-12345 - openssl",
      "SeverityLabel": "high",
      "Score": 7.5,
      "FixAvailable": true,
      "SnapshotId": "snap-1234567890abcdef0",
      "Paths": [
        "/usr/lib/libssl.so.3",
        "/usr/bin/openssl"
      ]
    }
  ]
}

The example illustrates how a finding can identify an affected package and its file locations.

Important properties include:

• Title: Identifies the vulnerability and affected package.
• SeverityLabel: Indicates the severity classification.
• Score: Provides the associated vulnerability score.
• FixAvailable: Indicates whether a fix is available.
• SnapshotId: Identifies the EBS snapshot associated with the finding.
• Paths: Shows affected file locations.

The API supports pagination. When the response contains a NextToken, pass it to the next request to retrieve additional findings.

This is important when scanning images with many vulnerabilities.

Step 5: Review Findings Before Approving the AMI

Not every vulnerability requires the same remediation priority.

A production approval process should evaluate severity, exploitability, available fixes, and application requirements.

For example:

Finding severity	Recommended action
Critical	Block deployment until reviewed and remediated
High	Prioritize remediation before production use
Medium	Evaluate application exposure and remediation options
Low	Review during regular security maintenance
Informational	Assess whether any action is required

These are example policy recommendations, not mandatory Amazon Inspector deployment rules.

A vulnerability with an available fix should generally be investigated before approving the image.

However, severity alone should not determine the final decision. Security teams should also consider whether the affected package is reachable, whether the vulnerability applies to the deployed configuration, and whether a safe remediation is available.

Integrating AMI Scanning Into a CI/CD Pipeline

Manual scanning is useful when working with a small number of machine images. However, organizations that build AMIs regularly should automate the scanning and approval process.

A typical deployment workflow can follow this sequence:

1. Build a custom AMI using an approved base image.
2. Install application dependencies and required security updates.
3. Create the AMI.
4. Initiate an Amazon Inspector on-demand scan.
5. Wait for scan results to become available.
6. Retrieve the vulnerability findings.
7. Evaluate the results against the organization's security policy.
8. Approve the AMI or send it back for remediation.
9. Deploy approved images to the target environment.

You can also use Amazon EC2 Allowed AMIs to control which machine images are permitted for use in an account. Its scan-result conditions can help enforce image selection policies based on available AMI scan results.

This provides an additional control beyond relying on developers to select approved images manually.

For reliable automation, the pipeline should distinguish between a scan that has not completed, a scan that failed, and a completed scan that contains unacceptable findings. An unavailable result should never be treated as a successful security check.

Common Mistakes When Scanning EC2 Machine Images

Assuming an accepted scan request means the image is clean

The scan API can accept a request before the assessment has completed.

Always retrieve the results and confirm that they are available before approving the AMI.

Ignoring vulnerabilities with available fixes

A vulnerability marked as high severity with an available fix should not be ignored simply because the application is currently functioning.

Review the affected package and update the image where appropriate.

Scanning an old AMI only once

A scan represents the findings available at a particular point in time.

New vulnerabilities may be discovered later. Continuous AMI scanning or periodic image reassessment can help maintain visibility.

Using the scan summary without reviewing individual findings

The highest severity label provides a quick overview, but it does not explain every affected package.

Review detailed findings to identify the actual remediation work.

Assuming image scanning replaces EC2 instance scanning

An AMI can be clean when created but become vulnerable after software updates or configuration changes.

Continue monitoring running EC2 instances with Amazon Inspector.

Advantages and Disadvantages of Amazon Inspector AMI Scanning

Advantages

• Identifies known software vulnerabilities before instance deployment.
• Supports both individual image scans and continuous monitoring.
• Provides severity classifications and remediation information.
• Integrates with AWS CLI and automated deployment workflows.
• Helps establish consistent security checks for reusable machine images.

Disadvantages

• Scanning introduces an additional step into the image deployment process.
• On-demand scanning requires explicit initiation and result verification.
• Scan findings represent known vulnerabilities and cannot guarantee that an image is completely secure.
• Vulnerability remediation may require rebuilding and retesting an image.
• Scanning incurs additional charges based on the selected scanning approach.

Best Practices for Production Environments

When introducing AMI scanning into production workflows, follow these practices:

1. Maintain approved golden images. Build application environments using centrally maintained and regularly updated base images.
2. Scan before deployment. Make vulnerability assessment part of the AMI approval process.
3. Define severity-based policies. Establish clear rules for critical, high, medium, and low findings.
4. Prioritize available fixes. Review vulnerabilities that have vendor-provided remediation options.
5. Automate image approval. Integrate scan initiation and result evaluation into CI/CD pipelines.
6. Reassess existing images. New vulnerability disclosures can affect images that previously passed security checks.
7. Monitor deployed instances. Use EC2 scanning to identify vulnerabilities introduced after launch.
8. Control image access. Use IAM permissions and Allowed AMIs to restrict which images teams can launch.
9. Track image ownership. Maintain AMI identifiers, creation dates, source images, and scan information.
10. Review scanning costs. Monitor on-demand and continuous scanning usage to keep security operations within budget.

Summary

Scanning EC2 machine images before launch helps organizations identify known software vulnerabilities before they become part of deployed infrastructure.

Amazon Inspector provides on-demand and continuous AMI scanning capabilities. Developers can initiate an individual scan using the AWS CLI, retrieve the scan summary through describe-images, and inspect individual vulnerabilities using get-image-findings.

For production environments, AMI scanning should be integrated into the image creation and approval process. Teams should define severity-based policies, prioritize available fixes, and prevent deployment when scan results are missing or violate security requirements.

Image scanning is one part of a broader cloud security strategy. Combining it with continuous EC2 monitoring, approved golden images, IAM controls, and automated deployment checks helps maintain a more consistent security posture across AWS environments.