SBOM
SBOM自動化
SBOM自動化とは、誰かがバージョンをスプレッドシートに書き写すことなく、すべてのビルドが自らのソフトウェア部品表を生成することです。複数の製品にわたってコンポーネントを手作業で整理している場合、その一覧は次のリリースまでに古くなり、製品が増えるたびに作業も増えていきます。
更新日
手作業のSBOMが破綻する理由
- 次のビルドで古くなる。依存関係はリリースのたびに変わりますが、スプレッドシートが更新されるのは誰かが思い出したときだけです。
- 人の目に見える範囲で止まる。直接の依存関係は簡単に一覧にできます。その下にある推移的依存関係はそうはいかず、手作業で追える人はいません。
- 増殖する。複数の製品にそれぞれ複数のサポート対象バージョンがあれば、ファイルは数十にもなり、それぞれに別の担当者と、別の「正解」があることになります。
- 肝心の問いに答えられない。新たな脆弱性が見つかったとき、そのパッケージがどのリリースに含まれているかを知る必要があります。スプレッドシートの詰まったフォルダを検索するのは時間がかかり、その答えも信頼できません。
- 他者が求める形式ではない。顧客やツールは、CycloneDXやSPDXのような機械可読な形式を期待しています。顧客からのSBOM要求への対応方法をご覧ください。
優れたSBOM自動化が行うこと
- すべてのビルドでSBOMを生成する。誰かが何かを実行したり覚えておいたりする必要はありません。
- ツリー全体をカバーする。推移的依存関係を含め、あらゆる階層を対象にします。
- 各SBOMを1つのビルドに結び付ける。どのファイルがどのリリースを記述しているかが分かります。
- 見えなかったものを明示する。不完全な一覧を完全なものとして示すことはしません。
- 標準形式でエクスポートする。SBOMが次のツールでも、次の顧客にも通用します。
- 出荷したものを監視し続ける。月曜日には問題のなかったリリースが、火曜日には影響を受けることがあるためです。
SBOMを管理する3つの方法の比較
| 問い | スプレッドシート | CI内のスキャナー | ビルド中に記録 |
|---|---|---|---|
| いつ更新されるか？ | 誰かが思い出したとき | スキャンステップの実行時 | すべてのビルドで |
| データの出どころは？ | 人 | ロックファイルまたは完成した出力 | ビルドが実際に取り込んだもの |
| 推移的依存関係は？ | ほとんど含まれない | 特定できるもののみ | あらゆる階層で |
| インストールスクリプトによるダウンロードなどの隠れた依存関係は？ | なし | 見落とす | 記録される |
| CIキャッシュから復元されたパッケージは？ | なし | ツールによる | 記録され、キャッシュ由来と明示 |
| 脆弱性の監視は？ | 手作業 | 通常は別ツール | CRACIに組み込み |
スキャナーによる自動化はスプレッドシートから大きく前進しますが、それでも何が含まれたかを推測していることに変わりはありません。その理由については、ビルドが信頼できる情報源である理由をご覧ください。
スプレッドシートはどうなるか
コンポーネントのデータは移行されます。バージョンとパッケージはビルドから得られるため、誰かが入力する必要はありません。残るのは、どの製品があり、誰が担当し、どのバージョンがまだサポート対象かといった、チームだけが持つ知識です。人が時間をかける価値があるのは、その部分です。
CRACIでの対応
CRACIはGitHubホステッドランナーを、より高速で低コストなランナーに置き換え、各ビルドの実行中にSBOMを記録します。runs-on: craciを設定するだけで、実行結果はこれまでどおりGitHubに表示されます。標準的なビルドでは、設定なしで完全なSBOMが得られます。独自のパッケージレジストリや特殊なコンテナ構成を持つビルドでは、多少の設定が必要な場合があります。
- スキャンではなく記録。CRACIは各ビルドに入ってくる通信を把握するため、ロックファイルベースのツールが見落とす隠れた依存関係も捕捉します。SBOMのすべてのコンポーネントは、実際にビルドに含まれていたものです。
- すべてのジョブに完全性の状態。ビルドを完全に記録できなかった場合に、それとその理由が分かります。
- CycloneDXとSPDXでのエクスポート。推移的依存関係と、コンポーネントで見つかった脆弱性も含まれます。
- 製品をまたいだ一元的なビュー。インベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかが分かり、CRACIは監視対象のSBOMを再評価し続けます。
パイプラインの異なる複数のチームに展開するには、エンジニアリングチーム横断のSBOM生成をご覧ください。
SBOM自動化に関するよくあるご質問
SBOM自動化とは何ですか？
ソフトウェア部品表をビルドの一部として生成し、誰も手作業で作成しなくても、すべてのリリースにSBOMが付くようにすることです。より優れた仕組みでは、リリースの出荷後も各SBOMを新たな脆弱性について監視します。
SBOMをExcelで管理し続けることはできますか？
スプレッドシートは最初のインベントリとしては機能しますが、最新の状態を保つのが難しく、推移的依存関係までは届きません。また、標準的なSBOM形式でもありません。顧客やセキュリティツールは一般にCycloneDXまたはSPDXを期待しており、Cyber Resilience Actは広く使われている機械可読な形式を求めています。
SBOM自動化には、すべてのパイプラインに新しいステップが必要ですか？
ほとんどのジェネレーターでは必要です。各ワークフローにステップを追加し、それを最新に保つ必要があります。CRACIはランナー内でSBOMを記録するため、ジョブに追加するステップはありません。
CRACIはどのエコシステムを記録しますか？
npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、DebianとUbuntuのパッケージ（apt）、Alpineのパッケージ（apk）、Gitソースに加え、YoctoとOpenEmbeddedのダウンロードを記録します。MavenとJavaはロードマップに掲載されています。
CRACIはどのCIシステムとプラットフォームに対応していますか？
現在はGitHub Actionsに対応しており、その他のCIシステムはロードマップに掲載されています。ランナーは現在Linux x86-64とARM64で、WindowsとmacOSはロードマップに掲載されています。
ベンダーから購入したコンポーネントはどうなりますか？
ベンダーのSBOMをCRACIに追加できるため、購入したコンポーネントも自社のビルドと並べて監視されます。
費用はいくらですか？
CRACIが課金するのはビルド時間のみです。1vCPU分あたり$0.002（デフォルトの2 vCPUランナーでは$0.004）を秒単位で計測し、月額料金もSBOMごとの課金もありません。