ソフトウェア部品表は、もはや組織にとって「あると便利な」単なる文書ではありません。今ではさまざまな理由から「なくてはならないもの」となっています。連邦規制によりソフトウェアのコンポーネントの開示が義務付けられているという事実とは別に、ソフトウェア会社は、アプリケーションで使用されているすべてのオープンソースおよび商用の依存関係をリストすることがサイバーセキュリティの有益な実践であることを認識しました。
興味深いことに、SBOM の必要性は認識しているにもかかわらず、SBOM の作成は依然として非常に困難な場合があります。それは、製品のソフトウェア部品表を作成するプロセスが複雑で、退屈で、時間がかかる場合があるためです。また、規制当局は製品の反復ごとに正確で正確な SBOM を生成することを推奨しているため、毎回手動で実装することは、完全に非現実的ではないにしても、かなりのリソースを消費します。
包括的な SBOM の実装に関しては、常に自動化ルートに進むことが推奨されます。すべてのソフトウェアは複数の依存関係で構成される複雑なパッケージであり、多くの場合、独自の依存関係も存在します。これは、最も単純なソフトウェアであっても、数百または数千の依存関係がある可能性があることを意味します。これらすべてをコンパイルし、手動で整理するには多大な労力がかかります。この記事では、SBOM の実装に自動化が必要な理由と、SBOM の手動生成に伴うストレスを軽減するために自動化を実装する方法について説明します。
SBOM プロセスの自動化が重要な理由
ソフトウェア部品表は、単にソフトウェア製品のコンポーネントのリストです (食用製品の成分リストに似ています)。一般に、ソフトウェア部品表の作成に必要なのは、これらのコンポーネントをリストしたスプレッドシートだけです。ただし、これは過度の単純化であり、ほとんど実用的ではありません。 SBOM は、必要な情報の正確なセットを含む網羅的なリストです。このリストを手動で処理しようとすると、明らかに時間がかかり、複雑になります。
手動の SBOM ではこれを解決することはできません。そのため、SBOM の実装と取り込みには自動化が不可欠です。手動の SBOM の実装の難しさ以外にも、コンプライアンスの問題は言うまでもなく、手動での SBOM の作成にはリスクも伴います。ソフトウェアの包括的なリストを収集して編集し、人間が判読可能でクエリが簡単なリポジトリに保存する自動システムを使用して SBOM を作成するのが最適である理由の一部を以下に示します。
サイバーサプライチェーンの脅威
包括的な SBOM を生成する主な目的は、ソフトウェア コンポーネントをより深く理解し、考えられる脆弱性を分析することです。これは、あらゆるソフトウェア製品の脅威を軽減するための重要なサイバーセキュリティ対策となっています。自動化された SBOM により、これを行うプロセスがよりシームレスになります。自動化されたソフトウェア部品表は (暗号署名と自動コンポーネント検証のおかげで) より安全になるだけでなく、自動化により、ソフトウェア反復の統合および展開パイプライン全体でコンポーネントが継続的にスキャンされるようになります。
時間の節約
SBOM の実装を自動化するとは、マシンスピードで動作する高度なツールを利用してソフトウェア部品表を生成することを意味します。これにより、さまざまな方法で時間を節約できます。まず、この方法で SBOM を生成すると、個々のコンポーネントを手動で識別してスプレッドシートに含めるよりも高速です。
SBOM を自動化すると、脆弱性の検出がより簡単かつ迅速になります。手動でコンパイルされた SBOM の場合、脆弱性の可能性がある場所を特定するのは非常に長いプロセスです。
SBOM を使用すると、更新も高速になります。自動化されたシステムは、SBOM のチェックを頻繁に実行し、新しく更新された依存関係に基づいて脆弱性を特定します。こうすることで、SBOM の作成や手動でのクエリに時間を無駄にすることなく、リスクをより迅速に軽減し、他の重要なタスクに時間とリソースを投資できます。
NIST および連邦政府の要件
SBOM の自動化は有益であるだけでなく、規制上の重要性も伴います。 2014 年のサイバー サプライ チェーン管理および透明性法などの SBOM に関する連邦要件では、SBOM の生成には自動ソリューションとツールを使用する必要があると規定されています。
同様に、2021 年 XNUMX 月に国家電気通信情報局 (NTIA) は、すべての SBOM に含める必要がある最小限の要素を詳述した連邦承認のガイドラインを発行しました。 自動化サポートはこのドキュメントに記載されています すべての SBOM の重要な要素の 1 つとして。
NTIA によると、ソフトウェア部品表は人間と機械が読み取り可能であり、自動生成できなければなりません。自動化された SBOM を実装すると、ドキュメントに含まれるデータの追跡が容易になります。
スプレッドシートは非効率でエラーが発生しやすい
前述したように、すべてのソフトウェア パッケージには何百もの依存関係があります。これは、一般的なソフトウェア部品表でカバーする必要のあるデータ ポイントが数千あることを意味します。スプレッドシートは、この量のデータを管理するにはまったく不十分です。これらすべてのデータ ポイントを手動で入力すると、時間通りに捕らえられなかった場合に重大な結果を招く可能性がある人的エラーへの扉が開きます。代わりに自動化システムを選択すると、正確で包括的な SBOM が生成される可能性が高くなります。
一貫性
SBOM 生成プロセスを自動化する主な利点の 1 つは、ソフトウェア製品のさまざまなイテレーションの CI/CD パイプライン全体で一貫性を維持できることです。これには、製品の構築中およびリリース後に加えられたすべての変更が含まれます。
SBOM は静的ではありません。製品が進化するにつれて、追加されたすべての新しい依存関係を把握するためにソフトウェア部品表が改訂されます。これらの変更は、ソフトウェアの社内およびサプライ チェーン全体の両方で、すべてのユーザーおよびその他の関係者に伝達される必要があります。すべての関係者が SBOM の最新バージョンと以前のすべてのバージョンのソフトウェアにアクセスできることが重要です。
手動で作成した SBOM では、一貫性の維持とバージョン管理が難しく、クラッシュやその他の問題が発生する可能性があります。自動化された SBOM により、加えられた変更の一貫性が確保され、これらの変更がいつ、どのように行われたかを簡単に確認できます。これを手動システムで達成するのは困難です。
ソフトウェア部品表を自動化する方法
NTIA の SBOM の最小要件などの規制基準では、ソフトウェア部品表の特定の形式が規定されています。これらの標準には、Software Package Data Exchange (SPDX) および CycloneDX が含まれます。ソフトウェア セキュリティ チームは、これらの標準の性質そのものが、SBOM が自動化されることをすでに暗示していることを知っておく必要があります。
したがって、すべてのソフトウェア セキュリティ チームは、開発パイプライン内の戦略的なポイントで実行される自動化されたステップを追加して SBOM を生成し、SBOM の生成と使用を確実にする必要があります。これは、ビルドの完了後にソフトウェア コンポーネントを調査するためのオープンソース ツール、またはソフトウェアの継続的な開発パイプライン内に統合された SCA ツールである可能性があります。ソフトウェア部品表を自動化するさまざまな方法を以下に示します。
オープンソース ツールを使用する
ソフトウェア部品表を作成する最も安価な方法の 1 つは、オープンソース ツールを使用することです。これらは実質的に無料ですが、基本的な機能しか提供しません。 SBOM 実装プロセスを自動化するオープンソース ツールがいくつかあります。ただし、これらのツールのほとんどで生成されるレポートは 2 つの形式でのみ生成されます。サイクロンDXとSPDX。
オープンソースの SBOM 自動化ツールの好例は次のとおりです。 Microsoft の SBOM ジェネレーター. この汎用ビルドタイム ジェネレーターは、企業がソフトウェア パッケージ用の SBOM を生成できるように構築されています。このツールはクロスプラットフォームのサポートを提供し、標準の Software Package Data Exchange (SPDX) 形式で SBOM を生成します。
Microsoft の SBOM ジェネレーターは、NPM、PyPI、Maven、Rust Crates、Ruby Gems、Linux、および NuGet フレームワークで構築されたソフトウェア パッケージに統合して、依存関係とコンポーネントのリストを生成できます。 GitHub パブリック リポジトリと統合することもできます。
このツールは、SBOM の最小要件で指定されている SBOM ドキュメントに関する一般情報を出力します。また、すべてのファイルとパッケージとそれらの間の関係もリストされます。
プラグインツールを使う
SBOM を自動生成するもう 1 つのアプローチは、継続的インテグレーションおよび継続的デプロイメント パイプライン (DevOps パイプライン) 内で行うことです。これは、ワークフローのビルド段階に統合される Maven プラグインを使用して行うことができます。このアプローチは、パイプライン内でソフトウェア部品表を生成するプロセスを自動化する、スケーラブルで便利な方法です。
プロジェクトの構築された環境内でこれを行うので、これははるかに簡単であることがわかります。 SBOM を自動生成するには、いくつかの引数を渡すだけです。 Maven プラグインの場合、SBOM は Cyclone DX 形式で生成されます。
Maven プラグインは、プロジェクト内のすべての依存関係を詳細に説明する包括的な SBOM を生成できます。これを行うには、「mvn verify」コマンドを実行して SBOM ファイルを生成する前に、まず pom.xml ファイルを構成する必要があります。 bom.json ファイルは、SBOM ファイルの前に最初に生成されます。
Maven プラグインには、依存関係について生成された SBOM ファイルを監査する組み込み SCA ツールが付属しています。ファイルの監査が完了したら、SCA ツールをもう一度実行して、ソフトウェア部品表を再度生成できます。
このようなプラグイン ツールの一例は、 スクライブプラットフォームこれにより、ソフトウェア製作者は SBOM を自動的に生成できます。これは SBOM の生成を超えて、ユーザーが SBOM を管理および共有し、整合性を検証し、コンテナー、依存関係、およびパイプラインの脆弱性を追跡するのに役立ちます。 Scribe が SBOM 作成を自動化する仕組みの簡単な概要を次に示します。
- ステップ1： Scribe Hub に登録してログイン (無料)。ユーザーは、この Web インターフェイスを使用してプロジェクトを登録およびセットアップします。 MAC および Linux デバイス上で実行される別の証拠コレクターが SBOM 自体を生成します。
- ステップ 2: Scribe を継続的インテグレーション パイプラインと統合します。これは、Scribe Hub のコード スニペットを継続的統合パイプラインや最終ビルド イメージに追加することで実現できます。
- ステップ 3: ソフトウェア部品表を生成してエクスポートします。ソフトウェア部品表は、Scribe gensbom CLI ツールを使用して生成されます。生成された SBOM は CycloneDX JSON 形式でエクスポートできます。
組成分析 (SCA) ツールを使用する
ソフトウェア製品の SBOM を自動的に生成する 3 番目のアプローチは、サードパーティのソフトウェア構成分析ツールを使用することです。 SCA ツールは製品を分析して、ソフトウェア内のサードパーティのコンポーネントとライセンスを特定します。このツールは、コードの正当性とライセンス要件への準拠を評価します。
SCA は、ソフトウェアのソース コード、バイナリ ファイル、コンテナ イメージ、およびマニフェスト ファイルをスキャンして、その構成を判断し、ソフトウェアに含まれるすべてのオープンソース コンポーネントをリストします。 SBOM の一部として、SCA はさまざまなデータベースに対してこれらのコンポーネントを実行し、セキュリティ情報、ライセンス、既知の脆弱性を抽出します。
ソフトウェア構成分析ツールは、SBOM の作成プロセスを自動化し、高速化します。このツールは、製品のソフトウェア部品表を作成するために、短時間内に数千のデータ ポイントをスキャンするように設計されています。 SCA ツールは、ソフトウェア パッケージのコンポーネントとこれらのコンポーネントの出所を完全に監視することで、DevOps パイプラインのセキュリティを確保するのに役立ちます。
まとめ
規制要件によって義務付けられているという理由だけで SBOM を生成する企業もありますが、ソフトウェア サプライ チェーンの脅威を軽減するという点では、SBOM の実践が必要であることが証明されています。プロセスの自動化は、SBOM を手動でコンパイルするという退屈で時間のかかる作業を軽減するのに役立つため、さらに重要です。この記事で取り上げた各手法で強調されているように、SBOM の自動化により、SBOM の作成プロセスが高速化され、精度と信頼性も高まります。 Scribe のようなプラグイン ツールを使用すると、ソフトウェアの開発パイプライン内で SBOM の作成を自動化できます。 Scribe が SBOM 生成を自動化するためにどのように機能するのか、またそれをどのように活用できるのかについては、ブログやその他のリソースをご覧ください。