2023 年 XNUMX 月、CISA はソフトウェア セキュリティに関する新しい共同ガイドをリリースしました。 サイバーセキュリティ リスクのバランスを変える: セキュリティ バイ デザインとデフォルトの原則。このガイドは、NSA、オーストラリア サイバー セキュリティ センター (ACSC)、ドイツ連邦情報セキュリティ局 (BSI) など、9 つの異なる機関の協力を得て作成されました。世界中の複数の機関がサイバーセキュリティガイドの作成に協力しているという事実は、現時点でサイバーセキュリティというテーマが世界中で重要であることを強く証明しているはずです。
CISA長官のジェン・イースタリー氏は、ピッツバーグのカーネギーメロン大学で学生と教員に行った最近の講演で、サイバーセキュリティのテーマに関する自身の考えを語った。 CISA ディレクターによると、これらの基本原則は、今後数年間で世界のソフトウェア業界を導くのに役立つはずです。
- 安全性の負担は決して顧客だけに負わせるべきではありません。ソフトウェアメーカーは自社の製品とコードに対して責任を負う必要があります。
- テクノロジーメーカーは、自社製品に対する説明責任の取り組みとして徹底的な透明性を採用する必要があります。
- テクノロジーメーカーは、安全な製品を構築することに重点を置き、設計上安全であり、デフォルトでも安全な製品を開発する必要があります。
CISA ガイドは、これらの基本原則を発展させたもので、ソフトウェア メーカーがより安全な製品を市場に投入するために実行できる実践的な提案の包括的なリストが含まれています。
興味深いのは、明示的な提案の多くが以下に基づいていることです。 NIST の SSDF フレームワーク しかし、より実践的で、自発的ではない方法で表現されています。
このガイドの提案の 1 つは、抜本的な透明性に直接関係しており、ソフトウェア メーカーに対して、 SBOM SDLC に追加して、ソフトウェアのコンポーネントを可視化します。
しかし、SBOM を作成し、それを公開するだけで本当に十分なのでしょうか?ソフトウェア制作者またはソフトウェア利用者は、SBOM JSON または XML ファイルを使用して実際に何ができるのでしょうか?
この記事では、SBOM が今日ソフトウェア制作者にもたらすことができる用途、SBOM を強化するために SBOM に追加できる情報、およびそのような強化されたドキュメントを調べることで得られるビジネス インテリジェンスについて検討します。 SBOM 使用のコンプライアンス面と、ソフトウェア制作者、ソフトウェア アグリゲーター、またはオープンソース メンテナーとしての責任の所在について簡単に見ていきます。最後に、リスク管理と、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトという CISA の原則が、サイバーセキュリティ規制順守および賢明なリスク管理とどのように連携するかについて説明します。
すべての SBOM が同じように作成されたわけではない
現在、オープンソースから独自のソリューションに至るまで、SBOM の作成に利用できるツールが多数あり、SBOM の作成を SOP に組み込みたい個人や企業は簡単に行うことができます。異なるものの中から選択することもできます 規格 顧客のニーズに最も適したものを選択できますが、それでも情報に基づいた意思決定を行うにはツールが多すぎる可能性があります。では、適切なものを決定する際に、これ以上何を求めることができるでしょうか。 SBOMの生成 あなたのためのツール？
まず、SBOM の作成時にどのような情報が含まれているか、または省略されているかを確認します。開発プロセスの一部ではあるが実際の製品の一部ではないツールやコードを含む部品表には、多くの冗長な情報が含まれている可能性があり、結果として得られるファイルから「クリーンアップ」して必要な情報のみを保持するのは非常に困難です。最も関連性の高い情報。同様に、含まれていないツールやコード、または意図的に省略されているツールやコードは、たとえば脆弱性をスキャンするときに著しく欠落しています。
ソフトウェアの構成要素と依存関係のリスト自体は、ほとんど意味がありません。あなたがそれを使って選択できる以上の目的はほとんどありません。現在、SBOM の最も一般的な用途は、ソフトウェア コンポーネントをスキャンして、製品に影響を与える可能性のある脆弱性のリストを取得することです。
発見された脆弱性の約 95% は製品では悪用できないことを覚えておくことが重要です。重要なのは、とらえどころのない 5% を見つけて作業計画を立て、悪用可能な脆弱性への対処を開始することです。何が悪用可能で何が悪用可能ではないかをどうやって見分けるのでしょうか?これは、セキュリティ担当者やエンジニアリング担当者を夜も眠れなくさせる大きな問題です。現在の提案の XNUMX つは、と呼ばれるソリューションを採用することです。 VEX – Vulnerability Exploitability eXchange。セキュリティ アドバイザリの一種で、その目的は、コンポーネントが使用されている製品のコンテキストにおいて、既知の脆弱性を持つコンポーネントの悪用可能性を伝えることです。脆弱性情報の干し草の山を精査し、悪用可能な脆弱性を見つけるという多くの作業は、主にエンジニアリング チームに任されています。結局のところ、コードを書いた人以上に自社の製品についてよく知っている人はいないでしょうか?
ただし、特に Docker イメージの親イメージ、または依存関係チェーンのはるか昔の依存関係に由来する継承された脆弱性に関しては、他にもできることはあります。次のようなオープンソース ツールを使用する 親画像 どの脆弱性が親イメージに付属しており、どの脆弱性がコードの直接の結果であるかを把握できます。これにより、潜在的に大規模な脆弱性が排除され、選別作業が容易になるはずです。さまざまな脆弱性に関するさまざまなアドバイザリを使用することも良い考えです。脆弱性が悪用できないと判断したら、チームの他のメンバーやユーザーに知らせて、すべてのバージョンで同じ脆弱性をチェックし続けることがないようにするのが合理的です。オープンソースとサードパーティの依存関係を追跡し、悪用可能な脆弱性を見つけて修正したら、製品内のそのコードを更新して、特定の潜在的な問題からも確実に保護されます。
SBOM にさらに何を追加できるでしょうか?
上で述べたように、今日 SBOM の最も一般的な用途の 1 つは、脆弱性スキャンのチェックリストとして使用することです。 NVD (National Vulnerability Database) などのさまざまな無料で利用できるデータベースを使用すると、SBOM によって提供されるものと同様のコンポーネントのリストをスキャンし、そこに含まれる脆弱性を確認できます。脆弱性のリストを取得したら、重大度順に並べ替えたり、既存の修正があるかどうかを確認したりできます。
コンポーネントに関して知っておくと役立つもう 1 つの情報層は、コンポーネントのライセンスです。多くのオープンソース コンポーネントには、商用利用と互換性のないライセンスが付属しています。すべてのオープンソース コンポーネント (自分でインクルードせずに他のコンポーネントにインクルードされたものであっても) が、ライセンスの観点から作成しようとしているものと互換性があることを確認することが重要です。
最後の提案は、依存関係についてオープンソースのセキュリティ「ヘルス」メーターに従うことです。 OpenSSF スコアカード。オープンソース ライブラリのサイバーセキュリティの健全性を客観的に示す比較的簡単な尺度を持つことは、製品にどのライブラリを含めるか除外するかを決定する際に大きな助けとなる可能性があります。これらのスコアと脆弱性の重大度を組み合わせると、最初に対処する脆弱性を順序付けるのに役立ちます。
ビジネスインテリジェンスの演習としてのリスク管理
複数存在する セキュリティリスク 昨今のソフトウェア制作者にとって、マルウェア、暗号通貨採掘者、パスワード窃盗者、ランサムウェアの間で、メーカーが安心して何でも市場に投入できるのは不思議です。すべてを一度に処理できる人はいないため、企業は脅威モデルを作成し、最も弱い部分と考えられるものに応じてリスクを管理しようとしています。最も簡単な最初のステップは、コードと開発プロセスが関連する規制とベスト プラクティスに準拠していることを確認することです。 ニストのSSDF そしてOpenSSF SLSA SBOM などに対する米国の要件と同様に、始めるのに適しています。規制とベストプラクティスに従うことで、少なくとも、法に基づく訴訟から比較的安全を約束できる可能性があります。 セーフハーバー プログラム。しかし、それはほんの始まりに過ぎません。
CISA ガイドは、メーカーに対し、セキュリティを第一に念頭に置いて製品の構築に取り組むことを推奨しています。製品完成後の一部の「ボルトオン」セキュリティでは、製品のアーキテクチャの一部であるいくつかの根本的な弱点を軽減することはできません。このガイドによると、Secure-by-Design の製品とは、顧客のセキュリティが単なる技術的な機能ではなく、中核的なビジネス目標となっている製品のことです。メーカーもこれを採用することが奨励されています 徹底的な透明性 そして説明責任。これは、とりわけ、脆弱性に関する勧告と、それに関連する一般的な脆弱性とその危険性を確保することを意味します (CVE) 記録は完全かつ正確です。これは、メーカーが製品の潜在的な問題を少なくとも認識していることをユーザーや顧客に示す方法として、コードのコンポーネント、その依存関係、および脆弱性を共有することが奨励されることも意味します。
Wikipediaによると、 ビジネス・インテリジェンス (BI) 企業が使用する戦略とテクノロジーで構成されます。 データ分析 ビジネス情報の管理。ご想像のとおり、ビルドごとに SBOM を収集するだけでなく、脆弱性レポート、ライセンス情報、悪用可能な脆弱性と悪用できない脆弱性を詳細に説明するアドバイザリも収集します。これは大量の情報です。一般的なソフトウェア製品の寿命と、使用しているサードパーティのコードやツール、および組み込んでいるオープンソース パッケージについてこの情報が必要になるという事実を考慮すると、情報ポイントの数は増加します。直接的または一時的に。組織のセキュリティ権限者 (おそらく CISO とその配下の人々) が使用できる方法ですべてを理解するには、システム、つまり単一の「ガラスの窓」プラットフォームが必要です。これにより、すべての情報を整理し、効果的に検索し、必要に応じて有用なレポートとして表示することができます。 BI プラットフォームがサイバーセキュリティ プラットフォームにとってどれほど重要であるかを 3 つの例として挙げると、次のように想像してください。 Log4J 去年のドラマ。この「新しい」脅威に対して、数回のキーストロークで依存関係やサードパーティ ツールを含むすべての製品を検索できたら素晴らしいと思いませんか?新しく登場した別の脅威となる CVE の存在を確認してみるのはどうでしょうか?または、会社全体の脆弱性の数が時間の経過とともにどのように徐々に減少しているか (または少なくとも増加していないか) に関するレポートを準備します。これは、サイバーセキュリティ SBOM が強化された収集プラットフォーム上の BI システムのみが提供できる、有用な「全体像」情報です。
関連情報をすべて入手して初めて、現在のコード、依存関係、および製品にサードパーティのツールやコードを含めるか省略するかを選択する際のリスクを真に評価できます。継続的に実行すると、このリスク評価を使用してビルドを管理し、不審なアクティビティが検出された場合に本番環境や配信を停止することもできます。
未来を見る
テクノロジーは常に進歩し続けています。かつては、組織のオフィスにあるサーバー上に置かれたモノリシック コード プロジェクトが標準でしたが、現在ではマルチクラウド マイクロサービス アーキテクチャと LLM がその主流となっています。 SBOM は、関連性と有用性を維持するためにソフトウェアが利用する複雑なアーキテクチャやインフラストラクチャをサポートできるように進化し続ける必要があります。たとえば、OWASP の CycloneDX は、すでに次の機能を含めることに取り組んでいます。 ML の透明性 SBOM形式で。同じフォーマットには、将来の計画時に VEX 機能と SBOM 共有 API も確実に組み込まれる予定です。私は、次のようなプラットフォームがますます増えていくと予想しています。 筆記 SBOM を含むセキュリティ関連情報の蓄積と共有を目的として、規制上の理由と、そのような充実した情報が適切に利用する組織にとっての利益と価値の両方を目的として作成されます。
Scribe のプラットフォームは、私が提案したすべての機能などを備えた、既存のセキュリティ プラットフォームの一部として新しい BI ツールをリリースしようとしています。ぜひお勧めします 試してみる、時間の経過とともに蓄積されたそのような情報の有用性を確認し、その情報を何に使用できるかを確認します。 Scribe プラットフォームを SDLC に組み込むことを選択したかどうかに関係なく、より安全なエコシステムとより包括的で便利な SBOM を求める競争はまだ終わっていません。規制や市場の圧力によって急進的な透明性を強制されるよりも、今すぐ透明性ワゴンに乗る方が良いでしょう。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
