急速に進化を遂げる今日のデジタル環境では、ソフトウェアサプライチェーンにおけるアプリケーション・セキュリティの重要性がかつてないほど高まっています。アップストリームの依存関係をソフトウェアに統合するには、透明性とセキュリティ対策が必須ですが、その実装と管理は思った以上に複雑です。そこで、今回のテーマであるソフトウェア部品表（SBOM）の出番となります。
SBOM（Software Bill of Materials）、日本語でソフトウェア部品表は、ソフトウェアの構成部品を包括的にリスト化したもので、開発ライフサイクル全体で使用されるライブラリ、ツール、プロセスの複雑な関係性を明確にします。また、脆弱性管理ツールと組み合わせることで、ソフトウェア製品に潜在する脆弱性を明らかにするだけでなく、戦略的リスク軽減も可能にします。本ガイドは、SBOMの重要な役割、DevSecOps戦略におけるその中心的位置付け、そしてアプリケーションのSBOM健全性を向上させるための戦略について深く掘り下げます。そして、潜在的脅威に満ちた環境における組織のサイバーセキュリティ体制を強化することを目的としています。
目次
- SBOMとは？
- SBOMが重要な理由
- SBOMデータ交換標準フォーマットの種類
- SBOMとソフトウェアの脆弱性管理を組み合わせるメリット
- Gitlabと動的なSBOM
- SBOMの生成と管理の拡大
- SBOMの統合とインジェスト
- SBOMの健全性を他持つための対策を迅速に行うには
- 継続的なSBOM分析
- SBOMの信頼構築
- Gitlab SBOM機能の今後の進化
- SBOMを始めましょう
- SBOMに関するFAQ
- SBOMとは？
- なぜSBOMは重要なのですか？
- SBOMのデータ交換に使用される標準フォーマットは何ですか？
- SBOMに対するGitLabのアプローチはどのようなものですか？
- SBOMを組織に導入するにはどうすれば良いですか？
SBOMとは？
SBOMとは、ソフトウェアを作るために使用されたコンポーネントをリスト化（外部サイト）したものです。コンポーネント間の関係性も階層的に示します。このリストには、ソフトウェア・アーティファクトの開発、構築、およびデプロイに使用されるライブラリ、ツール、およびプロセスに関する重要情報も含まれます。
SBOMの概念は10年以上前から存在しています。しかし、米国ホワイトハウスが2023年に発表した国家サイバー戦略を実施する一環として、CISA（米国土安全保障省の外局機関「サイバーセキュリティー・インフラセキュリティー庁」）の「セキュア・バイ・デザイン（Secure by Design）（外部サイト）」フレームワークはソフトウェアメーカーに対して、この原則を採用、サイバーセキュリティを製品に統合するよう促しています。加えて同政府は、公共部門に販売するアプリケーションデベロッパーにソフトウェア・パッケージに SBOM を含めるよう促すベストプラクティスも発表しました。民間企業もこれに追随し、SBOMは普及への道を進んでいます。また日本でも、同年度に「ソフトウェア管理に向けたSBOM導入に関する手引（外部サイト）」が経済産業省により作成されました。
SBOMは専用のソフトウェアで個別に作成されることが多いものの、GitLabのようなプラットフォーム型のソリューションでは、DevSecOpsワークフローの初期段階からSBOMの生成が完全に組み込まれており、重要な役割を果たすようにしています。
SBOMが重要な理由
現代のソフトウェア開発は、より迅速かつ効率的な方法でアプリケーションをリリースすることに注力しています。そのためデベロッパーは、オープンソースのリポジトリやプロプライエタリ（専有）パッケージのコードをアプリケーションに組み込むことがあります。Synopsys社が発行した「2024年度オープンソースセキュリティおよびリスク分析レポート」によると、2023年に17の業界にわたる1,000以上の商用コードベースを分析した結果、コードベース全体の96%にオープンソースが含まれ、リスク評価されたコードベースの84%に脆弱性が含まれていたことが明らかになりました。
未知のリポジトリを使用することは、ハッカーに悪用される脆弱性を含むコードを取り込む可能性を高めます。実際、2020年のSolarWinds社への攻撃（外部サイト）は、彼らのOrion製品で使用されているパッケージに、悪意のあるコードが仕込まれており、これが実行されたことに端を発しています。この事件では、ソフトウェアサプライチェーン全体の顧客が重大な影響を受けました。また、多くの商用ソフトウェアベンダーに影響を与えたlog4jの脆弱性を含むその他の攻撃は、ソフトウェアサプライチェーン全体のリスクを評価できるよう、コンテナやインフラを含むアプリケーションの依存関係を綿密調査する必要性を確固たるものとしました。
さらに、ソフトウェアのセキュリティ脆弱性を発見し修正するにはコストがかかることも、SBOMの必要性が高まっている理由の一つであり、同時にソフトウェアのサプライチェーン攻撃が企業の評判に与えるダメージも考慮すべき要素です。SBOMは依存関係の把握や、脆弱性や内部ポリシーに準拠していないライセンスの特定にも役立ちます。
SBOMデータ交換標準フォーマットの種類
SBOMは、名前、バージョン、パッケージャーなどの情報の生成と解釈が自動化されることで、最も効果的に活用できます。これには、すべての関係者が標準的なデータ交換フォーマットを使用することが重要です。現在使用されている主なSBOMデータ交換標準フォーマットには、次の2つの種類があります:
- OWASP CycloneDX（外部サイト）
- SPDX（外部サイト）
GitLabは、SBOMの生成にCycloneDXを使用しています。この標準フォーマットは指示的で使いやすく、複雑な関係を簡素化し、特定や将来のユースケースに対応できる拡張性を備えています。さらにcyclonedx-cli（外部サイト）やcdx2spdx（外部サイト）は、CycloneDXファイルを必要に応じてSPDXに変換するためのオープンソースツールとして利用可能です。
SBOMとソフトウェアの脆弱性管理を組み合わせるメリット
SBOMがDevSecOpsチームやソフトウェアの利用者にとって非常に有益な理由は次の通りです。
- アプリケーションに含まれる追加のソフトウェアコンポーネントとその宣言場所が標準的なアプローチで理解できるため
- アプリケーションの作成履歴を継続的に可視化し、サードパーティのコードの出所やホストリポジトリの詳細を含むため
- ファーストパーティによる開発コードと採用されたオープンソースソフトウェアの両方に対して、深いレベルでセキュリティの透明性を提供できるため
- SBOMが提供する詳細情報により、DevOpsチームが脆弱性を特定し、潜在的なリスクを評価し、それらを軽減することができるため
- アプリケーション購入者が昨今求めている透明性を提供できるため
Gitlabと動的なSBOM
SBOMを最大限活用するには、組織がSBOMを自動生成し、アプリケーションセキュリティスキャンツールと連携させ、脆弱性やライセンスをダッシュボードに統合することで内容を把握しやすくし、対応できるようにする必要があります。さらに、継続的に更新することが求められます。GitLabは、これらすべての要件をサポートしています。
SBOM生成と管理の拡大
オープンソース、サードパーティ、および専有ソフトウェアを網羅した正確で包括的なSBOMを所有することが、内部ポリシーや規制に準拠する上で重要です。そして、各コンポーネントや製品バージョンのSBOMを効果的に管理するには、SBOMの作成、統合、検証、承認を効率的に行うためのスムーズなプロセス確立が必須です。GitLabの依存関係リスト機能は、既知の脆弱性およびライセンスに関するデータを一元化されたユーザーインターフェース内で表示します。依存関係スキャンレポートの一部として依存関係グラフ情報も生成され、ユーザーは個々のプロジェクトや複数のプロジェクトにわたる依存関係やリスクに関する包括的なインサイトを得ることができます。また、CIパイプライン内でJSON形式のCycloneDXアーティファクトの生成が可能です。このAPIは、SBOM生成において、より柔軟でカスタマイズ可能なアプローチを提供します。さらにSBOMは、UIや特定のパイプライン、プロジェクト、またはGitLab APIを通じてエクスポートすることができます。
SBOMの統合とインジェスト
GitLabは、サードパーティのSBOMを取り込むことができ、サードパーティによる開発コードと採用されたオープンソースソフトウェアの両方に対して、深いレベルでセキュリティの透明性を提供します。。GitlabのCI/CDジョブを使うことで、複数のCycloneDX SBOMをシームレスに統合し、1つのSBOMにまとめることもできます。
各SBOMのCycloneDXメタデータに含まれるビルドやロックファイルの場所などの実装固有の詳細を使用し、統合ファイルから重複情報が削除されます。またこのデータは、SBOM内のコンポーネントに対するライセンス情報および脆弱性情報が追加されることで自動的に強化されます。
SBOMの健全性を保つための対策を迅速に行うには
高品質な製品を迅速に構築するには、対策可能なセキュリティ上の問題を検出し、デベロッパーがその中で最も影響の大きい脆弱性に対処できるようにする必要があります。GitLabはソースコード、コンテナ、依存関係、実行中アプリケーションにおける脆弱性をスキャンすることで、サプライチェーンのセキュリティを強化します。また、静的アプリケーションセキュリティテスト（SAST）、動的アプリケーションセキュリティテスト（DAST）、コンテナスキャン、ソフトウェア構成分析（SCA）機能など、さまざまなセキュリティスキャン機能を提供し、進化する脅威ベクトルに対し、全方位的な防御を実現します。GitLabのAI搭載機能「GitLab Duo脆弱性の説明」は、デベロッパーやセキュリティエンジニアが脆弱性をより理解し効率的に修正できるようサポートします。具体的には、特定の脆弱性に関する説明、その悪用可能性、そしてこれが最重要ですが、修正方法の提案を行います。「GitLab Duo 脆弱性の修正」と組み合わせることで、DevSecOpsチームはたった数回のクリックで脆弱性を特定、分析、修正することができます。
また、本プラットフォームは、新たに検出された脆弱性に基づいて、新しいポリシーの作成やコンプライアンスの強制もサポートしています。
継続的なSBOM分析
GitLabの継続的な脆弱性スキャンは、パイプラインの実行に関わらず、コンテナスキャン、依存関係スキャン、またはその両方が有効になっている全プロジェクトにに対してスキャンをトリガーします。新しい共通脆弱性識別子（CVE）が米国国立脆弱性データベース（NVD）に報告された場合、ユーザーが最新フィードを取得するためにパイプラインを再実行する必要はありません。
GitLabの脆弱性調査チームが、GitLabのアドバイザリ・データベースにそれらの脆弱性情報を追加し、自動的にGitLabに脆弱性として報告されます。このように、最新の情報がリアルタイムで更新される仕組みから、GitLabのSBOMが本質的に動的であることが分かります。
SBOMに対する信頼構築
コンプライアンス機能を必要とする組織は、GitLab Runnerによって生成されたすべてのビルドアーティファクトの証明書を作成できます。このプロセスでは、GitLab Runner内で証明書を生成します。データを外部サービスに引き渡すことないため、安全です。
Gitlab SBOM機能の今後の進化
大手ソフトウェアベンダーやオープンソースソフトウェアエコシステムを狙った集中的な攻撃が頻繁に発生しているため、ソフトウェアサプライチェーンのセキュリティは、サイバーセキュリティおよびソフトウェア業界において引き続き重要なトピックとなっています。確かにSBOM業界は急速に進化していますが、SBOMの生成方法、生成頻度、保存場所、分析方法、複雑なアプリケーション向けに複数SBOMを統合する方法、アプリケーションの健全性向上に際した活用方法等に関して、依然として懸念があります。
GitLabはSBOMを、ソフトウェアサプライチェーン戦略になくてはならないものと位置付け、新機能追加の計画を含め、DevSecOpsプラットフォーム内でSBOM関連機能の強化を継続しています。最近の改善点には、証明の自動化、ビルドアーティファクトのデジタル署名、外部で自動生成されたSBOMのサポートが含まれます。
また、GitLabはプラットフォーム内に堅牢なSBOM成熟度モデルを確立しており、これには自動SBOM生成、開発環境からのSBOM取得、アーティファクトのSBOM分析、SBOMのデジタル署名の推奨といったステップが含まれています。さらに今後のリリースでは、ビルドアーティファクトの自動デジタル署名機能も追加する予定です。
SBOMを始めましょう
SBOMの需要は既に高まっています。政府機関はソフトウェアベンダー、連邦政府のソフトウェアデベロッパー、さらにはオープンソースコミュニティに対して、SBOM作成を推奨または義務付けるになってきています。
これら要件を先取りするなら、Gitlab DevSecOpsプラットフォームで提供されている
GitLab Ultimate向けSBOM機能をご確認ください。
SBOMの基礎知識まとめとFAQ
SBOMとは？
SBOMとはソフトウェア部品表のことであり、ソフトウェアの作成、ビルド、デプロイに使用されたすべてのコンポーネント、ライブラリ、ツールを一覧にして詳しく記載したものです。この包括的なリストは単なる一覧にとどまらず、コードの起源に関する重要な情報も含み、アプリケーションの構成や潜在的脆弱性をより深く理解するのに役立ちます。
なぜSBOMは重要なのですか？
SBOMが重要な理由は次の通りです。
- 依存関係のインサイト: ソフトウェアの構成要素を理解することで、サードパーティ製コンポーネントに関連するリスクを特定し、軽減できます。
- セキュリティの強化: アプリケーションコンポーネントにの詳細を把握し、脆弱性を迅速に特定し、適切な対策を講じることができます。
- 規制遵守: 規制やベストプラクティスにより、特に公共部門向けのソフトウェアパッケージに対して、SBOMが推奨または義務化されつつあります。
- 開発の効率化: デベロッパーが、使用されているライブラリやコンポーネントに関するインサイトをSBOMから得ることで、開発サイクルの時間を節約し、エラーを減らすことができます。
SBOMのデータ交換に使用される標準フォーマットは何ですか？
主なフォーマットは次の2つです。
- CycloneDX: ソフトウェアコンポーネントとサポート間の複雑な関係を簡素化してくれるため、その使いやすさで知られており、特定のユースケースににも柔軟に対応します。
- SPDX: SBOMデータ交換のために、広く使われているもう一つのフレームワーク。ソフトウェア環境内のコンポーネントに関する詳細情報を提供します。
GitLabはSBOMの生成にCycloneDXを採用しています。指示的でありながらも柔軟に拡張可能であり、将来にわたって使い続けられるためです。
SBOMに対するGitLabのアプローチはどのようなものですか？
GitLabは動的なSBOMの作成として次の点を重視しています。
- 自動生成: ソフトウェアの構成に関する最新情報が常に反映されること
- ツールとの統合: リスク評価を徹底的に実施するために、脆弱性スキャンツールと連携すること
- 簡単な管理: SBOMの取り込みや統合をサポートし、包括的な分析が可能なこと
- 継続的な分析: プロジェクトを継続的にスキャンし、新たに発生する脆弱性を検出すること
SBOMを組織に導入するにはどうすれば良いですか？
SBOMの導入を検討している組織向けに、GitLab Ultimateがあります。このパッケージは、DevSecOpsワークフロー内でSBOMの生成と管理を行うための強力なプラットフォームを提供します。GitLabのツールを活用することで、チームはコンプライアンスの確保、セキュリティの強化、開発プロセスの最適化を実現できます。
SBOMへの需要が高まっている背景には、ソフトウェアのセキュリティとサプライチェーンの整合性への関心が増していることが挙げられます。SBOM機能を統合することで、組織は脆弱性に対する保護を強化し、新しい規制にも確実に対応できるようになります。
GitLab Ultimateを30日間無料でお試しください。
免責事項: このブログには、今後の製品、機能、および機能性に関する情報が含まれています。本ブログの情報はあくまで参考情報であり、購入やプランニングの際に情報の正確性を保証するものではありません。本ブログやリンクされたページに記載されている内容は、変更や未更新の可能性があります。製品、性能、および機能の開発、リリース、タイミングについては、予告なく内容を変更または削除する場合があります。
監修：川瀬 洋平 @ykawase
（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）
