動的SBOM：ソフトウェアセキュリティをリアルタイムで可視化
システムのSBOM（ソフトウェア部品表）を監視することは、システムのライフサイクル全体を通じて安全性を維持し、開発を進める上で重要な要素です。SBOMを追跡することで、開発者は継続的に脆弱性を検出し、適切な対策を講じるための判断を行うことができます。
動的SBOM（DSBOM）は、従来の静的SBOMに比べてソフトウェアセキュリティ評価を進化させたものです。静的SBOM分析では、ライブラリや依存関係を含むシステムコンポーネントの包括的な概要を提供しますが、動的SBOMはコードの実行中にサードパーティライブラリへの呼び出しを能動的に監視することで、リアルタイムのインサイトを追加します。
動的SBOMの際立った特徴は、アプリケーション内で実際に使用されているライブラリを正確に特定し、追跡できる能力です。このリアルタイムの監視により、ソフトウェアのエコシステムや潜在的な脆弱性をより正確に把握できるため、セキュリティ対策の優先順位を効果的に決定することが可能になります。
DSBOMの利点
動的SBOMは、セキュリティ対策の優先順位付けをより簡単かつ効果的に行います。以下の例を見てみましょう。静的SBOMでは、CVE-2023-31484がlibperl 5.36.0に関連していると報告されています。しかし、動的スキャンではこのアプリケーションのライブラリで使用されていないことが確認されました。一方で、動的SBOMによってアプリケーションがlibcurlをロードしていることが判明しました。これを静的SBOMと照合すると、libcurlのバージョンが7.86.0であり、これにはCVE-2023-27534が存在することが確認できます。
これで優先順位の判断が容易になりました。仮にこのアプリケーションのセキュリティ評価を行う必要がある場合、libperlに関連するCVE-2023-31484への対処は後回しにできます。一方で、libcurlに関するCVE-2023-27534は実際に使用されているライブラリに関連しているため、より緊急性が高く、優先的に対処する必要があります。
DSBOMの仕組み
初めに、「PlaxidityX DSBOM」は、動的ライブラリへのすべての呼び出しをトラップ割り込み、つまり「ブレークポイント」（x64およびARCH64で動作）に置き換えます。これは、メモリのアセンブリコードを置き換えることで実現されます。
そしてコードが実行されます。
動的SBOMを使用する際の検討事項
動的SBOMを活用する際には、以下の点を考慮することが重要です。
ItraceではなくDSBOMを使用する理由
ltraceは、printfのように繰り返し呼び出されるものを含め、外部ライブラリへのすべての呼び出しを記録するため、パフォーマンスが低下します。一方、DSBOMは各呼び出しを一度だけ記録することで、スピードと効率を最適化します。さらに、ltraceはアプリケーションからの直接的な呼び出ししか追跡できず、他のライブラリからの内部関数や推移的な呼び出しを把握することができません。これに対して、DSBOMはコード内の重要なパスを特定できます。例えば、特定の関数に脆弱性が存在する場合、DSBOMはその呼び出しがサードパーティライブラリ経由で行われた場合でもアラートを発することが可能です。
静的解析の補完にDSBOMを使用
動的SBOMは静的分析を補完するものですが、いくつかの理由から完全に置き換えることはできません。
- 不完全なカバレッジ: 動的分析では、コードカバレッジが不十分な場合にアプリケーションのすべての機能を網羅できない可能性があります。そのため、潜在的な脆弱性を特定するためには、静的分析の併用が必要となります。
- 依存関係の影響:特定のライブラリがメインアプリケーションで直接使用されていなくても、別のコンポーネントやサブシステムが依存している可能性があります。このような場合、脆弱性修正の優先順位に影響を与えることになります。
- 未使用ライブラリの識別: 動的SBOMの結果を基に未使用のライブラリを特定し、システムから削除することで、攻撃対象領域を減らし、システムのセキュリティを強化できます。
カバレッジと効果
動的SBOMの結果は、モニタリング中に達成されたカバレッジに直接影響を受けます。ユニットテストなどの包括的なテスト手法や、「PlaxidityX Security AutoTester」のような自動車向けファジングテスト製品を活用して高いカバレッジを達成すれば、システムの安全性とセキュリティを向上させるための、より信頼性が高く実用的な結果が得られます。
行カバレッジは、テスト中に実行されたコード行の割合を測定する指標であり、DSBOM分析において使用される重要なメトリクスです。以下のグラフでは、行カバレッジがライブラリの発見に与える影響を示しています。なお、この例では小規模かつ目的特化型のコードを用いており、大規模なプロジェクトでは結果が異なる可能性があります。
静的SBOMの出力結果は、次のような形式になります。
この表は、システム内に存在するアプリケーションやライブラリについて、実際に使用されているかどうかに関わらずユーザーに情報を提供します。図6に示されているように、メインアプリケーションで使用されていないアプリケーションやライブラリがシステム内に含まれている場合があります。
この例は、カバレッジを増やすことで検出精度が向上することを明確に示しています。しかし、依然として静的SBOMと重ならない未検出のライブラリが存在します。複数の実行結果を比較した詳細は、図4をご参照ください。
DSBOMがカバレッジに依存しているという事実は、たとえカバレッジ率が高くても、ライブラリが呼び出される箇所を網羅していなければ、結果の精度が低下することを意味します。したがって、重要なのはカバレッジの「量」だけでなく「質」であるという点です。
もう1つ重要なポイントは、DSBOMは呼び出されなかったライブラリ（関数が一度も呼び出されていないライブラリ）についても報告することです。これは、システム要件を理解する上で有益な情報となります。以下の表では、無作為に選んだサンプルの中で、実際に使用されたライブラリは1つだけであり、他のライブラリはすべて「必要」として報告されていることがわかります。全体として、カバレッジが高い領域で呼び出されたライブラリは読み込まれたライブラリ全体のわずか11%でした。この結果が示す可能性として、以下の3つが考えられます。
- デッドコード: 必要のないサードパーティコードが使用されている可能性があります。
- 低カバレッジ:
該当するコードがテストされていない可能性があります。 - 推移的依存関係:
ライブラリの機能の一部のみが使用されるのは一般的であるため、特に対応する必要はありません。
この表は、プロセスメモリにロードされたライブラリの数と、実行時に実際に呼び出されたライブラリの数を比較したものです。表示されているデータは、全体の表から無作為に選んだ小規模なサンプルであり、完全なデータは非常に膨大であるため、ここでは一部のみを示しています。
図8は、システム内に存在するアプリケーションおよびライブラリの数と、メインアプリケーションで実際に使用されているライブラリの数を比較したものです。DSBOM分析の結果、1,000個のライブラリのうち、実際にアクティブに使用されているのはわずか14個であることがわかりました。この洞察は、脆弱性対策の優先順位を決定する上で非常に重要です。このようにライブラリを絞り込むことで、プログラマーやプロダクトマネージャーは言うに及ばず、CISO（Chief Information Security Officer、最高情報セキュリティ責任者）にとっても負担が軽減されます。特に、より重大な脆弱性が存在する領域を強調することで、意思決定が容易になり、アナリストのアラート疲れを回避する助けにもなります。
結論
動的SBOMは、コード実行中にライブラリの使用状況をリアルタイムで把握することで、ソフトウェアセキュリティ評価を強化する重要なツールとして登場しました。静的分析を完全に置き換えることはできないものの、それを効果的に補完する能力により、静的分析だけでは見逃したり、優先順位を誤って判断する恐れのある脆弱性を明らかにします。ライブラリの使用状況を正確に特定し追跡することで、動的SBOMはセキュリティ対策の優先順位付けを効率的に支援し、より堅牢なソフトウェアセキュリティの実現に貢献します。
しかし、動的SBOMのカバレッジと有効性は、モニタリングのカバレッジに直接影響を受けるため、包括的なテスト手法の導入が重要であることも忘れてはなりません。また、ライブラリが使用されたかどうかにかかわらず、必要なライブラリをすべて報告する機能は、デッドコードやテストカバレッジの不足など、システム要件や潜在的な問題を示す有用な指標となります。静的分析と慎重に組み合わせて活用することで、動的SBOMは潜在的な脅威に対するソフトウェアエコシステムの強化に大きく貢献することができます。