SBOM (ソフトウェア部品表) を作成してオープンソースサプライチェーンのセキュリティを高める

近年、Web アプリケーションの開発でオープンソースのソフトウェアライブラリを基盤にする開発者が増加しています。ただし、これらのライブラリは SBOM のコンポーネントインベントリを構成していますが、開発者やビジネス関係者の全員が、サードパーティライブラリを含めることでオープンソースサプライチェーンのセキュリティに生じる重大な影響を理解しているわけではありません。これを念頭に置いて、SBOM セキュリティに関するトピックと、開発中のアプリケーションで追跡管理する重要性について考えてみましょう。

ソフトウェアサプライチェーンのセキュリティに関する懸念は、組織や政府にとってますます深刻なジレンマとなっています。欧州連合サイバーセキュリティ機関 (ENISA) が発行した報告書「Threat Landscape for Supply Chain Attacks」では、2021 年にソフトウェアサプライチェーンへの攻撃が 400% 増加すると推定されています。

近年、開発者に利用できるオープンソースソフトウェアの数が増え、ソフトウェアコンポーネントをインポートしやすくなったことで、開発者、ひいては企業にとっても、セキュリティや法的な懸念によるリスク要因が増加しました。そのため、開発者やセキュリティチームを教育し、高度なサプライチェーンのセキュリティソリューションを提供することが重視されています。

その前に、SBOM の基本について説明し、この記事で使われている専門用語の意味を明確にしておきましょう。

ソフトウェア部品表とは

ソフトウェア部品表は、多くの場合 SBOM と呼ばれ、組織全体で使用されるすべてのソフトウェアコンポーネントを網羅したリストです。ソフトウェア部品表は、サードパーティのオープンソースライブラリ、ベンダー提供のパッケージ、および組織が開発したファーストパーティのアーティファクトで構成されます。

SBOM の作成が必要な理由

SBOM は基本的に、アプリケーションで使用するすべてのソフトウェアコンポーネントの目録となります。これがないと、開発中または使用中のソフトウェアに関連するライセンスやセキュリティリスクを可視化できません。コンポーネントやそのバージョンが目まぐるしく変わるソフトウェア開発に対応するためにも、最新の SBOM 形式に準拠したソフトウェア部品表を維持することが重要です。

CycloneDX とは

OWASP CycloneDX は、アプリケーションセキュリティのコンテキストとサプライチェーンのコンポーネント分析のために設計された SBOM (ソフトウェア部品表) の標準規格です。すべてのファーストパーティおよびサードパーティのソフトウェアコンポーネントのインベントリを提供しています。仕様は豊富で、ソフトウェアライブラリにとどまらず、SaaSBOM (Software as a Service Bill of Materials) や VEX (Vulnerability Exploitability Exchange) などの規格に拡張されています。この規格は Apache 2.0 ライセンスのオープンソースプロジェクトで、次のオープンソース GitHub リポジトリで共同利用が可能です。https://github.com/CycloneDX/specification

開発者にソフトウェア部品表の維持を求める場合のセキュリティ上の懸念

ソフトウェア部品表という言葉は、開発者の心に響く言葉ではありません。従来それは、組織のセキュリティ部門やリスク評価チームの活動にのみ用いられていたためです。ただし、180 万種類以上のフリーオープンソースパッケージを網羅する npm パッケージレジストリに見られるように、オープンソースソフトウェアのコンポーネントの著しい増加により状況は変わってきています。

使用するすべてのソフトウェアコンポーネントで SBOM が必要な理由について、開発者として疑問に感じているなら、近年オープンソースソフトウェアライブラリが原因で発生した、注目を集めたいくつかのセキュリティインシデントを思い出していただければと思います。

1. event-stream: 一般的な npm パッケージが侵害され、悪意のあるコードが組み込まれてしまいました。

2. Log4Shell: 一般的な Java ログライブラリ Log4j には、重大度の高いリモートコード実行の脆弱性があることが判明しています。この脆弱性が発見されるまで実に 7 年間もかかっています。

これらのセキュリティ脆弱性やセキュリティインシデントが発見されたり、問題が発生したりした場合、アプリケーションでこれらの脆弱なバージョンのいずれかを使用している場合、これらのライブラリをアップグレードして新しいバージョンをプッシュする責任があるのは誰だと思われますか。そうです、開発者の皆さんです。

たとえセキュリティチームが独自にソフトウェア部品表を管理していたとしても、問題を発見したら、フラグを立て、関係するチームに報告し、脆弱性のあるバージョンをアップグレードする開発者を探す必要があります。ですが、これだけワークフロー管理が進んでいるのなら、このプロセス自体を自動化して、開発者のワークフローにもっとネイティブに統合できないのでしょうか。もちろん、できます。Snyk はそのために開発されました。しかも無料でお使いいただけます。

開発者がソフトウェア部品表の法的影響に注意すべき理由

現在、開発者がコードを調整し、アプリケーションを開発する際に、ソフトウェア利用における法的な面について考えることは、おそらくないでしょう。しかし、数十年前はそうではありませんでした。開発者やスタッフは、コードに取り込まれたソフトウェアコンポーネントの特定のライセンスを非常に気にしていました。何が変わったのでしょうか。当時は、GNU の GPL (General Public License) に代表されるコピーレフトタイプのライセンスが主流で、ソフトウェアの配布にいくつかの制限がありました。GPL の TL;DR にはカスケード効果があり、GPL ライセンスのコンポーネントを使用して開発されたコードは、自動的に GPL ライセンスのコンポーネントになります。これはビジネスモデルを構築する際に考慮すべき点です。

20 年ほどかけて、コピーレフトライセンスから大きな進歩を遂げました。2015 年までに、GitHub で作成されたオープンソースリポジトリで最もよく使用されているライセンスは、MIT ライセンスになりました。他のライセンスと同様に、MIT は寛容なライセンスのファミリーに属しています。これにより、ソフトウェアの使用方法に関する多くの制限が取り除かれているだけでなく、ライセンスされたソフトウェアを使用することで開発者の自由度が高まっています。

私たちは、オープンソースソフトウェアの歴史の中で、ライセンスポリシーが非常に寛容なソフトウェアの普及と新しいコントリビュートソフトウェアの大幅な成長を目の当たりにしています。普段、デフォルトのソフトウェアとしてオープンソースソフトウェアを使っているでしょうか。オープンソースソフトウェアのライセンスを当然のものとして考えているでしょうか。

プロジェクト独自のライセンス使用に関するソフトウェアの法律上の問題では、開発者たちの間で中心的な役割を果たしてきた 2 つのケースが非常によく知られています。

1. オープンソースの JavaScript ビューライブラリとして絶大な人気を誇る React は、Apache Software Foundation が Facebook のライセンスを制限しすぎるとして React プロジェクトを禁止したため、ライセンスが独自バージョンの「BSD + Patents grant」から寛容な MIT ライセンスにライセンスが変更されました。これには、プロジェクトを完全に捨てて、Preact プロジェクトなどの代替案に移行することを検討していた、世界中の開発者たちからも圧力がかけられました。クインシー・ラーソン氏 (Quincy Larson) は、以下の freecodecamp の記事でイベントのタイムラインを公開しています。

2. 人気のある検索ツールと ELK Stack の同名の会社でありオープンソースプロジェクトの Elastic も、クラウドベンダーとの競争の激化や Elastic のビジネスに対する影響を受けて、ライセンスの変更に対処する必要がありました。

React や Elastic などのオープンソースソフトウェアのライブラリを使用する開発者は、ライセンス問題が発生した際に、あるプロジェクトから別のプロジェクトへの移行を考慮する必要があります。

さらに、アプリケーションを開発し、その中のコンポーネントの 1 つのソフトウェアにコピーレフトのライセンスがある状態でソフトウェアを出荷することになったらどうなるでしょうか？JavaScript と Node.js のエコシステムは、インストールされる npm パッケージの数が多いことで知られています。ビジネスに対するリスクは極めて現実的なため、開発者としてはプロジェクト全体でどのソフトウェアライセンスが使用されているかを追跡して把握できるようにしておく必要があります。

開発中のアプリケーションや使用中のソフトウェアには、利用中のライセンスの参照がすでに含まれている可能性があります。たとえば、JavaScript プロジェクトを開発する場合、ライセンス情報は package.json マニフェストファイルに含まれています。

1{
2  "name": "snyk",
3  "version": "1.0.0-monorepo",
4  "description": "snyk library and cli utility",
5  "files": [
6    "help/cli-commands",
7    "dist",
8    "bin",
9    "pysrc",
10    "config.default.json",
11    "SECURITY.md",
12    "LICENSE",
13    "README.md"
14  ],
15  "author": "snyk.io",
16  "license": "Apache-2.0",

この package.json ファイルに記述されているライセンスは、SPDX と呼ばれる共通の SBOM 形式を使用して、ツール間の国際規格や相互運用性に適合していることを確認しています。

SPDX とは

Software Package Data Exchange (SPDX) は Linux Foundation の共同プロジェクトです。ソフトウェア部品表を追跡するための共通の SBOM形式規格を提供し、さまざまなツールで相互運用性レポートの作成を容易化します。具体的には、SPDX ライセンスリストにより、共通のライセンスリスト識別コードと、各ライセンスへの正規の URL が提供されます。

以下の SPDX ライセンスリスト Web ページには、すべてのライセンスとその識別コードの完全なリストが掲載されています。

Snyk はオープンソースの監査機能を提供しているため、上記の表と同様に、ソフトウェア部品表レポートを生成し、完全にインタラクティブで検索可能、かつフィルタリングが可能な包括的ソフトウェア監査を確立できます。

オープンソースライブラリ利用時における開発の標準化

成熟したエンジニアリング企業のプロジェクトでは、オープンソースライブラリの利用は、都合に合わせた不定期的な利用から、ガイドラインとベストプラクティスに従う、意図的かつ計画的な利用に移行しています。

たとえば、JavaScript の開発チームは、異なるチームの開発者が、npm package request、axios、node-fetch などの多数の依存関係に依存するのではなく、選択した 1 つの HTTP リクエスト依存関係を使用するようにして標準化したいと考えることもあるでしょう。その理由は、オープンソースの依存関係を管理しやすくすることに限られません。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 はダウンロード数ベースで 200 万人以上の開発者に影響を及ぼす VS Code 拡張機能マーケットプレイスで Visual Studio Code 拡張機能にサプライチェーンセキュリティの脆弱性を発見しました。

52 万ダウンロードを超える Open in Default Browser や 12 万ダウンロードを超える Instant Markdown など、これらの VS Code 拡張機能は、開発者にとって現実的かつ真の脅威となっています。開発者がハッカーにだまされてリンクをクリックさせられた場合、開発環境で機密ファイルや情報へのアクセスを公開するパストラバーサルの脆弱性が導入される可能性があります。より重大な脆弱性が存在するケースでは、開発者がリンクをクリックするだけで、ハッカーが完全にリモートコマンドを実行できるようになります。

次のビデオは、ソフトウェアサプライチェーンの SBOM セキュリティがなぜ開発者にとって重要な問題であるか、また Instant Markdown VS Code 拡張の攻撃により、開発者から秘密の SSH キーが盗み出される方法について説明しています。

JAVA IDE に影響するセキュリティの脆弱性

サプライチェーンセキュリティが JavaScript のエコシステムにもたらしている大打撃については、ENISA の 24 件のサプライチェーンセキュリティインシデントのタイムラインをご覧ください。これは 18 か月間 (2020 年 1 月から 2021 年 7 月) の期間で発生しており、その中には NetBeans IDE を通じて Java 開発者に影響を与えた悪意のあるサプライチェーンセキュリティの事例も含まれています。

安全なオープンソース SBOM を維持する

では、ソフトウェア開発ライフサイクル (SDLC) 全体で、ソフトウェアサプライチェーンのセキュリティに関する懸念を軽減するにはどうしたらいいでしょうか。最新の SBOM を維持することは良いスタートを切るのに役立つだけではありません。オープンソースのソフトウェアコンポーネントが企業や政府にもたらす脅威の現状を考慮した米国政府の大統領令によって義務付けられてもいます。

オープンソースのサプライチェーンセキュリティでは、既知のセキュリティ脆弱性や悪意のある行為の潜在的なゼロデイに起因するセキュリティ脅威の状況だけでなく、パッケージ全体の健全性も重要な点です。プロジェクトのコミットとリリースの頻度、未解決の問題の数、およびプロジェクトに関与するコントリビューターの全体的なコミュニティに関連するシグナルはすべて、パッケージ全体の健全性スコアに貢献し、プロジェクトの全体的なメンテナンスと悪意のある活動の影響を受けやすいかどうかに関する指針を提供することになります。

Snyk がオープンソースソフトウェアのサプライチェーンセキュリティについて、Snyk Advisor を開発したのは、パッケージ健全性スコアのまさにこの問題を解決するためです。現在、JavaScript、Go、Python、Docker ベースのコンテナイメージなどのエコシステムのメタデータがサポートされています。オープンソースライブラリを探す際には、ぜひこれを参照してください。

Snyk でオープンソース SBOM を生成する

Snyk Open Source はパッケージマニフェストとロックファイルと連動して完全な依存関係グラフを作成し、階層内の脆弱性や非推奨のパッケージなど、その他の問題を特定できます。ただし、それ自体は SBOM ではありません。

Snyk の製品担当副社長のガレス・ラッシュグローブ (Gareth Rushgrove) は、Snyk と SPDX による SBOM 規格の推進という記事を寄稿しています。この記事でガレスは、Snyk がコミュニティツールと連携する方法をいくつか模索していることについて説明し、Snyk CLI の出力を SPDX 形式に変換するオープンソースプロジェクト、snyk2spdx を紹介しています。

お望みなら Snyk API を活用して基盤となるパッケージマニフェストと脆弱性の詳細を消費ソースとして取得し、SPDX に変換する方法もガレスは提案しています。

要約すると、ソフトウェア開発およびデリバリープロセスの一環として SBOM の作成を義務付けることは、今日のサプライチェーンのセキュリティに関する重要な問題です。インベントリから完全性、来歴まで、あらゆる質問に答えることができます。

オープンソースやソフトウェア部品表におけるサプライチェーンのセキュリティに関する知識をさらに深めるため、以下の記事をぜひお読みください。

• サイバーセキュリティに関する大統領令におけるソフトウェアサプライチェーンのセキュリティ要件を理解する ダニエル・バーマン (Daniel Berman) 著

• ライセンス比較の詳細については、オープンソースライセンス: 種類と比較のドキュメントをご覧ください。

• Snyk のライセンスポリシーを使用して組織全体のライセンスコンプライアンスを管理する ジョセファ・リベロス (Josepha Riveros) 著

• Snyk のドキュメントを通じて、実用的な Snyk プラットフォームでのライセンスポリシー管理について学びましょう。