オープンソースのサプライチェーンセキュリティを支えるソフトウェア部品表（SBOM）の作成
2022年3月14日
0 分で読めますこれまで以上に多くの開発者が、オープンソースソフトウェアライブラリを基盤としてWebアプリケーションを開発しています。しかし、こうしたライブラリはソフトウェア部品表（SBOM）の構成要素である一方、サードパーティ製ライブラリを含めることがオープンソースのサプライチェーンセキュリティに及ぼす大きな影響を、すべての開発者やビジネス関係者が理解しているわけではありません。そこで今回は、SBOMのセキュリティと、開発するアプリケーションについてSBOMを追跡することの重要性を解説します。
ソフトウェアサプライチェーンのセキュリティへの懸念は、組織や政府にとってますます深刻な課題となっています。欧州連合サイバーセキュリティ機関（ENISA）が発表したレポート「サプライチェーン攻撃の脅威動向」では、2021年にソフトウェアサプライチェーン攻撃が400%増加したと推定されています。
現在、開発者がオープンソースソフトウェアを幅広く利用していること、そしてソフトウェアコンポーネントを簡単に取り込めることは、セキュリティや法務上の懸念によるリスクを高めています。開発者だけでなく、ひいてはビジネスにも影響が及ぶため、開発者やセキュリティチームへの啓発と、高度なサプライチェーンセキュリティソリューションの提供が重要です。
本題に入る前に、SBOMの基本を確認し、この記事で使う技術用語を整理しておきましょう。
ソフトウェア部品表とは？
ソフトウェア部品表（SBOM）は、組織全体で使用されているすべてのソフトウェアコンポーネントを網羅した一覧です。サードパーティ製のオープンソースライブラリ、ベンダー提供のパッケージ、そして組織が開発した自社製の成果物で構成されます。
SBOMを作成する必要があるのはなぜですか？
SBOMは、アプリケーションで利用するすべてのソフトウェアコンポーネントの一覧です。SBOMがなければ、開発または利用しているソフトウェアに伴うライセンスやセキュリティのリスクを把握できません。ソフトウェア開発のスピードが速まり、コンポーネントやそのバージョンが次々と変わるなか、SBOM形式に準拠した部品表を常に最新の状態に保つことが重要です。
CycloneDXとは？
OWASP CycloneDXは、アプリケーションセキュリティやサプライチェーンのコンポーネント分析向けに設計されたソフトウェア部品表（SBOM）の標準規格で、自社製・サードパーティ製のすべてのソフトウェアコンポーネントを一覧化します。仕様は幅広く、ソフトウェアライブラリだけでなく、Software as a Serviceの部品表（SaaSBOM）や脆弱性悪用可能性情報交換（VEX）などの標準も対象としています。この標準はApache 2.0ライセンスのオープンソースプロジェクトで、次のGitHubリポジトリで共同開発に参加できます。https://github.com/CycloneDX/specification
開発者にソフトウェア部品表の管理を求めるセキュリティ上の懸念
ソフトウェア部品表という言葉は、開発者にはあまりなじみがありません。従来、これは組織のセキュリティチームやリスク評価チームが担う業務だったためです。しかし、npmパッケージレジストリに1,800,000以上の無料オープンソースパッケージが登録されていることからも明らかなように、オープンソースソフトウェアコンポーネントが急増し、状況は変化しています。
開発者として、利用するすべてのソフトウェアコンポーネントについてSBOMがなぜ必要なのか疑問に思うなら、オープンソースソフトウェアライブラリが原因で近年発生した、注目度の高いセキュリティインシデントをいくつか思い出してください。
event-stream：人気のnpmパッケージが侵害され、悪意のあるコードが混入しました。
Log4Shell：人気のJavaロギングライブラリLog4jに、深刻度の高いリモートコード実行の脆弱性が見つかりました。この脆弱性は発見されるまで7年間も存在していました。
こうしたセキュリティ脆弱性やインシデントが発見・発生したとき、アプリケーションが脆弱なバージョンを使っていたら、ライブラリをアップグレードして新しいバージョンをリリースする責任は誰にあるでしょうか？そう、開発者です。
セキュリティチームが独自に対応し、ソフトウェア部品表を管理していたとしても、問題が見つかれば関係チームに警告を発し、脆弱なバージョンをアップグレードする開発者を探すことになります。ワークフロー管理が高度化した今、こうした一連のプロセスを自動化し、開発者のワークフローに自然に組み込むことはできないでしょうか？もちろん可能です。それを実現するのが、無料で利用できるSnykです。
開発者がソフトウェア部品表の法的影響を考慮すべき理由
今日、コードを試行錯誤しながらアプリケーションを構築する開発者が、ソフトウェア利用の法的側面を意識することはあまりないでしょう。しかし、数十年前はそうではありませんでした。開発者とそのチームは、コードに取り込むソフトウェアコンポーネントの具体的なライセンスに細心の注意を払っていました。何が変わったのでしょうか？当時よく使われていたのは、GNU General Public License（GPL）などのコピーレフト型ライセンスで、ソフトウェアの配布にさまざまな制約を課していました。GPLを簡単に説明すると、影響が連鎖するため、GPLライセンスのコンポーネントを使って開発したコードは自動的にGPLライセンスになります。ビジネスモデルを構築する際に考慮すべき点です。
それから約20年が経ち、コピーレフトライセンスは大きく後退しました。2015年までに、GitHub上で作成されたオープンソースリポジトリで最も一般的なライセンスはMITライセンスになりました。MITライセンスは、ほかのライセンスと同様に許容的ライセンスの一種です。ソフトウェアの利用に関する制約が少なく、ライセンス対象ソフトウェアを使う開発者の自由度が高まります。
オープンソースソフトウェアの利用が大きく広がり、許容的なライセンスの新しいソフトウェアが次々と提供される時代を迎えています。オープンソースソフトウェアを当たり前の選択肢として使うことに慣れてしまったのでしょうか？そのライセンスを当然のものとして見過ごしてはいないでしょうか？
プロジェクト自身のライセンスに関する法的問題として、開発者の間で大きな懸念を呼んだ有名な事例が2つあります。
非常に人気の高いオープンソースJavaScriptビューライブラリであるReactは、Apache Software FoundationがFacebookのライセンスを制約が強すぎるとしてReactプロジェクトを禁止したことを受け、独自の「BSD + 特許許諾」から、許容的なMITライセンスへとライセンスを変更しました。プロジェクトを完全に離れ、Preactなどの代替案に移行しようと考える開発者が世界中で増えるなど、変更を求める声も高まりました。Quincy LarsonがこちらのfreeCodeCampの記事で経緯を時系列にまとめています。
人気の検索ツールやELK Stackを手がける企業であり、同名のオープンソースプロジェクトでもあるElasticも、クラウドベンダーとの競争激化と、それがElasticのビジネスに及ぼす影響を受けてライセンスを変更しました。
ReactやElasticなどのオープンソースソフトウェアライブラリを利用する開発者は、ライセンスの問題が発生したとき、別のプロジェクトへ移行する方法を検討する責任を負うことになるでしょう。
さらに、ネストされたコンポーネントの1つにコピーレフトライセンスが適用されているアプリケーションを構築し、ソフトウェアをリリースしてしまったらどうなるでしょうか？JavaScriptやNode.jsのエコシステムでは、多数のnpmパッケージがインストールされることで知られています。ビジネスにとって現実的なリスクであり、開発者として、プロジェクト全体でどのソフトウェアライセンスが使われているかを追跡し、把握する必要があります。
開発するアプリケーションや利用するソフトウェアには、すでに使用ライセンスの情報が含まれているかもしれません。たとえば、JavaScriptプロジェクトを構築する場合、ライセンス情報はマニフェストファイルのpackage.jsonに記載されています。
このpackage.jsonファイルに記載されているライセンスは、一般的なSBOM形式であるSPDXを使用しています。これにより、国際標準やツール間の相互運用性に準拠できます。
SPDXとは？
Software Package Data Exchange（SPDX）は、Linux Foundationの共同プロジェクトです。ソフトウェア部品表を追跡するための共通SBOM形式を提供し、さまざまなツールで相互運用可能なレポートを簡単に作成できます。具体的には、SPDX License Listに共通のライセンス識別子と各ライセンスの正式なURLが記載されています。
次のSPDX License ListのWebページでは、すべてのライセンスと識別子を確認できます。
Snykはオープンソースの監査機能を提供しており、上の表と同様に、包括的なソフトウェア監査のためのソフトウェア部品表レポートを生成します。レポートは完全にインタラクティブで、検索やフィルタリングが可能です。
開発者によるオープンソースライブラリ利用の標準化
成熟したエンジニアリング組織は、オープンソースライブラリを場当たり的・散発的に使う段階から、ガイドラインやベストプラクティスに沿って、プロジェクトで計画的・意図的に利用する段階へと進みます。
たとえばJavaScript開発チームでは、チームごとに異なる依存関係に頼るのではなく、すべての開発者が単一のHTTPリクエスト用依存パッケージを標準として使うようにしたいでしょう。npmパッケージのrequest、axios、node-fetchなどを複数使うのではなく、1つに統一するのです。理由は、オープンソースの依存関係を管理しやすくすることだけではありません。APIに関する知識や専門性を集約でき、問題のトラブルシューティングも容易になります。
開発チームで、次の質問に現実的に答えられるでしょうか？
研究開発組織のすべてのプロジェクトで、最も多く使われているオープンソースライブラリは何ですか？
利用中のオープンソースライブラリのうち、非推奨とされているものはどれですか？
プロジェクトで使っているオープンソースライブラリのうち、GPL-2などのコピーレフトライセンスが適用されているものはどれですか？
15年以上前に公開されて以来、更新されていないオープンソースライブラリはどれですか？そのことを懸念すべきでしょうか？
こうした情報をはじめ、ソフトウェア部品表（SBOM）を維持することでさまざまなメリットが得られます。Snykは、Snyk Open Sourceの機能の一環として、オープンソースパッケージの健全性に関する貴重な情報も提供します。
SBOMによってサプライチェーンセキュリティへの備えが進む理由
ソフトウェアサプライチェーンセキュリティとは？
ソフトウェア開発セキュリティライフサイクルにおける従来のアプリケーションセキュリティの対象は、開発者自身が書いたコードから、ソフトウェア構築を支える開発ツール全体へと広がっています。その結果、開発者がコードを書くために使うIDEから、アプリケーション構築に用いるオープンソースコンポーネント、さらにCI/CDパイプラインやデプロイインフラの設定に至るまで、非常に広い攻撃対象領域が生まれます。開発環境として使うコンピューターのハードウェアチップにまで、サプライチェーンのセキュリティリスクが及ぶという見方もできるでしょう。
米国商務省は、国家のサイバーセキュリティ強化に関する大統領令14028に基づく文書を発行し、そのなかで「ソフトウェア部品表（SBOM）の最小要素」に言及しています。サプライチェーンをめぐる背景をさらに見て、そこから何を学べるか考えてみましょう。
ソフトウェアサプライチェーンとは、ソフトウェアの構築に至る一連のワークフローを構成する、あらゆるコンポーネントを指します。まずは、ソフトウェアサプライチェーンと聞いて、プロジェクトに追加する依存関係だけを思い浮かべるかもしれません。それも正しいですが、ソフトウェアサプライチェーンの範囲はそれだけにとどまりません。
IDEもソフトウェア開発ワークフローに欠かせない要素ですよね。愛用しているIDEにバックドアやマルウェアが仕込まれていたら、ビジネスにどのようなリスクが生じるでしょうか。IDEの拡張機能やプラグインに重大な脆弱性があったり、悪意のあるコードが含まれていたりしたらどうでしょう。
VS Code拡張機能の脆弱性
VS Code拡張機能の脆弱性は、単なる理論上の懸念ではありません。2021年5月、SnykはVisual Studio Code拡張機能のサプライチェーンセキュリティ上の脆弱性を発見しました。VS Code拡張機能マーケットプレイスにあるこれらの脆弱性は、ダウンロード数から推定して、2,000,000人を超える開発者に影響を及ぼします。
ダウンロード数が52万件を超えるOpen in Default Browserや、12万件を超えるInstant MarkdownなどのVS Code拡張機能は、開発者にとって現実的で深刻な脅威となります。攻撃者に誘導されてリンクをクリックすると、パストラバーサルの脆弱性が持ち込まれ、開発環境内の機密ファイルや情報へのアクセスが露呈するおそれがあります。さらに深刻なケースでは、開発者がリンクをクリックするだけで、攻撃者がリモートからコマンドを完全に実行できてしまいます。
次の動画では、ソフトウェアサプライチェーンのSBOMセキュリティが開発者にとって重要な課題である理由を示します。Instant MarkdownのVS Code拡張機能が悪用され、開発者の機密SSHキーが盗まれる様子をご覧ください。
Java IDEに影響するセキュリティ脆弱性
サプライチェーンセキュリティがJavaScriptエコシステムに大きな被害をもたらしていると思われるかもしれません。そこで、わずか18か月（2020年1月から2021年7月）の間に起きたサプライチェーンセキュリティインシデント24件のENISAの年表をご紹介します。NetBeans IDEを通じてJava開発者に影響した、悪意のあるサプライチェーンセキュリティインシデントも含まれています。
安全なオープンソースSBOMを維持する
では、ソフトウェア開発ライフサイクル（SDLC）全体にわたるソフトウェアサプライチェーンセキュリティの懸念に、どのように対処すればよいのでしょうか。最新のSBOMを維持することは、取り組みの第一歩として有効です。オープンソースソフトウェアコンポーネントが企業や政府にもたらす脅威が非常に大きいため、米国政府の大統領令でも義務付けられています。
オープンソースのサプライチェーンセキュリティで重要なのは、既知の脆弱性や悪意ある行為によるゼロデイの可能性といった脅威だけではありません。パッケージ全体の健全性も重要です。プロジェクトのコミットやリリースの頻度、未解決のIssue数、プロジェクトに参加するコントリビューターのコミュニティ全体に関する指標は、パッケージの健全性スコアに反映されます。これらを参考に、プロジェクトのメンテナンス状況や、悪意ある活動の影響を受けやすいかどうかを判断できます。
Snykは、オープンソースソフトウェアのサプライチェーンセキュリティにおけるパッケージ健全性スコアの課題を解決するため、Snyk Advisorを開発しました。現在、JavaScript、Go、Pythonなどのエコシステムや、Dockerベースのコンテナイメージのメタデータに対応しています。オープンソースライブラリを探す際にぜひご活用ください。
SnykでオープンソースのSBOMを生成する
Snyk Open Sourceは、パッケージマニフェストとロックファイルをもとに依存関係グラフ全体を構築します。これにより、依存関係の階層内にある脆弱性や、非推奨パッケージなどの問題を特定できます。ただし、それだけではSBOMにはなりません。
Snykのプロダクト担当VPであるGareth Rushgroveは、SnykとSPDXによるSBOM標準の発展について執筆しました。この記事では、コミュニティのツールと連携するさまざまな方法をSnykが検討していることを紹介し、Snyk CLIの出力をSPDX形式に変換するオープンソースプロジェクトsnyk2spdxを取り上げています。
Snyk APIを活用したい方に向けて、GarethはSnyk APIを使って基となるパッケージマニフェストや脆弱性の詳細を取得し、データソースとして利用する方法も紹介しています。取得した情報はSPDXに変換できます。
まとめると、ソフトウェアの開発および提供プロセスにSBOMを組み込むことは、今日のサプライチェーンセキュリティに関する課題に取り組むうえで重要です。資産の一覧から完全性、来歴まで、さまざまな疑問への答えを得るのに役立ちます。
オープンソースのサプライチェーンセキュリティとソフトウェア部品表について理解を深めるため、以下の記事もぜひご覧ください。
Daniel Bermanによるサイバーセキュリティに関する大統領令のソフトウェアサプライチェーンセキュリティ要件を理解する
ライセンスの比較について詳しく知りたい方は、オープンソースライセンス：種類と比較のドキュメントをご覧ください。
Josepha RiverosによるSnykのライセンスポリシーで組織全体のライセンスコンプライアンスを管理する
Snykのドキュメントで、Snykプラットフォームを使ったライセンスポリシー管理の実践方法をご覧ください。
オープンソースの依存関係を安全に
開発者を第一に考えたSnykのツールなら、脆弱なオープンソースの依存関係やその推移的依存関係を、ワンクリックで修正するプルリクエストを作成できます。