現代のアプリケーションはゼロから作られるわけではありません。組み立てられるのです。一般的なエンタープライズのコードベースの多くを見ると、オープンソース要素が大きな割合を占めており、その多くは公開リポジトリから取得され、自社の独自ロジックと組み合わせて使われています。
開発の観点からは、このアプローチは非常に理にかなっています。既に存在するものを差し込んで使えるのに、認証ライブラリやデータ解析の各種関数を自前で書くために何か月も費やす必要があるでしょうか？
とはいえ、根本的な問題はセキュリティに集約されます。各コンポーネントにはそれぞれ固有のセキュリティ履歴があり、その履歴の中には脆弱性、古い依存関係、そして最悪の場合には、次の被害者を待ち受ける意図的な悪意あるコードが潜んでいる可能性があります。
オープンソースのパラドックス
オープンソースの採用はここしばらく加速し続けており、その理由も納得できます。CI/CDサイクルが高速化する中、多くの開発チームは厳しい納期を守るプレッシャーが増しています。しかし問題は、開発者が高品質な仕事をするために必要なリソースを十分に与えられないまま、より速くリリースすることを迫られがちだという点です。
さらに、今日のソフトウェア開発市場では人材不足が深刻で、とりわけシニア層で顕著なため、すべてを内製することはもはや現実的ではありません。
オープンソースを活用すれば（開発者がすべてをゼロから作る必要がなくなるため）多くの問題は解決しますが、一方で可視性の問題が生まれます。セキュリティチームは本番環境で実際に何が動いているのかを把握できず、1つのアプリが数十、場合によっては数百の異なる依存関係を含み、それぞれが独自のサブ依存関係を持つこともあります。
Log4jのインシデントのように重大な脆弱性が公表されると、世界中のセキュリティチームが、そのコンポーネントが自社のコードベースのどこかに存在するのかどうかを突き止めようとして奔走することになります。
依存関係を明確に可視化できていないと、どの程度影響を受けるのかを把握するのは非常に困難です。そこでソフトウェア・コンポジション解析が重要になります。
ソフトウェア・コンポジション解析が実際に行うこと
ソフトウェア・コンポジション解析ツールは、コードベース内のサードパーティコンポーネントを体系的に棚卸しします。
開発者が使用しているものをすべて正確に手作業で記録し続ける（必ずしも現実的ではありません）ことに頼るのではなく、ソフトウェア・コンポジション解析は棚卸しプロセス全体を自動化します。
インベントリの作成
ソフトウェア・コンポジション解析の仕組みを見ると、ツールはまずアプリケーションをスキャンし、使用されているさまざまなオープンソースコンポーネントをすべて特定するところから始めます。これは、コンテナ、バイナリファイル、パッケージマネージャ、そしてソースコードそのものといった要素を検査することを意味します。
このプロセスでは、直接依存（開発者が明示的に追加したライブラリなど）と、推移的依存（他のライブラリの依存関係として一緒に入ってきたライブラリ）の両方を確認します。後者のカテゴリが、実際の露出の大半を占めることが少なくありません。
既知の脆弱性との照合
インベントリを作成できたら、ソフトウェア・コンポジション解析ツールは、各コンポーネントについて既知の脆弱性データベースと突合するクロスリファレンスチェックを実行できます。
一致するコンポーネントがあれば、潜在的な弱点を即座に可視化でき、影響を受けるかどうかや、取るべき適切な対応が何かをさらに調査できます。
ライセンス遵守の確認
ソフトウェア・コンポジション解析ツールは、既知の脆弱性だけでなく、ライセンスの現状も確認します。オープンソースだからといって、自動的に無料であるとは限りません。
コンポーネントには、寛容なもの（MIT、Apache）から制約の強いもの（自社コードのオープンソース化を求める可能性があるGPL系）まで、さまざまな義務が伴います。規制産業の組織や厳格なIPポリシーを持つ組織にとって、このコンプライアンスチェックはセキュリティスキャンと同じくらい重要だと言えるでしょう。
重要な統合ポイント
ソフトウェア・コンポジション解析を最大限に活用したいなら、ワークフローのどこに組み込むかをよく考える必要があります。
まず念頭に置くべきは、後回しのついでにスキャンを実行するだけにしないことです。他のタスクを優先しがちですが、監査の一環として四半期に一度スキャンするだけでは、問題が表面化するのが遅すぎます。その時点では脆弱性がすでにデプロイされている可能性があり、修正コストも高くなります。
最も効果的な実装の一部は、ソフトウェア・コンポジション解析をCI/CDパイプラインに導入し、すべてのビルドで新しいスキャンが走るようにするケースです。開発者は問題のある依存関係を導入した時点で即座にフィードバックを受け取れます。これにより修正コストを左にシフトし、まだ修正が安価な段階で問題を捕捉できます。
さらに踏み込み、開発者のIDEに直接統合する組織もあります。これにより、コードがリポジトリに到達する前、インポートの時点でリスクが顕在化します。代償は摩擦が生じうることです。ツールがワークフローを遅くし、開発者をコーディングから遠ざけるようであれば、反発を招く可能性があります。このバランスを適切に取るには、通常、セキュリティチームとエンジニアリングチームの緊密な協業が必要です。
優先順位付け：ノイズからシグナルを切り分ける
多くのセキュリティチームがすぐに指摘するように、新しいツール導入で最も一般的（そして苛立たしい）課題の1つはアラート疲れです。実装が不十分なソフトウェア・コンポジション解析は、広範なコードベース全体で数百の脆弱性にフラグを立ててしまい、導入前よりもチームの頭痛の種を増やしかねません。
文脈が重要
すべての脆弱性が同じリスクを意味するわけではなく、同じように悪用可能というわけでもありません。影響を受けるコードパスがアプリケーション内で実際には一度も実行されない場合もあり、そのようなものはより差し迫った対応が必要な項目より優先度を下げられます。
新しいSCAツールは、脆弱な関数が実行時に実際に到達可能かどうかを追跡しようとします。これは「悪用可能パス解析（exploitable path analysis）」と呼ばれることがある手法で、チームが本当に重要な問題に修正対応を集中するのに役立ちます。
深刻度評価は絶対ではない
脆弱性データベースの評価は有用なフィルタになりますが、絶対視するのではなく、確かな出発点として扱うのが賢明です。
サンドボックス化された社内ツールで使っているコンポーネントの「重大（critical）」な脆弱性は、顧客向けの認証コードにおける「中（medium）」の問題とは、リスクの水準が大きく異なります。
実装に向けた実践的ステップ
組織がソフトウェア・コンポジション解析プロセスの実装を検討し始めた場合、留意すべき点をいくつか挙げます。
可視性から始める。 何かを最適化する前に、まずすべてのアプリの内部に現時点で何が存在しているのかを完全に理解する必要があります。初回スキャンを実行して層を剥がしていくと、オープンソースのフットプリントがどれほど広いかに驚くかもしれません。
可能な限り自動化する。 コードベース全体を手作業で追跡し、ビルドのたびに記録を更新する方法はスケールしません。代わりに、ソフトウェア・コンポジション解析を既存のワークフローに統合し、単独の取り組みとして捉えないようにしましょう。
明確なポリシーを定義する。 どのライセンス種別が許容されるのか？ビルドをブロックする閾値と警告を記録する閾値はどこか？これらの判断は明文化し、一貫して適用されるべきです。
SBOMを維持する。 ソフトウェア部品表（SBOM）は、ある分野では「あれば良いもの」から規制上の期待へと移行しています。SCAツールはこれらを自動生成でき、製品の中身を尋ねる顧客や監査人に対するドキュメントを提供できます。
結論
オープンソースはなくなりませんし、なくなるべきでもありません。しかし、サードパーティコンポーネントを責任を持って利用するには、コードベースに何が含まれているかを把握し、新たに出現するリスクを継続的に追いかける必要があります。
ソフトウェア・コンポジション解析は、セキュリティチームにその可視性を提供します。最も価値を引き出している組織は、SCAを四半期ごとの監査として扱うのではなく、開発ワークフローに組み込んでいる組織です。
