オープンソースセキュリティについて

過去数年間にわたり、共同作業が可能で、公開的な性質を持つオープンソースソフトウェアは広く普及してきましたが、これは開発者にも悪意あるアクターにも都合のいいものでした。アプリケーションが公に知られている脆弱性にさらされていることを発見したハッカーは、そのオープンソースコードを使用して開発された他のアプリケーションを攻撃することができます。Log4j や Apache Struts の脆弱性のような事例は、これが組織にとって現実的で、時に深刻なリスクとなることを示しています。

このリスクを軽減するためには、オープンソースのコンポーネントと依存関係を管理することが不可欠です。しかし、アプリケーション内で使用されているすべてのオープンソースコンポーネントの可視化は難しく、オープンソースコンポーネントを既知の脆弱性データベースと手動で照合するのには手間がかかります。開発者が作成するコードだけでなく、開発者が利用するオープンソースコードやそのコード内の依存関係のセキュリティを確保する必要があるため、依存関係のネストにより問題がさらに複雑になります。

この記事では、オープンソースセキュリティを定義し、オープンソースソフトウェアに関係するリスクを詳しく検証し、オープンソースソフトウェアを利用する企業がリスクを軽減するために使用できるツールやプロセスについて紹介します。

オープンソースセキュリティとは

オープンソースセキュリティとは、サードパーティソフトウェアに付随するリスクや脆弱性、およびオープンソースソフトウェアのセキュリティを確保するために使用するツールやプロセスのことをいいます。セキュリティツールでは、コードのオープンソースライブラリや依存関係を自動的に検出し、コンポーネントがアプリケーションでどのように使用されているかを分析し、脆弱性が検出された場合にはアラートや対策をトリガーすることができます。二要素認証などの対策により、脆弱性に起因するインシデントから保護する別のセキュリティレイヤーが追加されます。

オープンソースソフトウェアの 4 つのメリット

ビジネスの需要により、ソフトウェアの開発とリリースのサイクルが加速化しています。このような需要に対応するため、開発者は社内で開発したコードを補強する目的でオープンソースソフトウェアを利用することが多くなっています。

人気の理由はいくつかあります。

1. コスト:ソフトウェア開発者は、パブリックドメインのオープンソースソフトウェアを自由に使用、変更、共有することができ、世界中の開発者とボランティアのコミュニティがソフトウェアのメンテナンスに取り組んでいます。商用オープンソースソフトウェアパッケージでも、カスタム開発コードをゼロから作成するコストと比較すれば安価になります。

2. 使いやすさ:事前に開発され、公開されているオープンソースソフトウェアの性質により、開発者は以前に作成されたコードを使用して特定のニーズに対応することが可能です。そうすることで、価値の高いタスクに取り組む時間を確保できます。

3. 品質:オープンソースコードを開発し、利用し、検査する開発者のコミュニティが存在するため、理論的には、脆弱性がすばやく発見され、対処されることにより、バグは少なくなるとされています。

4. スピード:オープンソースソフトウェアを使用することで、開発者は価値あるビジネスアプリケーションをすばやく市場に投入できます。

一部のケースでは、オープンソースソフトウェアの採用数は 2 倍以上に増え、開発者に規模の経済の恩恵をもたらしています。これは、利用可能なツールが増え、市場には優れた訓練を受けた開発者が参入しているからです。同時に、公開性と脆弱性、機敏性と品質はトレードオフの関係にあります。

図 1: エコシステムによって毎年作成される新しいパッケージ

オープンソースソフトウェアを使用することは、アプリケーションが依存するコードのメンテナンスを知らない人々に頼ることを意味します。そのため、潜在的なマイナス面を最小限に抑えるためにシステムやツールを使用することが重要です。

オープンソースソフトウェアセキュリティの 3 つのリスク

ほぼすべてのクラウドネイティブアプリがオープンソースのコンポーネントに依存しています。ただし、メンテナンスやセキュリティについては誰も責任を負わないため、オープンソース ソフトウェアには以下のようなリスクが伴います。

1.オープンソースの依存関係における脆弱性

これには既知の脆弱性と未知の脆弱性の両方が含まれます。既知の脆弱性には、共通脆弱性識別子 (CVE) 番号が割り当てられたもの、インターネット上で開示されたもの、公開された脆弱性データベースで共有されたもの、および非公開の脆弱性データベース内のものが含まれます。一般に、脆弱性の知名度が高くなるほど、緊急に対処する必要性が高まります。

脆弱性の追跡だけでなく、アプリケーション内のすべてのオープンソースの依存関係を追跡することも重要です。他の依存関係に依存する「推移的依存関係」は、セキュリティツールや監査では見えにくいため、特に懸念される分野です。それで、アプリケーションのすべての依存関係を特定し、監査できるツールやプロセスを活用することが役立ちます。

2.ライセンスコンプライアンスのリスク

開発者は使用するオープンソースパッケージの各種のソフトウェアライセンスについて理解し、ライセンスに準拠してコードを使用する必要があります。ライセンス条項を認識し、適用することはプロジェクト全体を通して求められます。オープンソースライセンスを適用するには、オープンソースのコンポーネントがどのように使用されているかを詳細に把握する必要があります。また、著作権者がライブラリのライセンスを変更した場合に備えて、ライセンスを継続的にモニタリングすることも重要です。

3.メンテナンスされていないオープンソースパッケージ

オープンソースのパッケージは、メンテナンスされているとしても、通常は一人の開発者または少人数のチームによってメンテナンスされています。コミュニティオープンソースプロジェクトの開発者は、ソフトウェアのメンテナンスに対する義務はなく、「現状のまま」提供されます。 したがって、コードの安全性を確保するために時間とリソースを費やすのはユーザーの責任になります。幸いにも、このプロセスを簡素化できる Snyk Advisor などの便利なツールがあります。これらのツールは、メンテナンスレベル、コミュニティ、セキュリティ態勢、人気度によってパッケージを分析し、使用しているオープンソースパッケージの健全性を評価するのに役立ちます。

オープンソースソフトウェアのリスクについてもっと詳しく知りたいですか？オープンソースソフトウェアに潜む 5 つのリスクという記事をご覧ください。

オープンソースの現状レポートの主要な統計

データは知識です。Snyk は、開発者やセキュリティ専門家を対象に、オープンソースのセキュリティに関する懸念、パッケージやコンテナイメージの脆弱性の傾向、メンテナや組織がソフトウェアのセキュリティ確保に採用している方法などについて調査しました。私たちは、2020 年のオープンソースセキュリティの現状レポートで調査結果を発表しました。レポートからの重要なポイントをいくつか紹介します。

オープンソースの導入が進んでいる

オープンソースのエコシステムは、市場の需要とビジネスの現実が相まって、継続的に拡大しています。首位は npm で、前年比 33% 以上の伸びを示し、2022 年 3 月時点で 180 万パッケージとなっています。オープンソースソフトウェアの脆弱性の大半は、間接的な依存関係で見つかっています。

• npm:86%

• Ruby:81%

• Java:74%

オープンソースセキュリティ文化は開発者にシフト

調査によると、セキュリティは複数の部門で責任を共有すべきであると考えていることが示されています。

• オープンソースセキュリティで開発者に責任があると感じている人は 85%

• セキュリティチームに責任があると感じている人は 55%

• 業務部門に何らかの役割があると感じている人は 35%

脆弱性の傾向

新たな脆弱性は全体で 20% 減少し、クロスサイトスクリプティング (XSS) の脆弱性が最も多く報告されました。

図 2: 2014 年以降にエコシステムで特定された脆弱性

コンテナおよびオーケストレーションの課題

最新版としてタグ付けされた公式ベースイメージには、既知の脆弱性が含まれていることが多く、特に公式ノードイメージには 700 件近くの既知の脆弱性が含まれています。回答者の 30% 以上は、Kubernetes のマニフェストに安全でない設定がないかを確認しておらず、Kubernetes のセキュリティ関連リソースコントロールの要件は広く実装されているとは言えません。

図 3: 公式コンテナイメージの脆弱性

2022 年のオープンソースセキュリティのトレンド

過去 1 年間で、オープンソースセキュリティに関連するいくつかのトレンドが話題となっています。それには、サプライチェーンのセキュリティ、責任に関する文化的な変化、新たに発見された脆弱性の減少、無報酬のオープンソースメンテナーへの依存、および脆弱性の修復に関する期待の変化が含まれます。

サプライチェーンセキュリティに対する攻撃が頻度を増している

サードパーティのソフトウェアコンポーネントは、一元管理されたリポジトリに存在し、ソフトウェアサプライチェーンを構成しています。このサプライチェーンは攻撃ベクトルとしては魅力的な対象となります。ハッカーはソフトウェアリポジトリを変更する必要がなく、開発パイプライン内の脆弱なポイントを攻撃することができるからです。たとえば、依存関係/名前空間の混乱を利用した攻撃で設計上の欠陥を突いたり、サードパーティのコンポーネントを悪用してユーザーデータを漏洩させたり、内部システムにアクセスしたりするなどできます。

リンクの一つひとつが潜在的な攻撃ベクトルとなるため、ソースコードからデプロイメントまでのサプライチェーンのセキュリティを確保することが重要です。サプライチェーンの脆弱性は新しい問題ではありませんが、2021 年に注目を集め、バイデン大統領が発令したサイバーセキュリティに関する大統領令でも取り上げられました。

企業文化がセキュリティの責任を共有する方向にシフトしている

セキュリティの責任は誰が負うのでしょうか。これまで見られている最も好ましいトレンドの一つは、開発者、セキュリティ、業務のチームがそれぞれ責任を共有する方向に動いていることです。

DevSecOps へのアプローチの移行は良い傾向ですが、回答者の 47% は、責任の共有を促進するための具体的なプログラムがないと答え、OWASP Software Assurance Maturity Model（SAMM） で主要なセキュリティプラクティスとして定義されているセキュリティチャンピオンプログラムを実施したと回答した人はわずか 15% でした 。これは、責任共有の認識から実践の間で橋渡しの必要性があることを示しています。

Puppet の「DevOps の現状」 レポートによると、組織が DevOps の対策を成熟させるにつれて、セキュリティ対策も成熟することが分かっています。

「DevOps の対策が向上すると、DevSecOps も自然にそれに従います。高度な進化を遂げている組織では、大半がセキュリティをシフトレフトさせ、セキュリティを要件 (51%)、設計 (61%)、ビルド (53%)、テスト (52%) に統合しています。一方、ほとんどの中堅組織では、本番環境の監査が予定されているとき (48%)、本番環境で問題が報告されたとき (45%) に、セキュリティ部門が関与しています」

2021 年 Puppet の DevOps の現状レポート

脆弱性の発見が減少している

この調査からは、新しい脆弱性は全体として 20% 減少しているという驚くべき発見が報告されました。オープンソースのエコシステムが爆発的に成長している今、この傾向は特に注目に値します。

オープンソースの脆弱性の発見が減少している理由について明確な理由はありませんが、一部のエコシステムでは 2 倍以上の増加が見られています。これは、セキュリティ意識、対策、およびツールの改善が成果を上げていることを示唆しているかもしれません。

私たちは引き続きこの傾向に注目していきますが、セキュリティコントロールや対策に関して安心するのはまだ時期尚早です。

オープンソースのメンテナーが企業に反感を抱いている

オープンソースのメンテナーの側では、企業や組織が自分たちのソフトウェアを利用して製品を商業化しているにもかかわらずメンテナンスにお金を払っていないため、不満がさらに高まることが予想されます。

2021 年にオープンソースのメンテナー 400 人を対象として Tidelift が行った調査では、46% のメンテナーがまったく報酬を得ておらず、メンテナンス作業で年間 1,000 ドル以上の報酬を得ていたのはわずか 26% だったことが明らかになりました。半数以上 (59%) がメンテナンスを辞めたか、辞めようと考えたことがあり、約半数がメンテナンスが嫌になった理由のトップに金銭的報酬がないことを挙げています。

この感情は実世界に影響を及ぼしています。たとえば、2022 年 1 月、広く使用されている npm パッケージ colors のメンテナーが問題のあるコードを導入し、無限ループを引き起こしてパッケージの使用を妨げる事態が発生しました。

破損したバージョンの colors は、95,000 件以上ダウンロードされています。colors は、毎週最大 50 万件がダウンロードされている prompt コマンドラインヘルパーや、毎週最大 200 万件がダウンロードされている AWS 独自の aws-cdk など、他にも複数のプロジェクトで使用されており、重大な懸念が生じています。

また、同じ人物がメンテナンスを行っている人気の npm パッケージ faker でも同様の事態が生じ、多数のフォーチュン 500 企業で使用されているプロジェクトを今後は無料でメンテナンスしないとメンテナーが宣言し、物議を醸しています。

脆弱性対策のタイミングが遅い

2020 年オープンソースセキュリティの調査によると、回答者の 47% は脆弱性の発見から 1 週間以内の修正を期待しており、18% 近くは 1 日以内の修正を期待しています。

図 4: オープンソースの脆弱性修正に期待すること

実際には、スキャンされたプロジェクトの脆弱性のうち 20 日以内に修正されたのは 35% にとどまり、36% については修正に 70 日以上かかり、平均日数は 68 日となっています。

組織が、リスク対応態勢に関する期待を管理する必要があることは明らかです。個々の貢献者がコードのメンテナンスに責任を持っている場合、オープンソースの脆弱性修正のための SLA (サービスレベル契約) に注意する必要があります。

オープンソースのセキュリティ戦略の重要指標

まずは、使用するライブラリのオープンソースセキュリティの指標の追跡に注意を払うことから始めましょう。以下のような指標について考慮します。

• 脆弱性が検出されてから修正されるまでの日数

• 問題が報告されてからプルリクエストをマージするまでの平均時間

• 自分でコードを修正するのに必要な時間

上記について検討することで、利用中のパッケージのセキュリティ問題に対する可視性が向上し、コンポーネントの管理および脆弱性の検出や対処のための戦略を立案できます。

さらに、使用するオープンソースパッケージを積極的に活用しましょう。プルリクエストをメンテナーに送信して、メンテナーが問題を認識できるようにします。オープンソースソフトウェアがビジネスに与える影響を理解することで、オープンソースソフトウェアを体系的に管理するためのビジネスケースを構築できます。

オープンソースのセキュリティツールに求めるべき 6 つの機能

オープンソースのセキュリティ戦略において、セキュリティツールは重要な役割を担っています。オープンソースのコードに既知の脆弱性がないかを自動的にチェックし、脆弱性データベースを参照して、脆弱性がもたらす潜在的な影響、そして問題を修復するための手順を把握するのに役立ちます。これらのツールにより、コードの生成を継続的にモニタリングし、ソフトウェア開発プロセス全体でセキュリティとライセンス/ガバナンスを統合できます。

1.パッケージと影響を及ぼす脆弱性の総合的なビュー

オープンソースコンポーネントと依存関係を可視化することは、セキュリティ上の課題の一部であるため、コンポーネントを自動的にリストアップして評価する方法があれば、オープンソース環境をコントロールできるようになります。CI/CDパイプラインのコンポーネントを特定し、脅威のレベルを評価できるオートメーションを探してください。脆弱性のあるコンポーネントが実際にアプリケーションで使用されているでしょうか。

2.ライセンス管理機能

セキュリティツールを使うことで、開発環境でコードが作成される際に、サードパーティやカスタムコードの脆弱性とライセンスリスクの両方を継続的にチェックできるため、コードリポジトリをスキャンする必要がなくなります。

3.オートメーション

セキュリティツールは、脆弱性を自動的にモニタリングして検出できます。脆弱性に起因するインシデントが発生した場合、ツールで被害の状況を把握し、適切な対応策を講じることができます。修正、要求、パッチ、依存関係のアップグレードに関するポリシーを設定し、プロセスを自動化することもできます。

4.開発者ツール、ワークフロー、自動化パイプラインへの直接統合

開発者のツールやプロセスに直接セキュリティを組み込むことで、コードの安全性を確保するプロセスを簡素化できます。開発者はプラグインを使用して CLI や IDE 内で直接簡単に修正プログラムを適用できます。GitHub との連携により、リポジトリ、プロジェクト、プルリクエストをテストし、プルリクエストを自動化して修正を適用できます。

5.既知の CVE を超える、最新の充実したデータベース

セキュリティツールは、既知の脆弱性の公開データベース以上の、独自のキュレーションデータベースを構築しています。これらの脆弱性には、CVE 番号の付いた脆弱性、セキュリティ勧告に記載されている脆弱性、問題追跡ツールによって特定された脆弱性、フォーラムやソーシャルメディアなどで議論されている脆弱性などが含まれます。

6.プロジェクトの継続的なモニタリング

セキュリティツールは、稼働中のアプリケーションを継続的にモニタリングし、脆弱性に対する攻撃を自動的に防止できます。その結果、アプリケーションは効果的に自身をモニタリングし、発生する攻撃やライセンスの問題から身を守ることができます。

オープンソースコンポーネントをモニタリングするためのセキュリティツールの選び方について詳しくは、当社のガイドSCA ツールの選び方をご覧ください。

OSS セキュリティに Snyk を使用する 6 つのメリット

Snyk Open Source は、アプリケーションセキュリティをソフトウェア開発パイプライン全体に組み込むデベロッパーファーストのセキュリティツールを提供し、脆弱性やライセンス問題からコードを保護しながら、オープンソースソフトウェアで構築されたアプリケーションを作成、導入できるようにしています。

1.DevSecOps に対応している

Snyk オープンソースは、コードの最初の行から SDLC に統合されています。セキュリティとライセンスのスキャンを可能な限りシームレスにするために、統合に多大な投資を行ってきました。これにより、開発者はアプリケーションのセキュリティに直接責任を持つようになり、セキュリティチームや業務チームとの生産的なループが生まれています。

また、DevSecOps Hub は、組織がセキュリティを効果的に統合する DevOps 文化を発展させるためのテクノロジー、プロセス、人材を紹介するもので、DevSecOps コミュニティは、サポートポータルや仮想およびライブのイベントで開発者とセキュリティリーダーを結びつけ、セキュリティチャンピオンをサポートするアンバサダープログラムを通じて Snyk とのつながりがより直接的になるようにしています。

2.問題の修正が開発者ワークフローに組み込まれている

Synk オープンソースは、Atlassian Bitbucket、Visual Studio Code、Maven Central、GitHub、JetBrains などの開発者ツールに組み込まれているため、開発者は Snyk にアクセスして、好みのツールで脆弱性やライセンスの問題を検出できます。

3.誤検出率が低い

Snyk のセキュリティ専門家チームがデータベースを管理することで、誤検知率を低く抑えています。データベースの各項目は分析、テストし、脆弱性にそれぞれ CVSS スコアとベクトルを割り当て、新しい脆弱性を発見するための独自の調査に投資し、該当する場合はコードスニペットを含め、手作業で厳選した概要を掲載しています。

4.依存関係をツリービューで表示できる

Snyk はアプリケーションのパッケージマネージャを使用して依存関係ツリーを構築し、Snyk UI に表示します。これにより、どのコンポーネントが問題を引き起こしているかが可視化され、推移的な依存関係のコンポーネントであったとしても、Snyk で問題に対処できるようにしています。また、開発者のワークフローで直接ソフトウェア部品表 (SBOM) 作成プロセスを自動化できます。SBOM を取得したら、Snyk の SBOM チェッカーを使用して、セキュリティの脆弱性をチェックできます。

5.修正を自動化できる

Snyk は、CLI、IDE、CI/CD パイプライン内から脆弱性の修正が利用可能になると、自動的に修正を提案します。依存関係の修正が利用できない場合、Snyk は修正が利用可能になったとき、またはその脆弱性に対して新しい脆弱性が発見されたときに通知できます。

6.ガバナンス/ライセンスを管理できる

Snyk オープンソースライセンスコンプライアンス管理では、ポリシーの適用を自動化し、きめ細かい管理を実施して、開発者ワークフローの中でライセンスを管理できます。これにより、コードの最初の行からデプロイされたアプリケーションに至るすべてのステップをモニタリングして、プロジェクトがライセンスに違反していないことを確認できます。

よくある質問

オープンソースセキュリティとは

オープンソースセキュリティとは、サードパーティのオープンソースコードをアプリケーションで実行する際に、開発者とセキュリティチームが直面するリスク、そしてそれを軽減するために導入するプロセス、方法論、ツールのことをいいます。オープンソースコードの脆弱性を悪用した最近の攻撃により、組織は莫大な費用を負担させられており、オープンソースセキュリティの重要性が浮き彫りになるとともに、関連するセキュリティ戦略を実行し、モニタリングする必要性を強調しています。

オープンソースのセキュリティが重要となる理由

オープンソースは、私たちが今日目撃しているデジタルトランスフォーメーションの原動力となっており、あらゆる規模や業種の企業に利用されています。ただし、それにはリスクも伴っています。リスクの認識は最初の重要なステップですが、継続的セキュリティテストとモニタリングを含む、明確に規定したオープンソースセキュリティプランへの投資とメンテナンスがその後も必要です。

オープンソースのリスクとは

開発者は、セキュリティの管理や可視化ができないまま、オープンソースの依存関係を大量に取り込んでいます。オープンソースコンポーネントは、組織外のボランティアによってメンテナンスされていますが、メンテナーはコンポーネントの更新やセキュリティの確保に義務を負っているわけではありません。さらに、その公開性からハッカーは、開発者が脆弱性を認識するたびに、その脆弱性を知り、悪用することができます。これらの点がオープンソースソフトウェアのリスクになります。