はじめに
インフラエンジニアとしてSBOMに無関心だった過去
正直に言うと、半年前まで「SBOM（Software Bill of Materials）」という言葉すら聞いたことがありませんでした。
日々AWS上でECSやLambdaの運用、CI/CDパイプラインの整備、セキュリティグループの設計なんかに追われる中で、「SBOM？なにそれ、開発者が気にするやつでしょ？」と完全に他人事。そんなスタンスでした。
ある日、Slackの技術系チャンネルで「またLog4jの脆弱性…」「これSBOM出してると楽なのに」みたいな会話が流れてきました。
周りのエンジニアたちは、「Insoectorで対応していないのかね..」「うちはSyftで自動化してるよ」なんて話が上がっていました。
SBOM？Syft？……正直、何ひとつピンと来ていませんでした。
SBOM（Software Bill of Materials）を検索、
「なるほどインフラの話ではないのか..」
という甘い認識でいましたが、身近で何回かSBOMを耳にしているうちにインフラエンジニにも重要な話だと認識をあらためました。
なぜ今、SBOMが話題なのか？
脆弱性・規制・ゼロトラストが背景に
SBOMが注目されるようになった背景には、大きく3つの流れがあります。
- OSS脆弱性の多発
Log4j、Spring4Shell、curlなど、OSSに起因する深刻な脆弱性が頻発。
「何にどんなライブラリが使われてるか」を把握できていないと、対応が後手に回りがちです。 - 米国政府によるSBOM推進
2021年、バイデン政権が出した「サイバーセキュリティ強化に関する大統領令（EO 14028）」で、SBOMの提出がソフトウェアベンダーに義務付けられました。
この流れは民間にも波及しており、企業としてもSBOM整備は「やらなきゃまずい」テーマになりつつあります。 - ゼロトラスト時代の前提条件
ゼロトラストは「信頼しない」を前提とするセキュリティモデル。その中で、「自社が運用するソフトウェアの中身を明確にする」ことは、信頼を築く出発点でもあります。
以前の自分のように「SBOMって開発の話でしょ？」と思っているインフラエンジニアにこそ、今だからこそ知ってほしい。
本記事では、AWS環境を中心に、SBOMをどう取り入れていけばいいのか、実践ベースでお話していきます。
SBOMってそもそも何？
SBOMの定義と役割
SBOMとは「Software Bill of Materials」の略で、ソフトウェアに含まれるすべての部品（コンポーネント）のリストを表すものです。
例えるなら、アプリケーションが「料理」だとしたら、SBOMはその「レシピと食材一覧」のようなもの。
▶どんなOSSライブラリが使われているか
▶バージョンは何か
▶どの依存関係から導入されているか
などなど・・・
といった情報をSBOMとして出力することで、ソフトウェアの中身を可視化できます
これにより、「このライブラリに脆弱性が出たとき、うちのどのアプリが影響を受ける？」といった問いに即座に答えられるようになります。
SPDX、CycloneDX、CDXなど主要フォーマット
SBOMには複数の標準フォーマットがあります。代表的なものは以下の通りです。
| フォーマット名 | 特徴 |
|---|---|
| SPDX | Linux Foundationが中心。多くのライセンス情報に対応 |
| CycloneDX | OWASP発。セキュリティ特化。脆弱性管理との連携が得意 |
| CDX JSON | CycloneDXのJSON形式。ツールとの親和性が高い |
どれを使うかはプロジェクトやツール次第ですが、AWSやDevSecOps文脈では CycloneDX が使われることが多い印象です。
開発者だけの話じゃない！インフラ目線での重要性
最初は「これ開発チームの話でしょ？」と思っていました。でも実際は、インフラエンジニアがSBOMを理解していると助かる場面がめちゃくちゃ多いです。
例えば：
▶CI/CDパイプラインの中でSBOMを自動生成＆保存したい → インフラ側で設計が必要
▶脆弱性スキャンを自動で走らせたい → SBOMとセキュリティツールの連携が前提
▶ECRの中のコンテナイメージに何が入ってるか調べたい → SBOMあれば即確認可能
SBOMは、アプリの透明性を高めるだけでなく、セキュリティ対応のスピードと確実性を底上げする道具なんだと今は実感しています。
AWSにおけるSBOMの必要性
OSS使用が当たり前のクラウド時代
クラウドネイティブな開発では、OSS（オープンソースソフトウェア）の活用はもはや前提です。
ECSやLambdaで動かすアプリは、ベースとなるDockerイメージにAlpineやUbuntuが使われ、その中でpip installやnpm installされたOSSライブラリが大量に含まれています。
それらがどこから来たのか・どのバージョンか・何に依存しているのかを明確にしないまま運用していると、脆弱性が出たときに何も手が打てません。
クラウドの便利さと引き換えに、「中身がブラックボックス化しやすい」――これが今のAWS運用の現実です。
AWS環境でも「どこに」「何が」使われているかわかりづらい現実
以下のような事例があると考えます：
▶ECRに大量のイメージがあるが、中に何が含まれているかわからない
▶Lambda関数がZipデプロイされていて、依存パッケージの情報が確認できない
▶Infrastructure as Code (IaC)で立ち上げられた環境の中身がブラックボックス化している
このような状態で脆弱性が出た場合、「対象のコンポーネントを含むアプリがどれか」「本番で使っているのかどうか」すらすぐに判断できず、対応が遅れがちです。
万一の脆弱性対応時、SBOMがあるとどう違う？
ここでSBOMがあるとどうなるか？
▶どのアプリケーション（ECRイメージ・Lambdaパッケージ）に、脆弱なライブラリが含まれているか即座に判明
▶トリアージの優先度付け（本番か？影響あるか？）がスムーズに
▶レポートとしてセキュリティチームや上層部に提示できる
つまりSBOMは、「緊急時の確認作業を平常時に済ませておく」ための保険とも言える存在なんです。
以下は、AWS環境でSBOMが果たす役割をざっくり図解したものです
┌──────────────────────────┐
│ AWS環境（ECS / Lambda / ECR） │
└──────────────────────────┘
│
▼
┌──────────────────────────┐
│ 各アプリケーション / イメージ │
│ ─ Python / Node.js / Java etc. ─ │
└──────────────────────────┘
│
▼
┌──────────────────────────┐
│ SBOM（ライブラリ一覧 + バージョン） │
│ SPDX / CycloneDX / CDX etc. │
└──────────────────────────┘
│
┌──────┴───────┐
▼ ▼
脆弱性スキャン ライセンス確認
(Trivyなど) (コンプラ対応)
AWSとSBOM：どこでどう関わる？
どのフェーズでSBOMが必要？
インフラエンジニア視点で見ると、SBOMは主に以下のようなフェーズ・場所で活用されます：
▶ビルド時：アプリケーションの依存関係をもとにSBOMを生成（CodeBuild等）
▶デプロイ後：実際に動作する環境のSBOMを確認・監視（Amazon Inspector等）
▶脆弱性発覚時：SBOMをもとに影響範囲を即座に特定（Security Hub等と連携）
それでは、AWS上で具体的にどうSBOMを扱えるのか、代表的なユースケースを見ていきましょう。
Lambda や ECS/Fargate のイメージ確認方法
LambdaやFargateなど、マネージドで動く環境では中身の可視化が難しいですが、以下の方法でSBOM対応が可能です。
▶Lambda：デプロイ用のZipやイメージビルド時に、SBOMを生成・アーティファクトと一緒に保存
▶Fargate：コンテナイメージをビルドするCI/CD工程でSBOMを作成しておく
つまり「動かす前にSBOMを生成して持たせておく」という発想が重要になります。
CodeBuild / CodePipelineでSBOM自動生成する方法
CI/CD環境でSBOMを自動生成する例です：
yaml
phases:
install:
runtime-versions:
docker: 18
build:
commands:
- docker build -t myapp .
- syft myapp -o cyclonedx-json > sbom.json
artifacts:
files:
- sbom.jsonこうして出力された sbom.json を S3 に保管したり、Security Hub や自作の脆弱性通知Slack連携と組み合わせることで、運用面の効率化が可能になります。
Amazon Inspector によるSBOMの自動生成・エクスポート
2023年6月のアップデートで、Amazon Inspector は SBOM のエクスポートに正式対応しました！
対応ポイント：
▶CycloneDX または SPDX 形式で出力可能
▶ECR・EC2・Lambda 向けにSBOM生成
▶Amazon S3に自動保存（KMSで暗号化も可）
▶フィルタ機能で対象リソースを絞り込み可能
使えるフィルタ例：
▶AccountID
▶Lambda関数名 / タグ
▶ECRイメージタグ
▶EC2インスタンスタグ
▶リポジトリ名など
出力例のイメージ（JSON形式でS3に保存）：
{
"bomFormat": "CycloneDX",
"components": [
{ "name": "openssl", "version": "1.1.1" },
{ "name": "log4j", "version": "2.14.1" }
]
}Inspectorを使えば、ビルド済み・稼働中のリソースに対してもSBOMを後から確認可能というのが大きなメリットです。
AWS × SBOM = クラウドセキュリティの“見える化”
インフラエンジニアにとってのSBOMは、「セキュリティチームに丸投げせず、自分たちでも可視化できる手段」のひとつです。
AWSの各サービスやツールと組み合わせることで、SBOMは“実運用に耐えるセキュリティ基盤”として活用できるようになります。
次章では、実際にSBOMを導入・運用していく上での落とし穴とベストプラクティスについてまとめていきます。
SBOM導入時の落とし穴とベストプラクティス
落とし穴1：スキャン漏れが発生しやすい
SBOMを作成していても、下記のようなパターンで「一部だけ可視化されていない」ことがあります：
▶CIでビルドしたけど、本番に使ってるイメージは別だった
▶Lambda関数はZipデプロイで、依存情報が反映されていない
▶SBOM生成ツールが一部言語に未対応
🔧 ベストプラクティス
▶本番と同じビルド環境・イメージからSBOMを生成
▶multi-stage build の場合は、最終ステージで生成
▶Lambdaは、依存パッケージを展開するスクリプト内でSBOM出力
◆ 落とし穴2：作って終わり、になりがち
SBOMを生成して満足してしまい、その後使われない or 古くなるケースも多いです。
特に「S3に置いたけど誰も見てない」問題はありがちです。
🔧 ベストプラクティス
▶SBOM生成 → Slack通知やGitHub PRコメントで出力連携
▶セキュリティチームと連携して、定期スキャンレポートに活用
▶Security HubやInspectorでのSBOM活用をルール化（Ex: “週1でチェック”）
SBOMは便利な仕組みですが、「形式がバラバラ」「活用されない」「対象が抜けてる」といった“よくある落とし穴”をそのままにしておくと、効果を最大限発揮できません。
インフラエンジニアとしては、
▶一貫性のあるフォーマットの選定
▶生成対象の網羅性チェック
▶運用チームとの連携・仕組み化
といった観点でサポートすることで、SBOMの導入を“現場に根付かせる”役割を担うことができます。
まとめ
SBOMは、開発者だけのものではなく、インフラエンジニアにとっても「備え」として極めて重要な存在です。どのアプリにどんなOSSが使われているのか、万一の脆弱性発覚時に即座に対応できる体制が求められる今、SBOMは“セキュリティ対策の保険証”とも言えます。AWS環境においても、CodeBuildでの自動生成やAmazon InspectorによるSBOMエクスポートなど、すでに仕組みは整いつつあります。インフラ担当者こそ、それらの活用と運用設計に携わり、チーム全体の可視性と対応力を底上げする役割を担っていくべきでしょう。
