Amazon InspectorのSBOMエクスポート手順｜CycloneDX・SPDX出力とCI/CD連携・料金

Amazon Inspectorは、監視対象のEC2インスタンス・ECRコンテナイメージ・Lambda関数について、そこに入っているパッケージの一覧をSBOMとしてS3へ書き出せます。ただし出せるのは「Inspectorが実際にスキャンしているAWSリソース」に限られます。ビルド前のソースや、まだデプロイしていない成果物は同じ機能では扱えません。ここでは出力フォーマットと実物のJSON、S3とKMSの前提、AWS CLIの実コマンド、失敗時に見るべきエラーコード、CI/CDで作る場合の代替手段、そして東京リージョンの実料金までを順に整理します。SBOMという仕組みそのものの定義や作成・運用の考え方はSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説で扱っています。

まとめ

• 出力形式はCycloneDX 1.4とSPDX 2.3のJSONの2択で、バージョンは選べません。
• 事前にS3バケットポリシーと、カスタマー管理の対称KMSキー（バケットと同一リージョン）が必要です。
• AWS CLIならaws inspector2 create-sbom-exportの1コマンドで開始し、get-sbom-exportで進捗を見ます。完了までの目安は3〜5分。
• 失敗時はerrorCodeの6値で原因が切り分きます。
• ビルド成果物やコンテナイメージのSBOMは、エクスポートではなくSbomgen（inspector-sbomgen 1.15.2）で作ります。
• Inspectorの料金表にSBOMエクスポート単体の課金項目はなく、費用はスキャン対象の課金とS3・KMSの実費です。

以下、それぞれの根拠と実際のコマンドを見ていきます。

Amazon Inspectorのエクスポートで出力できる範囲

対応フォーマットと実際に出力されるJSON

Amazon Inspectorが対応するのはCycloneDX 1.4とSPDX 2.3の2形式で、いずれもJSONとしてS3バケットに書き出されます。APIのreportFormatが受け付ける値はCYCLONEDX_1_4とSPDX_2_3の2つだけで、AWS SDKのサービスモデル（botocore 1.42.97）で確認しても列挙値はこの2つです。CycloneDX 1.6やSPDX 3.0を要求されている場合、このエクスポートでは要件を満たせません。

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

{
  "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に分かれて入りますが、AWSはCreative Commons Zero（CC0）フィールドを意図的に含めていません。再配布や改変を許す表明をしないためで、SPDXの完全な仕様どおりの文書を期待して受け取り側のバリデータにかけると弾かれることがあります。

対象リソースとWindows・未解決ハッシュの扱い

対象はInspectorが継続的に監視しているリソースで、AWSドキュメント上はEC2インスタンス、ECRのコンテナイメージ、Lambda関数の3種類です。Windows環境の扱いは2026年に変わりました。AWSの公式ドキュメントは2026年2月28日時点でエージェントレススキャンのEC2 Windowsインスタンスのエクスポートに対応したと記載しています。一方、エージェント（SSMエージェント）ベースのEC2 WindowsインスタンスのSBOMエクスポートは現在も非対応です。Windows資産を含む棚卸しを計画するときは、この対応差でスキャン方式を選ぶことになります。

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

S3バケットとKMSキーの前提設定

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

組織全体のSBOMをまとめて出す場合は、Inspectorの委任管理者アカウントでサインインして実行します。フィルタを付けなければ、メンバーアカウントを含む有効な全リソースが対象になります。

AWS CLIとコンソールでのエクスポート手順

CLIでの実行とステータス確認

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

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

失敗したときに読むエラーコード

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

最初の3つは設定ミス、INVALID_PERMISSIONSはポリシーの書き漏らし、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インスタンスタグで環境単位に分けてエクスポートすると、後段の分析でレポートが混ざりません。

CI/CDでビルド成果物のSBOMを作る場合

Sbomgenの導入と実行

エクスポートはあくまで「Inspectorが監視している稼働中リソース」の棚卸しです。パイプラインでビルドしたイメージや、まだデプロイしていない成果物のSBOMは、Amazon Inspector SBOM Generator（Sbomgen）で作ります。最新版は1.15.2で、Linux専用、AWSは4コアCPU・8GBメモリ以上の環境を推奨しています。収集できるのはAlpine APK、Debian/Ubuntu DPKG、Red Hat RPM、C#、Go、Java、Node.js、PHP、Python、Ruby、Rustの11種類のパッケージです。

# コンテナイメージから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

Sbomgenが出すのはCycloneDX形式です。ECRイメージスキャン、Lambda関数スキャン、EC2のエージェントレススキャンでもInspectorは内部でSbomgenを呼んでおり、手元で動かすバイナリは同じ基盤技術を使っています。

スキャン連携の制約とDockerfileチェック

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

プラグイン形式で提供されているCI/CDはGitHub Actions、Jenkins、TeamCityの3つです。AWSのマネージドサービス側では、CodePipelineとCodeCatalystがInspector Scanのアクションとして、GitLabはコンポーネントとして連携できます。いずれもビルドステップでSbomgenを走らせてScan APIに渡す流れです。SbomgenはDockerfileの設定不備も検出でき、sudoバイナリの同梱、Debian APTユーティリティの使い方、ハードコードされたシークレット、rootコンテナ、実行時にセキュリティを弱めるコマンドフラグと環境変数が対象になります。NODE_TLS_REJECT_UNAUTHORIZED=0やcurl --insecureのような、レビューで見落とされがちな記述が引っかかります。CI/CDでの脆弱性検査全般についてはTrivy（トリビー）とは｜使い方・インストール・読み方の入門ガイド【2026】も併せて検討材料になります。

出力したSBOMをAthenaで分析するときの注意

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に寄せる判断になります。

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

Amazon Inspectorの料金表を確認すると、SBOMエクスポートという課金項目そのものは存在しません。かかるのはInspectorのスキャン課金と、出力先のS3ストレージ・KMSの利用料です。東京リージョンの単価は次のとおりです（AWSの料金データ2026年7月7日公開分、USD）。

月額に直すと、エージェント方式のEC2は1インスタンスあたり約1.5ドル、エージェントレスは約2.1ドル、Lambda標準スキャンは1関数あたり約0.36ドルです（いずれも720時間換算）。Inspectorを新規に有効化したアカウントには15日間の無料トライアルがあり、CI/CDのオンデマンドスキャンはアカウントごとに25イメージ分が一度だけ無料になります。単価は改定されるため、見積もり時は必ず公式の料金ページで最新値を確認してください。

Inspectorのエクスポートで足りない場面

この機能は「AWS上で今動いているものの部品表を、運用側が自分たちのために出す」用途に向けて作られています。逆に言うと、次のケースでは選ぶべきではありません。

納品用・提出用のSBOMを求められている場合は不向きです。CycloneDX 1.4とSPDX 2.3に固定されており、SPDX出力はCC0フィールドを欠くうえ、供給者名や作成者情報といった取引先が求める項目を自由に埋められません。2026年7月29日に公表された国際ガイダンス「2026 ソフトウェア部品表（SBOM）の最小要素」のように要求項目は更新されていくため、提出要件がある案件では出力項目の充足を1つずつ突き合わせる必要があります。

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

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

よくある質問

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

Inspectorの料金表にSBOMエクスポートの課金項目はありません。発生するのは対象リソースのスキャン料金と、出力先S3のストレージ料金、KMSの利用料です。

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

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

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

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

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

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

CI/CDのビルド成果物のSBOMはどう作りますか？

Amazon Inspector SBOM Generator（inspector-sbomgen、最新版1.15.2）をパイプラインに組み込みます。GitHub Actions、Jenkins、TeamCityにはプラグインが提供されており、CodePipeline・CodeCatalyst・GitLabからも連携できます。生成したSBOMをInspector Scan APIへ渡せば脆弱性レポートまで作れます。

関連記事

• SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説
• SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説
• Trivy（トリビー）とは｜使い方・インストール・読み方の入門ガイド【2026】
• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位を解説