公開更新 10 人が閲覧（直近 30 日） AWS

AWSでSBOMを出力する手順｜Amazon InspectorのCycloneDX・SPDXエクスポートとSbomgen・料金【2026年10月】

AWSでSBOMを出力する手順｜Amazon InspectorのCycloneDX・SPDXエクスポートとSbomgen・料金【2026年10月】

AWSでSBOM（ソフトウェア部品表）を作る方法は、大きく2つに分かれます。1つは、Amazon Inspectorが監視しているEC2インスタンス・ECRコンテナイメージ・Lambda関数のパッケージ一覧をS3へ書き出す「SBOMエクスポート」。もう1つは、パイプラインでビルドした成果物やまだデプロイしていないイメージから、Amazon Inspector SBOM Generator（Sbomgen）でSBOMを生成する方法です。前者は稼働中の資産の棚卸し、後者は出荷前の成果物の検査に向いています。この記事では、両方の経路について出力フォーマットと実物のJSON、S3バケットとKMSキーのポリシー、AWS CLIで完了を待って取得するスクリプト、失敗時のエラーコード、GitHub Actionsでの組み込み、東京リージョンの料金までをコード付きで整理しました。SBOMという仕組みそのものの定義や作成・運用の考え方はSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説で、Inspectorのスキャン種類全体はAmazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断で扱っています。

まとめ：AWSでSBOMを出す2つの経路とAmazon Inspectorの使い分け

  • 稼働中のEC2・ECR・LambdaのSBOMは、InspectorのSBOMエクスポート（aws inspector2 create-sbom-export）でS3へ出力します。
  • 出力形式はCycloneDX 1.4とSPDX 2.3のJSONの2択で、仕様のバージョンは選べません（2026年10月時点のAPIリファレンスで確認）。
  • 事前にS3バケットポリシーと、カスタマー管理の対称KMSキー（バケットと同一リージョン）が必要です。
  • 失敗時はget-sbom-exportが返すerrorCodeの6値で原因を切り分けられます。
  • ビルド成果物やコンテナイメージのSBOMは、エクスポートではなくSbomgen（2026年10月時点の最新版は1.17.1）で作ります。GitHub Actionsには公式アクションがあります。
  • 料金表にSBOMエクスポート単体の課金項目はなく、費用はスキャン対象の課金とS3・KMSの実費です。

以下、それぞれの根拠と、コピーして動かせるコマンド・設定例を順に見ていきます。

AWSでSBOMを作る経路はInspectorのエクスポートとSbomgenの2つ

最初に、2つの経路の違いを表で押さえておきます。どちらもAmazon Inspectorの機能ですが、対象と出力先が異なります。

項目 SBOMエクスポート Sbomgen
対象 Inspector監視中のリソース イメージ・ディレクトリ等
実行場所 コンソール・API・CLI Linuxの手元・CIランナー
出力形式 CycloneDX 1.4／SPDX 2.3 CycloneDX
出力先 S3（KMS暗号化） ファイルまたは標準出力
主な用途 稼働資産の棚卸し 出荷前の成果物検査

InspectorはECRイメージスキャンやLambdaスキャン、EC2のエージェントレススキャンの内部でもSbomgenを呼んでいるとAmazon Inspector SBOM Generatorの公式ドキュメントに記載があります。つまり両者は同じ基盤技術で、違いは「AWSが監視しているものを書き出すか、自分で対象を指定して作るか」です。

出力できる形式はCycloneDX 1.4とSPDX 2.3のJSONの2択

SBOMエクスポートが対応するのはCycloneDX 1.4とSPDX 2.3の2形式で、いずれもJSONとしてS3バケットに書き出されます。CreateSbomExportのAPIリファレンスでreportFormatの有効値を確認すると、CYCLONEDX_1_4とSPDX_2_3の2つだけでした（2026年10月14日時点）。CycloneDXの仕様やSPDXの仕様にはこれより新しい版がありますが、CycloneDX 1.6やSPDX 3.0を要求されている場合、このエクスポートでは要件を満たせません。

S3に置かれるファイルは、指定した形式に応じてCyclonedx_1_4 (Json)またはSpdx_2_3-compatible (Json)という名前になります。CycloneDX形式の中身は次のような構造です（AWS公式ドキュメントのSBOMエクスポート解説の出力例から抜粋、コンポーネントは一部のみ）。

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "timestamp": "2023-06-02T01:17:46Z",
    "properties": [
      { "name": "architecture", "value": "arm64" },
      { "name": "accountId", "value": "111122223333" },
      { "name": "resourceType", "value": "AWS_ECR_CONTAINER_IMAGE" }
    ]
  },
  "components": [
    {
      "type": "library",
      "name": "pip",
      "purl": "pkg:pypi/[email protected]?path=usr/local/lib/python3.8/site-packages/pip-22.0.4.dist-info/METADATA",
      "bom-ref": "98dc550d1e9a0b24161daaa0d535c699"
    }
  ],
  "vulnerabilities": [
    { "id": "CVE-2022-40897", "affects": [ { "ref": "a74a4862cc654a2520ec56da0c81cdb3" } ] }
  ]
}

パッケージはpurl（Package URL）で識別され、検出済みの脆弱性はvulnerabilities配列にCVE IDと影響コンポーネントの参照で入ります。CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化で扱うCVE IDがそのままキーになるため、他ツールの検出結果とはこのIDで突合できる仕組みです。SPDX形式では同じ情報がpackagesとexternalRefsに分かれて入り、作成者欄には「Tool: Amazon Inspector SBOM Generator」が記録されます。ただしAWSはCreative Commons Zero（CC0）フィールドを意図的に含めていません。再配布や改変を許す表明をしないためで、SPDXの完全な仕様どおりの文書を期待して受け取り側のバリデータにかけると弾かれることがあります。

対象はEC2・ECR・Lambdaで、Windowsと未解決ハッシュに注意

対象はInspectorが継続的に監視しているリソースで、AWSドキュメント上はEC2インスタンス、ECRのコンテナイメージ、Lambda関数の3種類です。ECRにイメージを置く運用そのものはAmazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】で解説しています。監視下に入っているかどうかは、コンソールのカバレッジ画面で先に確かめておくと、後述のNO_FINDINGS_FOUNDを避けられます。

Windows環境の扱いは2026年に変わりました。AWSの公式ドキュメントは、2026年2月28日時点でエージェントレススキャンのEC2 Windowsインスタンスのエクスポートに対応したと記載しています。一方、エージェント（SSMエージェント）ベースのEC2 WindowsインスタンスのSBOMエクスポートは2026年10月時点でも非対応のままです。Windows資産を含む棚卸しを計画するときは、この対応差でスキャン方式を選ぶことになります。

もう1つ、バージョンレンジや動的参照で依存関係を書いているパッケージは、ハッシュやjarファイルが見つかっても特定の名前とバージョンに解決できません。Inspectorはこうした未解決ハッシュもコンポーネント一覧に含めて出力します。脆弱性スキャンの対象にはならないため、SBOMに名前の無いエントリが並んでいても欠陥ではなく、依存関係の書き方に起因する取りこぼしだと読み替えてください。

手順1：S3バケットポリシーとKMSキーポリシーを用意する前提設定

エクスポートを実行する前に、Inspectorが書き込めるS3バケットと、レポートを暗号化するためのKMSキーを用意します。KMSキーの条件は3つあり、カスタマー管理であること（AWS管理キーは不可）、対称暗号化キーであること、S3バケットと同じリージョンにあることです。findingsのレポートエクスポート用にバケットとキーを設定済みなら、同じものを流用できます。

バケットポリシーはfindingsレポートのエクスポート設定ドキュメントに雛形があります。東京リージョン向けに置き換えると次の形です。aws:SourceAccountとaws:SourceArnの条件で、自分のアカウントのInspectorレポートだけが書き込めるように絞っています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "allow-inspector",
      "Effect": "Allow",
      "Principal": { "Service": "inspector2.amazonaws.com" },
      "Action": ["s3:PutObject", "s3:PutObjectAcl", "s3:AbortMultipartUpload"],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "111122223333" },
        "ArnLike": { "aws:SourceArn": "arn:aws:inspector2:ap-northeast-1:111122223333:report/*" }
      }
    }
  ]
}

KMSキーのキーポリシーには、Inspectorのサービスプリンシパルにkms:Decryptとkms:GenerateDataKey*を許可するステートメントを追加します。既存のキーポリシーのStatement配列に足す1要素の例です。

{
  "Sid": "Allow Amazon Inspector to use the key",
  "Effect": "Allow",
  "Principal": { "Service": "inspector2.amazonaws.com" },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey*"],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:SourceAccount": "111122223333" },
    "ArnLike": { "aws:SourceArn": "arn:aws:inspector2:ap-northeast-1:111122223333:report/*" }
  }
}

手動で有効化するオプトインリージョン（中東のバーレーンなど）では、サービスプリンシパルをinspector2.me-south-1.amazonaws.comのようにリージョンコード付きに置き換える必要があります。東京リージョンは既定で有効なリージョンなので、上の例のままで問題ありません。組織全体のSBOMをまとめて出す場合は、Inspectorの委任管理者アカウントでサインインして実行します。フィルタを付けなければ、メンバーアカウントを含む有効な全リソースが対象です。

手順2：AWS CLIでcreate-sbom-exportを実行しS3へ出力する

CLIの実行コマンドとget-sbom-exportでのステータス確認

AWS CLIからはaws inspector2 create-sbom-exportを実行します。必須パラメータはreportFormatとs3Destinationの2つで、s3Destinationにはバケット名とKMSキーARNを必ず、キープレフィックスは任意で渡します。

# SBOMエクスポートを開始する（東京リージョンの例）
aws inspector2 create-sbom-export \
  --report-format CYCLONEDX_1_4 \
  --s3-destination bucketName=amzn-s3-demo-bucket,keyPrefix=sbom/,kmsKeyArn=arn:aws:kms:ap-northeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \
  --region ap-northeast-1

# 返ってきた reportId で進捗と結果を確認する
aws inspector2 get-sbom-export --report-id REPORT_ID --region ap-northeast-1

# 実行中のものを止める
aws inspector2 cancel-sbom-export --report-id REPORT_ID --region ap-northeast-1

GetSbomExportのAPIリファレンスによると、返るstatusはIN_PROGRESS、SUCCEEDED、CANCELLED、FAILEDの4値です。AWS Security Blogは完了までの所要時間を、対象アーティファクト数に応じて3〜5分としています。コンソールから実行する場合は、リージョンを選んだうえでナビゲーションペインの「Export SBOMs」を開き、形式・S3 URI・KMSキーを指定します。手順そのものはCLIと同じ内容を画面で埋める形です。

完了を待ってS3からSBOMを取得・確認するシェルスクリプトの実装例

定期的に棚卸しを回すなら、開始から取得までを1本のスクリプトにまとめておくと手作業が残りません。次の例は、エクスポートを開始してreportIdを受け取り、30秒ごとに状態を確認して、成功したらS3から手元へ取得し、失敗したらerrorCodeとerrorMessageを表示して終了します。

#!/usr/bin/env bash
set -euo pipefail
REGION=ap-northeast-1
BUCKET=amzn-s3-demo-bucket
PREFIX=sbom/$(date +%Y%m%d)/
KMS_ARN=arn:aws:kms:ap-northeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

REPORT_ID=$(aws inspector2 create-sbom-export \
  --report-format CYCLONEDX_1_4 \
  --s3-destination bucketName=${BUCKET},keyPrefix=${PREFIX},kmsKeyArn=${KMS_ARN} \
  --region "$REGION" --query reportId --output text)
echo "reportId=${REPORT_ID}"

while true; do
  STATUS=$(aws inspector2 get-sbom-export --report-id "$REPORT_ID" \
    --region "$REGION" --query status --output text)
  echo "status=${STATUS}"
  case "$STATUS" in
    SUCCEEDED) break ;;
    FAILED|CANCELLED)
      aws inspector2 get-sbom-export --report-id "$REPORT_ID" \
        --region "$REGION" --query '[errorCode,errorMessage]' --output text
      exit 1 ;;
  esac
  sleep 30
done

# 取得にはKMSキーの kms:Decrypt 権限が実行ユーザー側にも要る
aws s3 cp "s3://${BUCKET}/${PREFIX}" ./sbom/ --recursive --region "$REGION"

S3上のファイルはKMSキーで暗号化されているため、ダウンロードする側のIAMロールにもキーのkms:Decrypt権限が必要です。Inspector用のキーポリシーだけを書いて、取得する人の権限を忘れるケースがよくあります。取得したCycloneDXファイルは、jqで中身をすぐ確かめられます。

# コンポーネント名とpurlを一覧にする
jq -r '.components[] | [.name, .purl] | @tsv' sbom/*.json | head

# 検出済みの脆弱性（CVE）の件数と一覧
jq '.vulnerabilities | length' sbom/*.json
jq -r '.vulnerabilities[].id' sbom/*.json | sort -u

失敗したときにerrorCodeの6値で原因を切り分ける手順と対処

FAILEDになったときはerrorCodeを見ます。APIが返す値は6種類に決まっており、原因の切り分けはここで大半が済みます。

  • BUCKET_NOT_FOUND：S3バケットが存在しない
  • INCOMPATIBLE_BUCKET_REGION：バケットのリージョンが不一致
  • MALFORMED_KMS_KEY：KMSキーARNの形式・種別が不正
  • INVALID_PERMISSIONS：バケット／キーポリシーの許可不足
  • NO_FINDINGS_FOUND：条件に合う対象リソースが無い
  • INTERNAL_ERROR：Inspector側の内部エラー

最初の3つは設定ミスで、MALFORMED_KMS_KEYはAWS管理キーや非対称キーを指定したときにも出ます。INVALID_PERMISSIONSは手順1のポリシーの書き漏らし、とくにaws:SourceArnのリージョンをus-east-1のまま写した場合に起きがちです。NO_FINDINGS_FOUNDはフィルタの絞りすぎか、そもそも対象リソースがInspectorの監視下に入っていないケースにあたります。INTERNAL_ERRORは時間をおいて再実行してください。エラーが返らずコマンド自体が400になる場合はリクエストのバリデーション違反なので、パラメータ名と値を先に疑います。

8種類のフィルタでアカウントやリソース単位に出力対象を絞り込む

フィルタを指定しない場合は有効な全リソースが対象になります。絞り込みに使えるのは、アカウントID、EC2インスタンスのタグ、Lambda関数名、イメージタグ、Lambda関数のタグ、リソースタイプ、リソースID、リポジトリ名の8種類です。比較演算子は文字列フィルタがEQUALSとNOT_EQUALSの2つ、EC2インスタンスタグとLambda関数タグのフィルタはEQUALSのみで、findingsのフィルタで使えるPREFIXはSBOMエクスポートでは受け付けません。

# ECRのコンテナイメージだけを対象にする例（--resource-filter-criteria）
aws inspector2 create-sbom-export \
  --report-format SPDX_2_3 \
  --s3-destination bucketName=amzn-s3-demo-bucket,keyPrefix=sbom/ecr/,kmsKeyArn=arn:aws:kms:ap-northeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \
  --resource-filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_ECR_CONTAINER_IMAGE"}]}' \
  --region ap-northeast-1

# 本番タグのEC2インスタンスだけを対象にする例
aws inspector2 create-sbom-export \
  --report-format CYCLONEDX_1_4 \
  --s3-destination bucketName=amzn-s3-demo-bucket,keyPrefix=sbom/ec2-prod/,kmsKeyArn=arn:aws:kms:ap-northeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \
  --resource-filter-criteria '{"ec2InstanceTags":[{"comparison":"EQUALS","key":"env","value":"prod"}]}' \
  --region ap-northeast-1

本番と検証が同居しているアカウントでは、EC2インスタンスタグで環境単位に分けてエクスポートすると、後段の分析でレポートが混ざりません。リソースタイプごとにSBOMの構造が異なる点も、分けて出す理由になります（後述のAthenaの章を参照）。

手順3：ビルド成果物のSBOMをSbomgenとGitHub Actionsで作る

Sbomgen 1.17系のインストールとコンテナ・ディレクトリのSBOM生成

エクスポートはあくまで「Inspectorが監視している稼働中リソース」の棚卸しです。パイプラインでビルドしたイメージや、まだデプロイしていない成果物のSBOMは、Sbomgenで作ります。Sbomgenのバージョン一覧では、2026年10月14日時点の最新版は1.17系（1.17.1）でした。この記事の旧版を書いた8月時点は1.15.2だったので、2か月で5回更新されています。版を固定したいCIでは、一覧に載っているバージョン付きのURLとSHA-256チェックサムを使うのが安全です。

SbomgenはLinux専用で、AWSは4コアCPU・8GBメモリ以上の環境を推奨しています。収集できるのはAlpine APK、Debian/Ubuntu DPKG、Red Hat RPM、Homebrew、C#、Go、Java、Node.js、PHP、Python、Ruby、Rustの12種類のパッケージです（旧版の記事時点ではHomebrewを含まない11種類でした）。生成対象はコンテナイメージ、ディレクトリ、アーカイブ、マウントしたボリューム、ローカルシステム、コンパイル済みのGo・Rustバイナリに対応します。

# 最新版をダウンロードして展開（Linux AMD64）
curl -sSLO https://amazon-inspector-sbomgen.s3.amazonaws.com/latest/linux/amd64/inspector-sbomgen.zip
unzip inspector-sbomgen.zip
# 展開されたディレクトリへ移動してから以降を実行する
sha256sum < inspector-sbomgen   # checksums.txt の値と照合する
chmod +x inspector-sbomgen

# コンテナイメージからSBOMを生成
./inspector-sbomgen container --image alpine:latest -o /tmp/sbom.json

# プロジェクトディレクトリから生成
./inspector-sbomgen directory --path /path/to/dir -o /tmp/sbom.json

# 生成と同時に Inspector Scan API で脆弱性判定まで行う
./inspector-sbomgen container --image alpine:latest \
  --scan-sbom \
  --aws-region ap-northeast-1 \
  --scan-sbom-output-format cyclonedx \
  --outfile /tmp/inspector_scan.json

zipには実行ファイルのほか、変更履歴のWhatsNew.txt、チェックサムのchecksums.txt、Sbomgen自身のSBOMであるsbom.jsonが同梱されています。Sbomgenが出すのはCycloneDX形式なので、SPDXで受け取りたい相手がいる場合は変換ツールを別途挟みます。

GitHub ActionsでInspectorのスキャンとSBOM出力を組み込む

GitHub Actionsには、AWSが公開しているAmazon Inspector用の脆弱性スキャンアクションがあります。内部でSbomgenを実行してSBOMを作り、Inspector Scan APIに渡して結果をJSON・CSV・Markdownで出力する仕組みです。artifact_typeにはrepository・container・binary・archiveの4つを指定できます。ビルドしたイメージを検査し、SBOMを成果物として残す最小構成は次のとおりです。

name: sbom-and-scan
on: [push]
permissions:
  id-token: write   # OIDCでAWSに認証する
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t app:latest .
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ap-northeast-1
          role-to-assume: ${{ secrets.INSPECTOR_ROLE_ARN }}
      - name: Inspector scan
        id: inspector
        uses: aws-actions/vulnerability-scan-github-action-for-amazon-inspector@v1
        with:
          artifact_type: container
          artifact_path: app:latest
          output_sbom_path: ./sbom.json
          display_vulnerability_findings: enabled
          critical_threshold: 1
          high_threshold: 1
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: ./sbom.json
      - name: Fail if threshold exceeded
        run: exit ${{ steps.inspector.outputs.vulnerability_threshold_exceeded }}

output_sbom_pathを指定しない場合も、SBOMはsbom_<run_id>.jsonという名前で作られます。sbomgen_versionの既定値はlatestなので、版を固定したい場合はここに明示します。引き受けるIAMロールには、Inspector Scan APIのScanSbomを呼び出す権限を付けてください。GitHub Actions以外では、InspectorのCI/CD連携ドキュメントがJenkins・TeamCityのプラグイン、CodePipeline・CodeCatalystのアクション、GitLabのコンポーネントを案内しています。いずれもビルドステップでSbomgenを走らせてScan APIに渡す流れは共通です。CI/CDでの脆弱性検査をOSSで組む選択肢としては、Trivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定まで【v0.74対応】も比較対象になります。

Scan APIの5,000パッケージ上限とDockerfileチェックの対象

--scan-sbomやGitHub ActionsでInspector Scan APIへ送る場合、パッケージ数が5,000を超えるSBOMは処理されずHTTP 400が返ります。巨大なモノリシックイメージをそのまま投げると失敗するため、イメージ自体を分割するか、対象を絞る運用が必要です。ログや画像などの大きなファイルは、スキャン時間とメモリを抑える目的で--skip-filesにより除外できます。

SbomgenはDockerfileチェックで設定不備も検出でき、sudoバイナリの同梱、Debian APTユーティリティの使い方、ハードコードされたシークレット、rootコンテナ、実行時にセキュリティを弱めるコマンドフラグと環境変数が対象になります。NODE_TLS_REJECT_UNAUTHORIZED=0やcurl --insecureのような、レビューで見落とされがちな記述が引っかかります。2026年10月時点では、CIS Docker Benchmarkの評価（--enable-cis-docker）とFIPS関連の暗号設定の記録（--enable-fips-checks）も試験機能として追加されており、どちらも既定では無効です。

出力したSBOMをAthenaとjqで分析するときの権限とスキーマの注意

数件のSBOMなら前述のjqで足ります。S3に溜まったSBOMを横断で見たい場合は、AWS Security Blogの手順どおりAmazon Athenaでクエリを書くか、QuickSightでダッシュボード化して読む形が一般的です。同ブログはGlueクローラでテーブルを作る流れを示していますが、ここに引っかかりやすい点が2つあります。

1つは復号権限です。SBOMはKMSキーで暗号化されているため、GlueクローラのIAMロールをKMSキーポリシー側にも追加しないと、クローラがS3のデータを読めません。もう1つはスキーマで、生成されるSBOMの構造はEC2・Lambda・ECRでそれぞれ異なります。全リソースをまとめて1つのテーブルに載せる前提でクエリを書くと崩れるので、リソースタイプでフィルタしてエクスポートを分けるか、テーブルを分ける設計にしてください。

クローラをスケジュール実行にしておけば、新しいレポートが追加されるたびにカタログが追随します。なお同ブログはS3 Selectでの単発確認にも触れていますが、S3 Selectは新規のお客様への提供が終了しているため、これから始めるならS3からファイルをダウンロードするかAthenaに寄せる判断になります。手順2のスクリプトで日付付きのプレフィックスに出しておくと、Athena側でも日付単位のパーティションとして扱えて便利です。

Amazon Inspectorの東京リージョン料金とSBOMエクスポートの課金

Amazon Inspectorの料金ページを確認すると、SBOMエクスポートという課金項目そのものは存在しません。かかるのはInspectorのスキャン課金と、出力先のS3ストレージ・KMSの利用料です。東京リージョンの単価をAWSのPrice List API（2026年9月11日公開分、USD）で取得すると次のとおりで、旧版記事の7月時点から単価は変わっていませんでした。

課金対象 東京リージョン単価
EC2 継続スキャン（エージェント） $0.0021 / インスタンス時間
EC2 エージェントレススキャン $0.00289 / インスタンス時間
EC2 CIS Benchmark評価 $0.03 / 回・インスタンス
ECR 初回スキャン（push時） $0.11 / イメージ
ECR 自動再スキャン $0.01 / 回
Lambda 標準スキャン $0.0005 / 関数時間
Lambda コードスキャン $0.0009 / 関数時間
オンデマンド・CI/CDスキャン $0.03 / イメージ
コードセキュリティ $0.18 / スキャン種別ごと
SBOMエクスポート 課金項目なし

月額に直すと、エージェント方式のEC2は1インスタンスあたり約1.5ドル、エージェントレスは約2.1ドル、Lambda標準スキャンは1関数あたり約0.36ドルです（いずれも720時間換算）。コードセキュリティはSAST・SCA・IaCのスキャン種別ごとに課金されます。料金ページの注記では、SBOMを入力にしてScan APIで脆弱性判定を受ける場合も、CI/CDスキャンと同じ1イメージ0.03ドルが適用されます。つまりSbomgenで作るだけなら無料、Scan APIに渡すと課金という切り分けです。

Inspectorを新規に有効化したアカウントには15日間の無料トライアルがあり、CI/CDのオンデマンドスキャンはアカウントごとに25イメージ分が一度だけ無料になります。2026年10月時点ではMicrosoft AzureのVM・ACR・Function Appsのスキャンにも対応し、Azure側には別枠で30日間のトライアルが設定されています。単価は改定されるため、見積もり時は必ず公式の料金ページで最新値を確認してください。

Inspectorのエクスポートで足りる場面と別ツールを選ぶべき場面

この機能は「AWS上で今動いているものの部品表を、運用側が自分たちのために出す」用途に向けて作られています。採用してよい条件と、見送る場面を表にまとめました。

状況 判断
稼働中AWS資産の棚卸し エクスポートを採用
CIで出荷前に検査したい Sbomgen・公式アクション
納品・提出用のSBOM 別ツールを併用
CycloneDX 1.6等が必須 別ツールを併用
オンプレ・他クラウド込み 別ツールで一元化

納品用・提出用のSBOMを求められている場合は不向きです。CycloneDX 1.4とSPDX 2.3に固定されており、SPDX出力はCC0フィールドを欠くうえ、供給者名や作成者情報といった取引先が求める項目を自由に埋められません。2026年7月29日に公表された国際ガイダンス「2026 ソフトウェア部品表（SBOM）の最小要素」のように要求項目は更新されていくため、提出要件がある案件では出力項目の充足を1つずつ突き合わせる必要があります。国内外の規制が求める範囲はSBOM義務化の現在地｜経済産業省の手引とEU CRAが課す期限と対応範囲で、生成・管理ツールの選び方はSBOMツールの比較と選び方｜生成・管理・SCAのタイプ別に選定基準を解説で整理しています。

開発リポジトリの依存関係を追いたい場合も、エクスポートの担当ではありません。ただしInspector自体が守備範囲外というわけではなく、Amazon Inspector Code Securityが自社ソースコード・サードパーティ依存関係・IaCのスキャンを担います（東京リージョンで1スキャン種別あたり$0.18）。注意点は、その結果をSBOMとしてエクスポートする経路が用意されていないことです。リポジトリ起点でSBOMが要るならSbomgenのdirectoryサブコマンドか、GitHub Actionsのartifact_type: repositoryで作ります。ツール選定の観点はSCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説にまとめました。

オンプレミスや他クラウドの資産、Inspectorが監視していないリソースも当然含まれません（AzureはスキャンこそできるもののSBOMエクスポートのフィルタはEC2・ECR・Lambdaのみです）。またエクスポートはスナップショットであり、リアルタイムの構成監視でもありません。サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位で整理しているような攻撃起点をカバーしたいなら、SBOMの出力は入口にすぎず、脆弱性の突合と是正の運用まで設計して初めて意味を持ちます。

結論として、AWS中心の構成で「今動いているもの」を把握したいならInspectorのエクスポートを週次などで定期実行し、CIではSbomgen（公式アクション）で出荷前に検査する、という2段構えが運用負荷と網羅性の釣り合う形です。S3・KMSのポリシー設計やCIへの組み込みを含め、AWS環境の構築から相談したい場合は一創のインフラ構築（AWS・Google Cloud・Azure）でお手伝いしています。

よくある質問

Amazon InspectorのSBOMエクスポートに追加料金はかかりますか？

Inspectorの料金表にSBOMエクスポートの課金項目はありません。発生するのは対象リソースのスキャン料金と、出力先S3のストレージ料金、KMSの利用料です。SbomgenのSBOMをScan APIに渡して脆弱性判定を受ける場合は、1イメージあたり0.03ドルがかかります。

AWSでSBOMを作るにはどの方法を選べばよいですか？

稼働中のEC2・ECRイメージ・Lambda関数ならInspectorのSBOMエクスポート、ビルド中の成果物やリポジトリならSbomgen（GitHub Actionsでは公式アクション）を選びます。前者はS3にまとめて出力され、後者はCIの中でファイルとして生成される点が違います。

CycloneDX 1.6やSPDX 3.0で出力できますか？

できません。APIが受け付けるのはCYCLONEDX_1_4とSPDX_2_3の2値のみです（2026年10月時点）。新しい仕様版が必須の要件では、別のSBOM生成ツールを併用してください。

Windows EC2インスタンスのSBOMは出せますか？

エージェントレススキャンのWindowsインスタンスは2026年2月28日以降エクスポートできます。エージェントベースのWindowsインスタンスは2026年10月時点でも非対応です。

エクスポートが失敗したときはどこを見ればよいですか？

aws inspector2 get-sbom-exportのerrorCodeとerrorMessageです。バケット不在、リージョン不一致、KMSキーの不正、権限不足、対象なし、内部エラーの6種類に分かれており、設定ミスの大半はこの値で特定できます。権限不足のときは、バケットポリシーとキーポリシーのaws:SourceArnのリージョンを最初に確かめてください。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.28　テックブログ リンツ不正アクセス：314万件の対象確認とパスワード強制リセット後の対処
  2. 2026.10.29　テックブログ ソニー生命の不正アクセス：38.5万件の対象確認と窓口、停止中の手続き
  3. 2026.10.27　テックブログ Brotli 脆弱性：CVE-2026-111497の影響確認とNode.js・Python・.NETの更新手順
  4. 2026.01.30　コラム 税務調査は個人と法人で何が違う？担当部署・件数・調べられる点と追徴税額を比較【令和6事務年度】
  5. 2026.09.26　コラム 価格転嫁とは？価格交渉促進月間の調査に回答義務はあるか・取適法の協議記録まで

RELATED POSTS 関連記事

一覧へ戻る

目次