Generating and exporting a software bill of materials in AWS

Every AWS environment eventually asks the same question: what's actually running in production, and what's inside it? Answering that at scale is the job of a software bill of materials, and AWS SBOM generation has become the fastest way to get a reliable answer without building tooling from scratch. Amazon Inspector can now generate and export SBOMs directly for EC2 instances, Lambda functions, and container images, giving security and platform teams a native starting point instead of a patchwork of scripts.

This guide walks through a practical, repeatable process for AWS SBOM generation: scoping what to cover, generating SBOMs with Amazon Inspector, exporting them for container images in Amazon ECR, storing and versioning the output, validating the format, and wiring the whole thing into CI/CD so it runs without anyone remembering to trigger it. By the end, you'll have a working pipeline that produces a software bill of materials AWS auditors, customers, and your own engineers can actually use.

Step 1: Plan Your AWS SBOM Generation Workflow

Before running any commands, decide what "coverage" means for your organization. AWS SBOM generation typically spans three resource types:

• Container images stored in Amazon ECR (and images running in ECS/EKS)
• EC2 instances, including the OS packages and installed software
• Lambda functions, including function layers and dependencies

Pick a target format up front — CycloneDX or SPDX are the two Amazon Inspector supports natively. If you're feeding SBOMs into a vulnerability management pipeline or a customer-facing trust portal, CycloneDX 1.4/1.5 tends to have broader tooling support today, but SPDX is often required for compliance frameworks that reference it explicitly. Whichever you choose, standardize it across teams — mixed formats create reconciliation headaches later.

Also decide where exports will live. A dedicated S3 bucket with versioning and server-side encryption enabled is the standard pattern, and it's the destination Inspector's export API expects anyway.

Step 2: Enable Amazon Inspector and Required Permissions

Amazon Inspector needs to be activated in each account/region where you want SBOM coverage, and the calling role needs export permissions.

aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA \
  --region us-east-1

Attach an IAM policy granting the SBOM export actions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "inspector2:CreateSbomExport",
        "inspector2:GetSbomExport"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetBucketLocation"],
      "Resource": [
        "arn:aws:s3:::your-sbom-export-bucket",
        "arn:aws:s3:::your-sbom-export-bucket/*"
      ]
    }
  ]
}

If you're exporting to a KMS-encrypted bucket, also grant kms:GenerateDataKey and kms:Decrypt on the relevant key — this is the step most people miss and the one that produces the most confusing error messages later.

Step 3: Run an Inspector SBOM Export

With Inspector enabled, kick off an export job. This is the core AWS SBOM generation call — it's asynchronous, so you request an export and then poll for the result.

aws inspector2 create-sbom-export \
  --report-format CYCLONEDX_1_4 \
  --s3-destination bucketName=your-sbom-export-bucket,keyPrefix=sboms/,kmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/abcd-1234 \
  --resource-filter-criteria '{
    "resourceType": [{"comparison": "EQUALS", "value": "AWS_EC2_INSTANCE"}]
  }'

The command returns a reportId. Check status with:

aws inspector2 get-sbom-export --report-id <report-id>

Once status shows SUCCEEDED, the SBOM lands in your S3 destination as a compressed JSON document. This same Inspector SBOM export mechanism is what you'll reuse for container images and Lambda functions — only the resourceFilterCriteria changes.

Step 4: Export an SBOM Amazon ECR Image

Container images are usually the highest-value target, since they carry the most third-party dependencies per deployable unit. To scope the export to a specific repository or tag, adjust the filter criteria:

aws inspector2 create-sbom-export \
  --report-format SPDX_2_3 \
  --s3-destination bucketName=your-sbom-export-bucket,keyPrefix=sboms/ecr/ \
  --resource-filter-criteria '{
    "ecrImageRepositoryName": [{"comparison": "EQUALS", "value": "payments-service"}],
    "ecrImageTags": [{"comparison": "EQUALS", "value": "latest"}]
  }'

For an SBOM Amazon ECR export to succeed, the image must already have been scanned by Inspector at least once — Inspector generates the SBOM from its own scan results rather than re-pulling and re-analyzing the image on demand. If you push new images frequently, trigger the export as a step after the scan completes rather than immediately after push.

Step 5: Store, Version, and Tag Exported SBOMs

Treat SBOMs like build artifacts, not throwaway logs. Enable S3 versioning on the destination bucket so historical SBOMs remain retrievable for audits or incident retrospectives:

aws s3api put-bucket-versioning \
  --bucket your-sbom-export-bucket \
  --versioning-configuration Status=Enabled

Use a consistent key prefix scheme that encodes resource type, name, and image digest or instance ID — for example sboms/ecr/payments-service/sha256-<digest>.json. This makes it trivial to answer "what was in production on this date" months later without cross-referencing separate logs. A lifecycle policy that transitions older SBOMs to Glacier after 90 days keeps storage costs down while preserving compliance retention.

Step 6: Validate Format and Scan for Known Vulnerabilities

Before trusting an exported SBOM, verify it parses correctly and reflects reality. A quick sanity check with a CycloneDX validator:

pip install cyclonedx-python-lib
cyclonedx validate --input-file sbom.json --input-format json

Then cross-reference the component list against a vulnerability database — either Inspector's own findings (since it generated the SBOM from a scan) or an independent scanner like Grype:

grype sbom:./sbom.json

Running an independent scan matters because it catches drift: if Inspector's scan is stale or a dependency was added after the last scan window, a second tool comparing against a fresher CVE feed will surface it.

Step 7: Automate the Pipeline

Manual exports don't scale past a handful of images. Wire SBOM generation into your existing pipeline using EventBridge to trigger on ECR push events, or add a CodePipeline stage after image build:

{
  "source": ["aws.ecr"],
  "detail-type": ["ECR Image Action"],
  "detail": {
    "action-type": ["PUSH"],
    "result": ["SUCCESS"]
  }
}

Point this rule at a Lambda function that calls create-sbom-export with the pushed repository/tag, waits for the Inspector scan to complete, and then triggers the export. This closes the loop so every image that reaches ECR automatically produces a software bill of materials AWS teams can query without manual intervention.

Troubleshooting and Verification

Export stuck in IN_PROGRESS: Inspector needs the underlying resource scan to finish first. Check aws inspector2 batch-get-account-status to confirm scanning is active, and confirm the image or instance has completed at least one full scan cycle — new resources can take several minutes.

AccessDeniedException on export: Almost always a missing KMS permission on the destination bucket's key, not a missing Inspector permission. Verify the calling role has kms:GenerateDataKey.

Empty or near-empty SBOM: Usually means the resource type wasn't actually enabled for scanning (e.g., Lambda scanning is a separate toggle from EC2/ECR), or the filter criteria matched zero resources. Re-run with broader filters to confirm resources are visible to Inspector at all.

Format mismatches downstream: If a downstream tool rejects the file, confirm the --report-format matches what that tool expects — CycloneDX and SPDX are not interchangeable, and version differences (1.4 vs 1.5, SPDX 2.2 vs 2.3) can break strict parsers.

Verifying completeness: Spot-check a known dependency — pick a library you know is in the image (e.g., a specific version of OpenSSL or a core npm package) and confirm it appears in the exported SBOM with the correct version. If it's missing, the scan likely ran against a cached or older image layer.

How Safeguard Helps

Native AWS SBOM generation is a strong foundation, but most organizations run workloads across more than one cloud, plus on-prem build systems, plus third-party vendor software that never touches Inspector at all. Safeguard sits on top of that reality: it aggregates SBOMs generated by Inspector, CI/CD pipelines, and vendor attestations into a single normalized inventory, regardless of source format.

Safeguard automatically reconciles CycloneDX and SPDX documents, deduplicates components across overlapping exports, and continuously matches every SBOM against live vulnerability and license data — so a new CVE disclosure surfaces immediately across every affected image, instance, and function, not just the ones you remember to re-scan. For compliance teams, Safeguard turns the raw export files this guide produces into audit-ready evidence: version history, provenance, and attestation status in one place, mapped to the frameworks you're actually being assessed against. If AWS SBOM generation is your starting point, Safeguard is what makes that data operationally useful at scale.