過去数年間に、この問題について多くの言葉が書かれてきました。 SBOM – ソフトウェア部品表。これだけの露出があると、人々は説明するのに十分な内容を知っていると感じます。これはソフトウェアの構成要素のリストであり、透明性とセキュリティにとって重要であり、一時的な依存関係を明らかにするのに役立ちます。これらはすべて真実です。
それでも、SBOM は見た目ほど明確ではありません。まず、新しいライブラリ バージョンまたはパッチを常に最新の状態に保つには、新しい SBOM をリリースする必要があることを考慮してください。多くの場合、一度に 1 つか 2 つのライブラリだけを変更したりパッチを適用したりするので、新しい要素を分解して SBOM に追加し、その他はすべて同じままにできます。
では、「既知と未知」の概念についてはどうでしょうか?開発者が何かが足りないとわかっている場合は、それを「既知-未知」として入力し、後で空白を埋めることができます（またはまったく埋めないこともできます）。
非常に複雑で、複数の連動要素を含むソフトウェア アーティファクトもあり、それぞれがそれ自体でソフトウェア アーティファクトを構成します。多くの場合、各要素には独自の個別の SBOM があり、ビルド全体にはより大きな集約された SBOM が含まれる場合があります。
これらはすべて、明確で単純な SBOM ファイルの代わりに、常に可能な限り最新の状態に保つ必要がある、さまざまな絶えず変化する要素のホストになる可能性があることを示しています。
これはすべて良いことですが、SBOM または SBOM の一部が可能な限り正確または最新でない場合、それは誰にとってどのような違いをもたらすのでしょうか? SBOM の出所と正確性の両方を維持するにはどうすればよいでしょうか?
この記事では、脆弱性スキャンと脆弱性開示における SBOM の使用について検討します。暗号署名について説明し、SBOM またはその一部に署名することでセキュリティと透明性のツールとしてどのように役立つかを見ていきます。また、メタデータについて、また、SBOM やその他のアーティファクトの作成において、特に認証に暗号的にサインインする場合にそれが非常に重要である理由についても説明します。
ここから始めましょう: そもそも暗号署名とは何ですか?
暗号署名は、デジタル ファイルまたはフォルダーの整合性と正確性を検証するために使用されます。署名付きファイルは、署名を無効にしない限り改ざんできないため、誰かが署名付き文書を検証しようとするとすぐに発見されてしまいます。
そのため、デジタル署名は、企業の兵器庫の中で非常に貴重なツールとなっています。 ソフトウェアセキュリティ 業界では、デジタル資産のデジタル署名または暗号署名という単純な概念の用途がすでに多数見つかっています。
どのように機能するのでしょうか?デジタル署名は、エンティティが秘密鍵と公開鍵という 2 つの鍵を持つ非対称暗号化に基づいています。 2 つの鍵は、自分の秘密鍵で署名された文書を自分の公開鍵を使用して検証できるようにリンクされています。検証とは、文書がいかなる方法でも改ざんされていないこと (1 ビットの変更でさえ署名が検証できなくなる) と、署名者の身元、または少なくとも使用されたキーの身元を証明することの両方を意味します。
その SBOM で何をしているのですか?
SBOM は、ソフトウェア コンポーネント情報を含む長くて複雑なファイルだけではありません。これらは、ソフトウェア成果物を構成するコンポーネントを正確に知るための入り口となります。コンポーネントの完全なリストを知る必要があります。何が含まれているかを正確に知っていると思っていても、ライブラリを追加するたびに多数の隠れた一時的な依存関係が組み込まれている可能性があり、そのそれぞれが脆弱性やエクスプロイトの媒介となる可能性があります。クライアントに出荷するソフトウェアに組み込まれるようになりました。
SBOM とその完全な構成要素のリストを取得したら、そのリストを既知の脆弱性データベースと照合して、ソフトウェアにどのような脆弱性が含まれているかを確認できます。しかし、それはほんの始まりにすぎません。脆弱性スキャンを実行したことのある人なら誰でも知っているように、単純なアーティファクト スキャンの結果でも、簡単に数百 (またはそれ以上) の脆弱性が検出される可能性があります。
ここから大変な作業が始まります。各脆弱性をマッピングし、特定のソフトウェア構成で悪用可能かどうかを確認し、その情報を文書化して、できれば危険性の順にパッチを適用して修正することで悪用可能な脆弱性に対処します (ライブ)。実際のエクスプロイトは、まだ起こったことのない理論上のエクスプロイトよりも危険です)。
このすべての作業と脆弱性の文書化と修復は、ソフトウェア制作者にとって重要ですが、クライアント、パートナー、潜在的な監査人にとっても重要です。
彼らは、あなたが潜在的な脆弱性を認識しており、それらがクライアントやパートナーである彼らに影響を及ぼさないように、パッチを適用して欠陥を修正するなど、その問題に対処していることを知りたいのです。
新しい脆弱性が常に明るみに出ているため、この点ではスキャンを実行する時間が重要であるため、作成時のメタデータとともに SBOM に署名することは、本当に優れていることを示す優れた方法です。脆弱性リストの。
このようにして、脆弱性について事前に知っていて、それが無関係であることを証明できます ( VEX アドバイザリー)、特定のバージョンには存在しない、または最後のバージョンをリリースした時点では存在すらしなかったということです。
どこにサインすればいいですか？
次に、その単純な成分リスト ファイルを、記事の冒頭で説明したより複雑な使用例の 1 つに置き換えてみましょう。複数の SBOM を結合して、アーティファクト全体を記述するより大きな集約バージョンを形成すると、その集約バージョンの個々の部分の署名と検証がますます重要になります。複雑なソフトウェア成果物の新しいバージョンを構築しているとします。この新しいバージョンでは、3 部構成のアーティファクトのうちの 3 部だけが変更されています。他の 3 つの部分はまったく同じままになります。 3 部構成の完全な SBOM を構築し、1 つすべての脆弱性をスキャンし、関連するエクスプロイトを見つけるために 3 つすべてをマッピングすることに、なぜ時間とリソースを浪費する必要があるのでしょうか?唯一の変更はパート 2 にあるため、作業を加える必要があるのはパート 3 のみです。前回作成したときに XNUMX つの SBOM と脆弱性スキャンすべてに署名した場合は、他の XNUMX つのパートの情報を含めることができません。変更されていません。これにより、パート XNUMX と XNUMX の SBOM が元のバージョンと同一であることをいつでも証明できます。もちろん、新しい脆弱性が心配な場合はスキャンを再度実行することもできますが、それは完全にあなたとソフトウェア次第です リスク分析.
いつ、どのくらいの頻度で SBOM を作成し、脆弱性をスキャンしたかをクライアント、パートナー、監査人に証明できることは、さまざまな理由で役立ちます。とりわけ、保護されるべきことはすべて行ったので、エクスプロイトによる損害に対して責任がないことを証明するために法廷で使用される可能性があり、それによって、 セーフハーバー.
ここからどこへ行くか
前に述べたように、ソフトウェア成果物またはファイルにデジタル署名する場合の問題の 1 つは、キー管理システムを扱うのが面倒なことです。 Sigstore のようなものを使用して従来の PKI の使用を回避し、署名と検証のフローを自動化することでその煩わしさを解消できれば、このセキュリティ ツールを利用しない理由はほとんどなくなります。ファイルまたはアーティファクトの署名に使用される ID が、CI/CD パイプラインのセキュリティを検証するポリシーでも使用できることを考慮すると、目に見えるほぼすべてのものに署名を開始する意欲がさらに高まるはずです。
メタデータを使用してファイルに署名すると、ファイルが作成された時間と場所、作成されたペルソナやシステムなど、セキュリティ専門家の視点で検討したすべての関連情報を検証するのに役立ちます。歌っている人物がチェックされるまでは、単純な置き換えで署名付きの説得力のある偽造品が提示される可能性がある場合、人物、システム、時間がソフトウェアが作成された会社およびパイプラインと一致していることを判断できることは良いアイデアです。
私が証拠に署名して検証するために提案したツールが無料で使用できることを考慮すると、まったく言い訳の余地はありません。記事全文をご覧ください ヴァリント – Validation Integrity ツールを使用して他に何ができるかを確認し、SBOM やその他の生成された証拠への署名を今すぐ開始してください。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
