2023/05/09 SecurityWeek — リスク管理や脆弱性の影響を判断する際に SBOM は有用であるが、複数のプラットフォームでデータが標準化されていないと、全体的なリスク・モデルを構築することは極めて困難になる。2021年5月に発せられたバイデン大統領の大統領令 14028号には、「ソフトウェアのサプライチェーンを理解し、SBOM を取得し、それを使って既知の脆弱性を分析することが、リスク管理において重要である」と記されており、ソフトウェアを政府調達する際の SBOM の必要性を訴えるものだった。 そのことが、セキュリティ分野における大きな契機となり、米政府の機関と請負業者の双方において、広く使われているソフトウェアの内部構造に関して、さまざまな疑問が生じることになった。
ソフトウェアのサプライチェーン
現時点において、いくつかのセキュリティ製品の一部として、SBOM が自動生成され、また、追加コストなしで提供されるケースも多いようだ。各社が提供するサービスには多少のバラツキがあるが、これをこの分野における大きな進歩だと捉えるべきだ。現代のクラウド・インフラの、複雑なコード・デプロイで必要とされる、大きな可視性を与えている。
いまの Web が、いかに複雑であるかは、あまり知られていないだろう。それを明らかにするために、GraphMyRepo から引用した pandas データ分析フレームワークの例を紹介する。このフレームワークは、約 15MB のサイズであり、世界中の何百万もの企業で使用されている。
この分野には多数のセキュリティ・ベンダーが存在し、依存関係ツリーをスキャンするための、オープンソース・フレームワークも存在する。そして、現時点における大きな問題として挙げられるのは、SBOM が平等に作成されていないことだ。SBOM を適切に作成／運用すれば、リスク管理や脆弱性の影響の判断に活用できるが、複数のプラットフォーム間でデータが標準化されていないと、全体的なリスク・モデルを構築することが極めて困難になる。
ここでは、SBOM で理解すべき３つのポイントを紹介していく：
ソフトウェアが使用される場所を理解する
セキュリティ専門家である私たちは、「それらのソフトウェアは、どこでつかわれるのだろうか？」と自問自答することが多い。開発レベルのコードと生産レベルのコードにおける、ソフトウェアの依存関係を含めると、この問は、さらに複雑なものになっていく。しかし、それぞれのリスク・プロファイルを持つ、複数の製品や複数の環境がある場合はどうだろうか。
ビジネス上の判断を合理的に下していくためには、より多くの質問に答える必要がある。そこでは、SBOM に加えて、より多くのメタデータと環境情報を持つことが必要になる。対象となるソフトウェアを理解し、そのソフトウェアが使用される場所を理解することは、リスクを適切に判断するためのコンテキスト構築に役立つ。
オープンソース・ライブラリの法的リスクを評価する
見落とされがちな項目の１つに、オープンソース・ライセンス・ソフトウェアを理解し、組織のポリシーとコンプライアンスに対して、整合性を確保することが挙げられる。このようなライセンスは、法的な影響を生じる可能性があり、あなたのコードについて証拠開示や法的請求が行われることもある。
過去の事例については、こちらを参照してほしい。 前述のように、コンテキストを示すデータの追加ポイントや、レビューの日付は、コンプライアンスを確保するための基盤を構築するのに役立つ。エンジニアリングのユースケースは、時間の経過とともに変化することが多いため、それを考慮する必要がある。
ダウンストリーム・ライブラリを理解する
オープンソースを介した悪意のプロジェクトが、文字通り、下流のユーザーを破壊した話を覚えているだろうか？ この依存関係には、スキャン中に見落とされる、その他の依存関係も含まれる。コードを再帰的に検索して、影響を受ける可能性のある下流のライブラリを発見することは、特にプロダクション・パイプラインでは重要となる。
代替案を事前に準備する
オープンソース・ライブラリでは、常に脆弱性が発見されており、修正に時間がかかることも少なくない。そこでの待ち時間は、数日／数週間／数ヶ月にもなり得る。すでにサポートされていない、あるいは、サポートされない可能性のあるソフトウェアを知ることが重要となる。ライブラリ内のコードを、自分で削除する必要性や、プロジェクトをフォークして内部で保守する必要性が生じるかもしれない。すべてのリスクを完全に取り除くのことは不可能であっても、危殆化しているリンクに対する計画を、あらかじめ準備しておくことで、この種のリスクを軽減できる。
SBOM という実験には、長い道のりが残されている。多くの人々が、マシン・リーダブル・フォーマットの標準 (SPDX／CycloneDX) を統一しようとしているが、ここで私が述べてきたことを、はるかに超えたレベルの話である。とは言え、正しい方向に進んでいるようだ。これらの規格を、共通のマシン・リーダブル・フォーマットに統一できなければ、各種の規格が爆発的に増えることになる。
より大規模で複雑な、モジュール式ソフトウェアを作り続けることで、外部との依存関係やサプライチェーンを対象とする攻撃が増え続けている。ソフトウェアのサプライチェーンを理解するために、手作業で開発して、より多くの洞察を得ることも可能だ。しかし、SBOM を取得し、それを使用して、既知の脆弱性を分析することは、リスクを管理する上で極めて有用である。将来的には、発見から修復までのワークフロー・プロセス全体を、自動化できるようになるはずだ。
2023年に入ったころは、2023/01/19 の「SBOM の品質をチェック：米政府基準の最小限要素を満たすものは１％に過ぎない」 にあるように、先行きが危ぶまれていた SBOM ですが、Docker や GitHub による SBOM サポートの表明があり、なんとなく勢いがついてきました。今日の記事は、SBOM 対応の最小セットに加えて考えるべきことを整理してくれています。よろしければ、以下の関連記事と、SBOM で検索も、ご利用ください。
2023/05/08：SBOM エコシステムを CISA が推進
2023/05/04：SBOM：Gartner の予測値について考える
2023/04/25：SBOM を構築して活用する：第一歩を考えよう
2023/04/11：米陸軍は SBOM を望んでいる
IoT OT Security News 
You must be logged in to post a comment.