ソフトウェアの推移的依存関係をどこまで把握できるか？
まずはソフトウェアのサプライチェーンについて考えてみよう。簡単に言えば、ソフトウェアが本番環境にデプロイされ、ユーザーの元へ届くまでの一連の流れを指す。物流のサプライチェーンを想像してみると分かりやすい。原料が工場に届き、加工され、別の工場に移送されて別の加工が施され……最終的には消費者の元へと届けられる。そうした供給の一連の流れだ。
一方、ソフトウェアのサプライチェーンの流れを見ると、コードには外部ライブラリ（主にOSS）が多く組み込まれている。つまりソースコードは何らかのOSSに依存し、そのOSSはまた別のOSSに依存し、それが何重にも連鎖したものとなっている。悪意あるコードやパッケージを潜ませることをソフトウェアのサプライチェーン攻撃と言う。
開発から本番環境までのサプライチェーン全体に良くないものが混入していないかをチェックするフレームワークにSLSAがある（元々はGoogle社内で使われていたもの）。ソースコードに脆弱性などが混入するポイントには多数ある。例えばソースコードは外部から攻撃されるようなリポジトリに置かれていないか、ビルドされたソースコードが後から改ざんされていないかなど。ソフトウェア開発ではサプライチェーン全体を見て、脆弱性を割り込ませる隙を作らないようにする必要がある。それがサプライチェーン攻撃の防止策となる。
どのくらいの脅威があるのかを数字で見ていこう。JFrog Japanの横田氏は自身の調査結果として「ソフトウェアの99％、エンタープライズ向けソフトウェアなら85％にオープンソースのコンポーネントが含まれます。昨今生じている攻撃の62％がサプライヤーの信頼を悪用したものとなり、2015〜2021年で6.5倍に増加しました。2022年にはさらに4倍に増加すると予想されています」とまとめた。
直近で印象的な事例がLog4Shellだ。2021年末にJavaでよく使われるロギングのライブラリに致命的な脆弱性が含まれていたことが発覚し、問題となった。クリスマス前後で対応に追われた人もいるだろう。
繰り返しになるが、ソフトウェアの依存関係は深く連鎖している。推移的依存関係とも言われる。多くのプログラマが自分のコードや自分が参照したコードであれば、目が届く。しかし遠い依存先までは把握するのは難しい。
横田氏は「身近なところならパッケージマネージャを定義しているファイルがあります。そこにあるのが皆さんが直接使うOSSです。そこに書かれているOSSがさらに何を使っているかを対策していかないと、完全なセキュリティ対策ができているとは言えないのです」と指摘する。
SBOMで抑えるべきポイント3つを詳しく解説
こうしたソフトウェアのサプライチェーンに潜む脅威にどう対策するか。ひとつの答えが「SBOMを作る」こと。もちろん、これだけで全て解決するわけではないが、重要な柱となるのは確かだ。
あらためてSBOMとは「Software Bill Of Materials」の略であり「ソフトウェア部品表」と訳されることもある。食品なら食品成分表をイメージするといいだろう。ソフトウェアを構成するコンポーネントとメタデータの一覧となる。脆弱性やライセンスの観点で安全性を確認する、あるいは保証するのに使われる。
アメリカでは政府と関わる重要なソフトウェアではSBOMが義務化されるほど、ソフトウェア開発ではメジャーなものとなりつつある。日本では自動車業界や医療業界でも徐々に浸透してきている。
SBOMに記載するコンポーネントは、ソフトウェアが依存または使用するOSSやサードパーティーのライブラリ、ソフトウェアが使うアドオン、プラグイン、拡張機能、プロプライエタリなコード、SaaSの場合はAPIやサードパーティーのサービスに関する情報を含んでもよい。プログラムで使うものは全て網羅すると考えていいだろう。SBOMで抑えるべきポイントは次の3つ。
（1）Data Fields
SBOMに記録する情報で、大きく分けてSBOMそのものの情報とソフトウェアの情報となる。前者はこのSBOMが用いているフォーマット、作成者、作成時のタイムスタンプで、後者はコンポーネント（パッケージ）の名前、識別用のキー、バージョン、サプライヤ、そして大事な依存関係だ。依存するものを記載していく。
（2）Automation Support
SBOMの生成や利用を自動化しやすくするための配慮。SBOMのフォーマットは標準的なものに則り生成すること。最近SPDX（Software Package Data Exchange）が国際標準となったが、他にもSWID（Software Identification）やCycloneDXも有名だ。できれば一貫して同じフォーマットで管理したほうがいいだろう。なおSPDXはコロンでタグと値を区切るタグバリュー（tag:value）形式で、他にもJSON、YAML、XMLなどにも対応している。
SBOMに関するツールは大きく分けて生成のためのツール、使用（消費：consume）のためのツール、変換のためのツールがある。生成のツールは自動または手動でSBOMを生成する。自動ならビルド時に生成するといいだろう。使用のためのツールは人間が分かりやすい形で表示するためのもので、SBOMとSBOMを比較するなどSBOMを読み込んで活用する。変換のツールは別のフォーマットに変換したり、複数のSBOMを統合したりする。横田氏によると多くが発展途上でデファクトスタンダードと呼べるツールはまだないとのこと。
（3）Practices and Processes
SBOMは作るだけではなく、活用方法や運用方法も定義しておく必要がある。例えばSBOMを作成する頻度やタイミングならビルドやリリース時にSBOMを新規作成するとか、SBOMを修正するタイミングなど。また推移的依存関係をどれだけ深く含めるかも大事なポイントとなる。横田氏は「悪意あるパッケージが“ない”ことを証明するには完全な網羅性が必要となります。なるべく深いところまで完全に書ききれるようなツールを使うのが大事なポイントです」と強調する。依存関係で不明なところがあれば、不明な箇所を「既知の未知」として明記しておく。
他にも必要とする人が適切なタイミングで使用できるようにする、要件に応じたアクセス制御を定めておく（ライセンスや契約などで定めておく）なども念頭においておこう。なおサプライチェーンのリスク管理は発展途上なので課題や変化には寛容でいるといいだろう。大事なのは「成熟を待つより、今日から始めること」と横田氏は言う。
SBOMを始めるならSCAも知り、DevSecOpsへと歩みを進めよう
SBOMにまつわる懸念もある。例えば「ソフトウェアに関する情報を全部さらすことにリスクはないのか？ 情報漏えいとならないのか？」がある。これについて横田氏は「ソースコードを公開するものではない」と指摘する。攻撃者にとってSBOMは頼りになる情報にはならず、SBOMを公開するかどうかも現状では任意となっている。
先にSBOMに関連するツールを挙げたが、それに近いものにSCA（ソフトウェアコンポジション解析）ツールもある。これはSBOMを作るかどうかに関係なく、ソフトウェアをスキャンして脆弱性やライセンス違反をチェックする。世の中にはさまざまなSCAツールがあり、CI/CD実行時にSCAも自動で行うように組み込むのが「基本」と横田氏は言う。
そのためSBOMを始めるにあたり、もしSCAが未着手であれば横田氏は「まずはSCAから」と勧める。SCAを使えば脆弱性診断で問題を見つけたとしても、ライブラリのバージョンを上げれば解決することも多い。脆弱性対策としてもSCAは頼もしい。
また横田氏は「SBOMの作成やSCAはソースコードではなく、成果物（アーティファクト）に実施するのが望ましい」と話す。理由として、アーティファクトは依存解決が済んでおり、ソースコードにない情報を持っているためと、またソフトウェアはビルドのたびに内容が変わる可能性があるためと説明する。
今日の話を聞いて「まだ遠い未来かな」と感じているのであれば、横田氏は「いつか必要になった時のために、せめてSBOMの存在を覚えていただけるとうれしい」と話す。SBOMはDevSecOps、つまり安全なソフトウェアを効率良く提供するために重要な要素となるからだ。開発者がソフトウェアの仕様や開発など本来やるべきことに専念できるようにするためにも、SBOMやSCAツールを取り入れることを検討してもいいだろう。
実際、横田氏も開発者時代は「セキュリティは苦手で、セキュリティ担当者を悩ませる存在だった」と明かす。「少しでもDevSecOpsを身近に感じてください」と横田氏は言う。
JFrogに2人目のデベロッパーアドボケイト、佐藤氏がジョイン
ここからは2022年6月にJFrogに2人目のデベロッパーアドボケイトとしてジョインした佐藤由久氏が加わり、横田氏と開発者の現場について対談した。佐藤氏はアプリケーション開発エンジニアやITコンサルタントなどを経験し、2017年に地元の山形にUターン。現在はリモートワークをしている。
セキュリティではなく開発メインの経験がある点では横田氏と同じ。開発者時代を振り返ると、要件定義を進めていく時に顧客からはセキュリティについての明確な条件はなく、ざっくりと「ちゃんとやってね」的な指示で終わる場合があった。そのため「これを守っていきます」と非機能要件をまとめて、提案していた。そうしたなかで役に立ったのがSCAのようなツールだったと佐藤氏は言う。
佐藤氏は「開発時にはアーティファクトを継続的に見て行くことが力になります。アーティファクトを管理し、リリース後も継続的にSCAツールなどでチェックをすることが重要です。こうした脆弱性をチェックするツールを使うことで、エンジニアの負荷を下げ、エンジニアが少しでもハッピーになるように、そして本当に力を割きたいところに力を割けるように、情報発信していこうと思います」とデベロッパーアドボケイトとしての抱負を述べた。
