Javaで書いた4行のコード、依存関係をたどると51万行に――超複雑化するソフトウェア構成、SBOMで探るには：特集：1P情シスのための脆弱性管理／対策の現実解（3）

OSSの使用リスク対処として注目を集めているSBOM。SBOMを使ってどのようにサプライチェーン攻撃対策を行えばいいのだろうか。本稿では、＠ITが開催した「＠IT ソフトウェア品質向上セミナー」の基調講演「SBOMによるサプライチェーン攻撃対策 〜自社ソフトウェアのリスク、把握していますか？〜」で語られた、OSSの使用に潜むリスクへの対処法について、要約してお届けする。

[谷川耕一，＠IT]

　＠IT編集部は2022年8月22日、デジタルイベント「＠IT ソフトウェア品質向上セミナー」を開催した。基調講演では、「SBOMによるサプライチェーン攻撃対策〜自社ソフトウェアのリスク、把握していますか？〜」と題して、JFrog Japanの横田紋奈氏（デベロッパーアドボケイト兼Java女子部・JJUG運営）が、企業におけるオープンソースソフトウェア（OSS）の使用に潜むリスクにはどのようなものがあり、それにどう対処していけばよいかについて解説した。

ソフトウェアのセキュリティで注目されるソフトウェアサプライチェーン攻撃

　SBOMとソフトウェアサプライチェーンの話題の前に、横田氏はDevSecOpsとは何かから話を始めた。DevOpsは、開発者と運用者が協力してサービスを改善していくもの。ユーザーからのフィードバックなどを受けて取り組みを繰り返し、改善を継続する。そのための考え方であり、組織として改善の文化を持つことでもある。DevSecOpsは、DevOpsにセキュリティを組み込んだもので、開発、運用にセキュリティ担当も加え、協力してサービスの改善に取り組む。

JFrog Japanの横田紋奈氏

　国内では現状、「開発」「運用」「セキュリティ」の各エンジニアの割合が、100対10対1だともいわれている。開発者に対しセキュリティ担当者は極めて少ない。一方でソフトウェアやサービスに対するサイバー攻撃は、どんどん増えている。開発者不足はよく話題になるが、セキュリティ人材不足はより深刻だ。このような状況からもDevSecOpsという考え方の元、それぞれが対立するのではなく協力し自動化などを進める考え方が不可欠となる。

　このような状況の中、ソフトウェアのセキュリティとして昨今考慮すべきことの一つがサプライチェーンだ。ソフトウェアでは、開発され本番環境にデプロイされてユーザーに届くまでの一連の流れ、工程をソフトウェアサプライチェーンと呼ぶ。そしてソフトウェアサプライチェーンのどこかで悪意のあるコードやパッケージが組み込まれることを、ソフトウェアサプライチェーン攻撃という。

　ソフトウェアサプライチェーンでは、多くの場合OSSが使われている。あるいは有償のサードパーティーのモジュールもある。便利なライブラリがあれば、それを利用するのは自然で、ソフトウェアは多くのOSSで構成されている。

　さらに使っているOSS自体にも独自のサプライチェーンがあり、別のOSSを使っていることが多く、構成しているOSSのさらに先のOSSとどんどん連鎖していく。つまり自分たちが作っているソフトウェアは、「依存を取得しビルドして使うところを何重にも繰り返した結果となります。これはすごく大事なポイントで、ソフトウェアのサプライチェーンは複雑なのです。何重にも繰り返されているサプライチェーンの1つを抜き取っても、そこにはたくさんのフェーズがあり、各フェーズにもさまざまな脅威が入り込む可能性があるのが厄介です」と横田氏。

　ソフトウェアの脆弱（ぜいじゃく）性といえば、自分の書いたコードが安全かどうかに気を取られがちだが、外部から取得しているソフトウェアが自社ソフトウェアの大部分を占めているので、サプライチェーンに着目することが大事だとも横田氏は言う。

　複雑なソフトウェアサプライチェーンの安全性を確保するのに有効なのがSBOMだ。現状、ソフトウェアの99％、エンタープライズ向けのソフトウェアでも85％にOSSが使われている。昨今発生しているサイバー攻撃のうち62％がサプライヤーへの信頼を悪用したもので、そのような攻撃は2015年から2021年までの間に6.5倍に増え、2022年にはさらに4倍に増えるとの予測もある。

　外部から取得したOSSに信頼を置きすぎて、そこに潜む脆弱性を突かれるケースは多い。自分が使っているOSSが安全か、さらにそのOSSが使っているOSSが安全かどうかまで保証できている開発者は少ない。実際、2年ほど前に米国のSolarWindsがソフトウェアサプライチェーン攻撃を受け、他の大企業や政府関連のソフトウェアにも影響を与える大きな騒ぎとなった。また2021年のクリスマス前後には、Javaのロギングライブラリである「Log4j」の脆弱性が判明。対応に追われた企業は多い。

　ソフトウェアの中でコードやモジュールの依存関係が何重にも連鎖していることを、推移的依存関係と呼ぶ。この推移的依存関係を網羅した状態で、自分が使っているOSSが安全であるかどうかを確認する必要があるのだ。例えば、Javaで4行だけプログラムコードを書いて極めて小さなアプリケーションを作ったとする。フレームワークを使いそのコードの依存関係を解決したら、最終的には51万行を超えるコードとなっていたとの話もある。OSSのライブラリなどを使っていれば、自分が把握していないコードが大量に存在する可能性がある。開発効率化のためにはOSSを使いたい。OSSを使った上で、安全性をどう保証できるかが重要だと横田氏は指摘する。

SBOMはソフトウェアが安全であることの保証に使える

　OSSに脆弱性が見つかった際に、自分のソフトウェアが大丈夫かどうかを把握できるようにするのがSBOMだ。SBOMは"Software Bill Of Materials"の略で「ソフトウェア部品表」と訳される。ソフトウェアを構成するコンポーネントとその特徴を書いたメタデータの一覧がSBOMだ。SBOMはソフトウェアの成分表であり、何が含まれているかをドキュメント化し分かるようにする。脆弱性管理以外にも、資産やライセンスコンプライアンスの管理、知的財産、インシデントレスポンスにも活用できる。

　ソフトウェアの中身を分析し人間にも分かる形にして、管理できるようになっているのがSBOMだ。SBOMがあれば、ソフトウェアが安全であることの保証に使える。SBOMでは、依存していたり使用していたりするOSSかサードパーティーのライブラリから、アドオンやプラグイン拡張などのソフトウェアが動くのに必要なものを全て、さらに自分たちが書いたコードの情報、サービスの場合はAPIやサードパーティーサービス情報なども含め部品表にまとめる。

　SBOMは、以下の3つの最小要素から構成される。

データフィールド（Data Fields）

　成分表の内容に当たるもので記録管理する情報を明確に文書化する。

オートメーションサポート（Automation Support）

　SBOMの生成も使用も自動化できるようにする。

プラクティス・プロセス（Practices and Processes）

　ベストプラクティス集のようなもの。SBOMを使いどういうオペレーションすべきかの指針。

　データフィールドは実際のSBOMのファイルで、SBOM自体の情報とソフトウェアの情報の2つに分かれる。前者は、どのような形式で書かれたドキュメントか、いつ誰が作ったかなどドキュメント自体のプロファイルなどが記載される。どのようなコンポーネントが含まれているかの部品表の部分もある。コンポーネントの名称、バージョンなども記載され、名前とバージョンがあればおおむね一意に識別でき、その識別キーも記載される。依存関係となるリレーションシップの情報もあり、"CONTAINS"というキーワードでコンポーネント同士をつなげて記載することでどのソフトウェアを含んでいるかが分かる。

データフィールドの例（講演資料から引用、参考文献を元に横田氏作成）

　SBOMの代表的なフォーマットがSPDX、SWID、CycloneDXだ。SPDXは国際標準として認められており今後はこれを使うケースが多くなると横田氏は語る。フォーマットはさまざまな形式で作ることができ、コロンでつないでいるキー値の形（Tag:value）は、SPDX独自のフォーマットだ。他にもJSONやXMLなどでも記載できる。「大事なのは人間が目で見てある程度把握でき、自動化する際に機械で読み取りやすいことです」（横田氏）

　自動化のためのツールには幾つか種類がある。ソフトウェアを解析し、SBOMを出力するツールや、出力した結果を解析するツール、SBOMを運用するためのツールもある。SBOMはまだ歴史も浅く発展途上であり、それぞれデファクトスタンダードと呼ばれるようなものはまだないという。

　プラクティス・プロセスは、ベストプラクティスを集めたものだ。これはSBOMを作る頻度として、ビルドやリリースの工程を経てソフトウェアが更新される度に作成すべきとされており、推移的依存関係も含め全てを記載する。脆弱性に対する安全性を証明するには、全てを網羅的に書き出す必要があるのだ。

SBOMを活用するためにまずは組織のカルチャーを変える

　SBOMはソフトウェアの中身を全部書き出すので、情報漏えいになるのではとの懸念がある。しかし、SBOMはソースコードや知的財産をそのまま公開するわけでなく、何を使っているかの情報にすぎない。SBOMを使った攻撃のリスクよりもソフトウェアの安全性を把握するメリットの方が大きい。もう1つ、SBOMが嘘（うそ）をついていたらどうするのかとの懸念もある。これについては発行するSBOMに署名することで解決できるという。

　SBOMを作るにはソフトウェアを分析しなければならない。これにはソフトウェアコンポジション解析（SCA）を行う。ソフトウェアをスキャンし脆弱性やライセンス違反などを調べるのだ。SCAのツールは既にさまざまなものが流通しており、それらをCI/CD（継続的インテグレーション／継続的デリバリー）の実行の際にライフサイクルとして組み込むのがベストプラクティスだ。「CI/CDのパイプラインにSCAツールのAPIをたたくステップを入れてあげるだけで、すぐに分析を始められます」と横田氏は言う。

　SCAに限らず、さまざまなセキュリティのチェックは、自動でパイプラインに組み込むことが望ましい。セキュリティ対策でしばしば「シフトレフト」といわれるもので、なるべく早い段階でセキュリティの対策をするために、左から右に進むプロセスにおいてセキュリティチェックを左側に寄せるという考え方だ。リリース直前にチェックすれば、問題がそこで一気に噴出し対応が大変になる。細かい単位でビルドする度に自動でチェックすれば、細かい修正対応のみで事足りる。

（講演資料から引用）

　SCAを適用する際には、JFrogのDevOpsプラットフォームであるArtifactoryなどが有効だ。Artifactoryでは、ソースコードをビルドした後のバイナリファイルやコンテナイメージをソースコードとは別の専用リポジトリで、メタデータとともに管理できる。依存解決の際に脆弱性が紛れ込む恐れを考えると、きちんと依存解決が進んだ状態のソフトウェア、すなわちArtifactoryに対しSCAの適用やSBOM生成の解析をすることが望ましいのだ。

　SBOMを活用するには、組織のカルチャーを変えていく必要がある。組織全体でDevSecOpsに理解を示し、コミュニケーションやコラボレーションを活発にできる環境が必要となる。そして成功も大事だが失敗を認めフィードバックを繰り返すのも重要だ。「失敗を批判したり誰かのせいにしたりするのではなく、組織としてどうすべきだったのか、次につなげられる議論のできる環境が必要です」と横田氏は言う。

　すぐにSBOMを作ろうとの動きになる組織もあれば、そうではない組織もあるだろう。今の対策が不十分だと感じられているならば、まずは何かを変えるところから始める。組織として取り組むのがベストだが、それに時間がかかるような場合には、自分自身が変わることも大事だ。今日のセッションを聞き、何か行動を起こすきっかけが生まれたらうれしいと、横田氏は締めくくった。

特集：Log4j 2、クラウド設定ミスだけじゃない―1P情シスのための脆弱性管理／対策の現実解

Log4j 2の件を端に、再び世間を騒がせたソフトウェアの脆弱性問題。だが、もともと脆弱性というものは、OSSに限らず、商用ソフトウェア、ルーターやメモリなどのハードウェアと、あらゆるところに存在する。パッチを当てるなどの対策を施しても、減るどころか日々新たな脆弱性が発見されて増え続けるような報道が後を絶たない。むしろクラウドの設定ミスやコーディングミス、テスト不足など、人が新たな脆弱性を次々と作り出しているといっても過言ではない。人手が足りない企業の情報システム部門は日々の安定運用に手いっぱいで、脆弱性を管理して対策を講じるところまで頭が回らないのが実情ではないだろうか。本特集では、脆弱性を取り巻く現状を改めて整理し、今の時代に即した脆弱性管理／対策の在り方を探る。

特集：Log4j 2、クラウド設定ミスだけじゃない―1P情シスのための脆弱性管理／対策の現実解