サイバーセキュリティの実践の進歩により、最新のソフトウェア パッケージはこれまで以上に安全になっています。ただし、最先端の脅威にも直面しており、安全であると同時に脆弱でもあります。サプライチェーン攻撃など ソーラーワインド そして次のような深刻な脆弱性 ログ4シェル これらは、今日ソフトウェア システムが直面している最新の脅威の 1 つです。このようなソフトウェア サプライ チェーン攻撃は、その効果が動的であり、直接制御できないシステムの脆弱性を悪用するため、対処がより困難になります。
ただし、このようなソフトウェア サプライ チェーン攻撃に対抗するための最初のステップは、ソフトウェアに含まれるパッケージ、依存関係、コンポーネントについて明確な知識を持つことです。このため、ビルドのソフトウェア部品表 (SBOM) を生成することが重要です。 SBOM は、ソフトウェア サプライ チェーンの脆弱性の可視性を高めるだけでなく、コンプライアンスの目的でも重要になっています。 SBOM の生成は、最近の規則によって義務付けられました。 米国連邦政府が発行した大統領令 サイバーセキュリティを強化し、ソフトウェア パッケージで使用されるサードパーティ コンポーネントの信頼性を保証します。
によると、 ガートナー 予測によれば、重要なインフラストラクチャ ソフトウェアの開発を担当する組織の 60% は、2025 年までに標準化された SBOM を必要とするでしょう。SBOM の作成は、組織の標準と目標に合致するツールを選択することから始まり、ソフトウェア ビルド ライフサイクルのどのフェーズでどの段階で SBOM を構築するかを決定します。 SBOM を適用し、それが形式に準拠していることを確認し、脆弱性スキャンを実行します。 SBOM の生成は繊細で複雑なプロセスです。この記事では、SBOM の生成が必要な場合と、ソフトウェア用に SBOM を生成する方法について説明します。
ソフトウェア部品表をいつ作成するか
ソフトウェア部品表 (SBOM) の生成は、ソフトウェア ビルドだけでなくソフトウェア サプライ チェーン全体を保護するために不可欠です。 SBOM の生成は、ソフトウェアのビルド プロセスのさまざまな段階に統合できます。ビルド時、実行時、またはソフトウェアのフォレンジック中にソース コードを使用して部品表を生成できます。これらすべてのうち、専門家はビルド時に SBOM を生成することを推奨しています。これは、ビルド時の SBOM ジェネレーターがより正確で、より完全な依存関係のリストを生成するためです。ただし、これが常に現実的であるとは限らないため、SBOM は DevOps ライフサイクルの他の時点でも生成できます。
使用する SBOM 生成ツールのタイプは、DevOps ライフサイクルのどの段階で SBOM ドキュメントが生成されるかによって異なることに注意してください。以下に、ビルド ライフサイクル中に SBOM を生成できるさまざまな段階を示します。各期間には異なる利点とトレードオフがあります。生成する SBOM データの対象ユーザーとユースケースを理解し、最適な結果が得られるアプローチを選択することが最善です。
ソースコードの段階で
アーティファクトと、マニフェスト、メタデータ、ロック ファイルなどの関連ソースを調べることにより、ソース ツールまたはバイナリ ツールはソース コードの段階でソフトウェア部品表を生成します。この段階では、ソフトウェア コンポーネント分析またはソフトウェアのバイナリ分析を実行できます。
SCA (ソフトウェア コンポーネント分析) ツールは、ソフトウェアとそのマニフェスト ファイルを分析してそのコンポーネントを特定するように設計されています。一方、バイナリ分析ツールは、ソフトウェアのメタデータを分析し、アーティファクト情報を構築して SBOM を生成します。この段階で使用される分析ツールの例には、CycloneDX、It-Depends、Fossa、AppSonar、Cybellum、Black Duck、Fortress などがあります。
脆弱性アナライザーとソース コード段階で生成された SBOM を併用すると、構築中のソフトウェアの脆弱性警告を早期に受け取ることができます。ただし、この段階で生成される SBOM には制限があります。まず、依存関係を含むビルド中に生成された情報が欠落していることが多いため、完全ではありません。さらに、最終的に展開される製品では使用されなかったコンポーネントに関する情報が含まれる場合があります。
ビルド時
ビルド システムを利用するツールを使用してビルド時に SBOM を作成すると、推移的依存関係や固定されていない依存関係など、バイナリに何が入るのかについて最も正確な情報が得られます。これをサポートしているのは、 ソフトウェア サプライヤーの SBOM の作成と提供に関する NTIA の調査.
NTIA は、新しいコンポーネントのリリースごとに SBOM を作成することを推奨しています。これは、ソフトウェアの新しいバージョンを更新またはリリースするたびに新しい SBOM を作成することを意味します。また、サプライヤーは、以前の SBOM に間違いを発見したり、以前に文書化されていなかったソフトウェア コンポーネントに関する新しい情報を知ったりした場合にも、新しい SBOM を作成する必要があります。
ビルド時に SBOM を生成するには、ソフトウェアを構築するネイティブ環境で動作するプラグインを使用する必要があります。ほとんどの開発環境には、依存関係管理システムと統合して SBOM を自動的に生成するプラグインがあります。ビルド時 SBOM ジェネレーターの例には、SPDX、CycloneDX Maven プラグイン、OWASP のDependency-Track-Check などがあります。
ビルド時 SBOM ジェネレーターは最も包括的で正確ですが、他の方法と比べてセットアップが難しくなります。また、この方法は一部のビルド システムでは機能せず、レガシー製品ではこの方法を使用できません。
実行時に SBOM を生成する
実行時に動作する SBOM ジェネレーターは、ソフトウェア、アプリ サーバー、またはプラグインが実行時に使用するライブラリをキャプチャするように設計されています。このタイプのジェネレーターは、ソフトウェアによって呼び出されるすべてのサービスと、ソフトウェアがアクセスするポートおよびアクティブなライブラリの詳細も示します。ただし、この SBOM 生成方法は広く普及していません。また、この方法を使用して生成されたデータを元の SBOM ドキュメントとマージするための明確なワークフローはありません。 ジボム および 脅威マッパー は、ランタイム SBOM ジェネレーターの例です。
ソフトウェア部品表を作成する方法: ステップバイステップ ガイド
ソフトウェア部品表を手動で生成することは、開発者にとって時間がかかり、面倒な作業です。この方法でソフトウェア プログラムのすべてのコンポーネントをリストすることは、ほとんどの場合非現実的です。ただし、現在では、このプロセスを簡素化する多数の SBOM 生成ツールが利用可能です。これを行う方法は、組織の標準と、開発ライフサイクル中にいつ SBOM を生成するかによって異なります。
SBOM ワークフローをソフトウェア ビルド パイプラインに統合することで、SBOM プロセスを自動化できます。 Scribe プラットフォーム は、ソフトウェア部品表の作成方法を簡素化するツールの 1 つです。 Scribe を使用すると、SBOM を 1 か所から管理および共有できます。このようにして、ソフトウェア コンポーネントの整合性を検証し、ソフトウェア パイプラインの脆弱性をシームレスに追跡できます。このセクションは、Scribe を使用してソフトウェア部品表を生成するためのステップバイステップのガイドです。
ステップ 1: Scribe Trust Hub に登録してログインします。
始める前に、Scribe プラットフォームにはブラウザからアクセスできる Web インターフェイス (Scribe Trust Hub) があることを知っておく必要があります。ただし、Scribe 証拠コレクターは Linux および Mac デバイスでのみ実行されます。 Scribe を使用して整合性レポートと SBOM を生成するには、プロジェクトのビルド スクリプトを変更し、プロジェクトを Scribe に接続するために必要な関連コード スニペットを追加する権限が必要です。 Scribe はコンテナ イメージを生成する任意のプログラミング言語で記述されたプロジェクトの SBOM を生成できますが、現在のリリースは Node.js プロジェクトでのみ機能することに注意してください。
Scribe をプロジェクトに統合するための最初のステップは、Scribe Trust Hub に登録することです。登録してログインしたら、「製品」タブに移動し、「セットアップ」をクリックします。 Scribe のこのページにはデモ製品があり、これを操作してプラットフォームとその仕組みを理解することができます。
ステップ 2: Scribe Trust Hub を統合する
次のステップは、Scribe をプロジェクトの継続的インテグレーション パイプラインに接続することです。これにより、SBOM 生成プロセスが自動化されます。通常、Scribe Trust Hub のコード スニペットを CI パイプライン上の 2 つのポイントに追加できます。コードは、ソース コード チェックアウトまたは最終ビルド イメージに配置できます。最初のオプションは推奨されますが強制ではありませんが、2 番目のオプションは必須です。
Scribe の CI セットアップは現在、Kubernetes および GitHub Actions 上の Jenkins に対してのみ機能します。これらの CI セットアップに Scribe を統合するプロセスは同様です。開始するには、Scribe Hub 製品設定ページで次の認証情報を取得する必要があります。
- プロダクトキー
- 顧客ID
- クライアントの秘密
プロダクト キーは製品ごとに異なりますが、クライアント資格情報はアカウントに固有です。
Jenkins の CI 統合のセットアップ
Jenkins の CI 統合をセットアップするには、チェックアウト ポイントまたは Docker イメージの作成後に、「Gensbom」(証拠を収集して SBOM を生成するための Scribe Trust Hubs のツール) を呼び出すコード スニペットを追加できます。
まず、独自の手順に従って上記の資格情報をビルド環境に追加します。 ジェンキンズ。次に、指示に従ってコード スニペットをパイプラインに追加します。 ページ をご覧ください
GitHub Actions の CI 統合のセットアップ
GitHub Actions の CI 統合をセットアップするプロセスは、Jenkins のプロセスと似ています。主なアイデアは、Scribe の証拠コレクターおよび SBOM ジェネレーターを「Gensbom」と呼ぶことです。始めるには、次に従ってください GitHub の手順 指示に従って、製品セットアップ認証情報とコード スニペットをパイプラインに追加します。 こちら
Scribe Trust Hub と他の CI システムの統合
Scribe は Jenkins と GitHub アクションのネイティブ サポートのみを提供しますが、他の CI システムにも使用できる場合があります。まず、Unix ベースのコマンド ライン インターフェイスから「Gensbom」ツールをダウンロードします。次に、製品とクライアントの認証情報を追加し、チェックアウト時または最終ビルド イメージの後にビルド スクリプトから Scribe gensbom を呼び出します。
ステップ 3: ソフトウェア部品表の生成
Scribe の gensbom CLI ツールは、Docker および Open Containers Images (OCI) 用のソフトウェア部品表 (SBOM) を生成します。このツールは Mac または Linux システムでのみ実行されます。 Scribe によって生成される最終的な SBOM は、CycloneDX JSON 形式です。これは、SBOM として認識される標準マシンおよび人間が読み取り可能な形式の 1 つです。オープンコンテナイメージは、場合に応じて、Docker、ローカルディスク、またはリモートレジストリから抽出できます。
SBOM の生成元となるイメージの名前、ディレクトリ、パスにはデフォルト設定がありますが、必要に応じてこれらのデフォルト設定を変更することができます。
ステップ 4: SBOM をエクスポートする
Scribe Trust Hub を使用すると、ソフトウェアの検証プロセスの一環として、ソフトウェア部品表をシームレスにエクスポートして共有することもできます。 SBOM は CycloneDX JSON レポート形式で生成され、分析された Docker イメージのすべてのオープンソース依存関係の詳細が示されます。 SBOM が生成されたら、ワンクリックでエクスポートできます。レポートの右上隅に「SBOM をエクスポート」ボタンがあります。それをクリックしてソフトウェア部品表をエクスポートします。
まとめ
ソフトウェア部品表の作成は、ソフトウェア サプライ チェーンを保護するため、またコンプライアンスの目的からも、ますます重要なステップになってきています。 SBOM を生成する理由に関係なく、Scribe Trust Hub は、各ソフトウェア ビルドの SBOM 生成ワークフローを自動化する使いやすく柔軟な方法であることがわかります。