オープンソースセキュリティを解説

オープンソースソフトウェアは、その協調的で公開された性質からここ数年で広く利用されるようになり、開発者だけでなく悪意ある攻撃者にとっても利用しやすいものとなっています。攻撃者は、アプリケーションが公知の脆弱性にさらされていると知れば、そのオープンソースコードを使って開発されたあらゆるアプリケーションを攻撃できます。Log4jやApache Strutsの脆弱性の事例は、これが組織にとって現実的で、時には深刻なリスクであることを示しています。

このリスクを軽減するには、オープンソースのコンポーネントと依存関係を管理することが不可欠です。しかし、アプリケーションで使用されているすべてのオープンソースコンポーネントを把握し続けるのは難しく、既知の脆弱性データベースと照らし合わせて手作業で確認するのも大変です。さらに、依存関係が入れ子になっていると問題は複雑になります。開発者が記述したコードだけでなく、利用するすべてのオープンソースコードと、そのコード内の依存関係も保護する必要があるためです。

この記事では、オープンソースセキュリティを定義し、オープンソースソフトウェアに伴うリスクを掘り下げ、オープンソースソフトウェアを利用する際に組織が直面するリスクを軽減するツールとプロセスを紹介します。

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

オープンソースセキュリティとは、サードパーティ製ソフトウェアに伴うリスクや脆弱性と、オープンソースソフトウェアを保護するために用いるツールやプロセスを指します。セキュリティツールは、コード内のオープンソースライブラリや依存関係の検出、アプリケーションでの各コンポーネントの利用状況の分析、脆弱性が見つかった際のアラートや修復措置の実行を自動化できます。二要素認証などの対策を取り入れることで、侵害を防ぐためのセキュリティ層を追加できます。

オープンソースソフトウェアを利用する4つのメリット

ビジネス上のニーズにより、ソフトウェアの開発とリリースのサイクルは加速しています。こうしたニーズに応えるため、開発者は社内で開発したコードを補完する手段として、オープンソースソフトウェアをますます活用しています。

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

1. コスト:開発者は、パブリックドメインのオープンソースソフトウェアを自由に利用、変更、共有でき、世界中の開発者やボランティアのコミュニティがその保守を担います。商用のオープンソースソフトウェアパッケージでさえ、コードをゼロから独自開発するコストと比べて、比較的安価です。

2. 使いやすさ:オープンソースソフトウェアは事前に構築され、コードも公開されているため、開発者は既存のコードを活用して、それぞれのニーズに対応できます。その分、より付加価値の高い作業に時間を割けます。

3. 品質:オープンソースコードは開発者コミュニティによって構築、利用、検査されるため、理論上はバグが少なく、脆弱性もすぐに発見されて対処されます。

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

オープンソースソフトウェアの導入は、場合によっては2倍以上に増加しました。利用可能なツールが増え、市場に参入する開発者のスキルも向上することで、規模の経済によるメリットが開発者にもたらされています。一方で、オープン性と脆弱性、俊敏性と品質の間にはトレードオフもあります。

図1：エコシステムごとに年間で新たに作成されたパッケージ

オープンソースソフトウェアを利用するということは、アプリケーションが依存するコードの保守を、直接知らない人々に委ねるということです。そのため、潜在的な悪影響を最小限に抑えるシステムやツールを活用することが重要です。

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

ほぼすべてのクラウドネイティブアプリは、オープンソースコンポーネントに依存しています。しかし、その保守やセキュリティに責任を負う人がいないため、オープンソースソフトウェアには次のようなリスクが伴います。

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

既知の脆弱性と未知の脆弱性の両方が含まれます。既知の脆弱性には、共通脆弱性識別子（CVE）が割り当てられたもの、インターネット上で公開されたもの、公開または非公開の脆弱性データベースに登録されたものがあります。一般に、脆弱性の知名度が高いほど、早急な対処が必要です。

脆弱性を追跡するだけでなく、アプリケーション内のすべてのオープンソース依存関係を把握することも重要です。依存関係が別の依存関係に依存する「推移的依存関係」は、セキュリティツールや監査では見えにくいため、特に注意が必要です。ツールやプロセスを活用し、アプリケーション内の依存関係をすべて特定して監査しましょう。

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

開発者は、利用するオープンソースパッケージの各種ソフトウェアライセンスを理解し、ライセンスに準拠してコードを使う必要があります。そのためには、ライセンス条項を把握し、プロジェクト全体で遵守することが求められます。オープンソースライセンスを遵守するには、組織がオープンソースコンポーネントの使用状況を詳細に把握する必要があります。また、ライブラリの著作権者がライセンスを変更する可能性に備え、継続的にライセンスを監視することも重要です。

3. 保守されていないオープンソースパッケージ

オープンソースパッケージは、保守されている場合でも、通常は単独の開発者か小規模なチームによって管理されています。コミュニティ主導のオープンソースプロジェクトの開発者には、ソフトウェアを保守する義務がなく、提供されるソフトウェアは「現状有姿」です。そのため、コードの安全性を確保するために時間やリソースを割く責任は利用者にあります。幸い、Snyk Advisorのように、このプロセスを簡略化できる便利なツールがあります。パッケージの保守状況、コミュニティ、セキュリティ態勢、人気度を分析し、利用しているオープンソースパッケージの健全性を評価するのに役立ちます。

オープンソースソフトウェアのリスクについて、さらに詳しく知りたい方は、オープンソースソフトウェアに潜む5つのリスクをご覧ください。

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

データは知見につながります。そこでSnykは、オープンソースセキュリティに関する懸念、パッケージやコンテナイメージにおける脆弱性の傾向、保守担当者や組織によるソフトウェア保護の取り組みを把握するため、開発者とセキュリティ担当者を対象に調査を実施しました。その結果を2020年版オープンソースセキュリティの現状レポートとして公開しました。主なポイントをご紹介します。

オープンソースの導入が拡大

市場のニーズとビジネスの実情を背景に、オープンソースのエコシステムは継続的に拡大しています。最も成長したのはnpmで、2022年3月時点で前年比33%超の成長を遂げ、パッケージ数は180万件に達しました。オープンソースの脆弱性の大半は、引き続き間接依存関係で発見されています。

• npm：86%

• Ruby：81%

• Java：74%

オープンソースセキュリティの文化は開発者中心へ

回答者は、セキュリティは部門間で共有すべき責任だと考えていることを示しました。

• 85%が、オープンソースセキュリティは開発者の責任だと回答

• 55%が、セキュリティチームの責任だと回答

• 35%が、運用チームにも役割があると回答

脆弱性の傾向

新たに発見された脆弱性は全体で20%減少し、最も多く報告されたのはクロスサイトスクリプティング（XSS）でした。

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

コンテナとオーケストレーションの課題

latestタグが付いた公式ベースイメージには、既知の脆弱性が含まれていることがよくあります。特に公式nodeイメージには、約700件もの既知の脆弱性が含まれています。調査参加者の30%超は、安全でない設定がないかKubernetesマニフェストを確認しておらず、Kubernetesにおけるセキュリティ関連のリソース制御要件も広く導入されていません。

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

2022年のオープンソースセキュリティの傾向

この1年、オープンソースセキュリティに関する議論では、サプライチェーンセキュリティ、責任意識の変化、新たに発見される脆弱性の減少、ボランティアの保守担当者への依存、脆弱性修正への期待の変化などが大きなテーマとなりました。

サプライチェーン攻撃の増加

サードパーティ製ソフトウェアコンポーネントは、ソフトウェアサプライチェーンを構成する一元的なリポジトリに格納されています。このサプライチェーンは、攻撃者にとって魅力的な攻撃経路です。ソフトウェアリポジトリを変更することなく、開発パイプラインの脆弱な箇所を攻撃できるからです。たとえば、依存関係や名前空間の混同を狙った設計上の欠陥を悪用したり、サードパーティ製コンポーネントを悪用してユーザーデータを侵害し、内部システムにアクセスしたりできます。

サプライチェーンのどの部分も攻撃経路になり得るため、ソースコードからデプロイまでの全体を保護することが重要です。サプライチェーンの脆弱性は新しい問題ではありませんが、2021年には大きな注目を集め、バイデン大統領のサイバーセキュリティに関する大統領令でも繰り返し取り上げられました。

セキュリティを共有責任とする文化への変化

セキュリティに責任を持つのは誰でしょうか。開発、セキュリティ、運用の各チームで責任を共有する方向に変化していることは、特に注目すべき傾向です。

DevSecOpsへの移行は前向きな変化ですが、回答者の47%は責任共有を推進するための具体的なプログラムを導入しておらず、OWASP Software Assurance Maturity Model（SAMM）で主要なセキュリティプラクティスとされるセキュリティチャンピオンプログラムを導入している回答者はわずか15%でした。責任を共有する必要性への認識と、実際の取り組みとの間には隔たりがあることがわかります。

また、PuppetのState of DevOpsレポートによると、組織のDevOpsプラクティスが成熟するにつれて、セキュリティプラクティスも成熟していくことがわかっています。

「DevOpsプラクティスが向上すると、DevSecOpsも自然に実現します。進化の進んだ組織では、セキュリティを要件（51%）、設計（61%）、ビルド（53%）、テスト（52%）に組み込むシフトレフトが進んでいます。一方、多くの中堅組織では、セキュリティが関与するのは本番環境の定期監査時（48%）や、本番環境で問題が報告された時（45%）です。」

Puppet State of DevOps Report 2021

脆弱性の発見件数が減少

レポートの意外な結果の一つは、新たに発見された脆弱性が全体で20%減少したことです。オープンソースのエコシステムが急速に拡大する中での減少であり、特に注目に値します。

一部のエコシステムでは規模が2倍以上になっているにもかかわらず、オープンソースの脆弱性の増加が鈍化した明確な理由はわかっていません。しかし、セキュリティに関する意識やプラクティス、ツールの改善が成果を上げている可能性を示しています。

今後もこの傾向を注視していきますが、セキュリティ対策やプラクティスに油断するにはまだ早い段階です。

オープンソースの保守担当者が企業に反発

保守担当者に資金を提供せず、自分たちのソフトウェアを使った製品から収益を得る企業や組織に対し、不満を募らせるオープンソースの保守担当者が増え、緊張が高まると予想されます。

2021年にオープンソースの保守担当者400人を対象に実施されたTideliftの調査では、46%が報酬をまったく受け取っておらず、保守作業で年に1,000ドルを超える収入を得ている人はわずか26%でした。半数以上（59%）がプロジェクトの保守をやめた、またはやめることを検討したことがあり、回答者の約半数が、保守担当者を続けることへの最大の不満として金銭的な報酬がないことを挙げています。

こうした不満は現実の影響をもたらしています。たとえば2022年1月、広く使われているnpmパッケージcolorsの保守担当者が、無限ループを引き起こし、パッケージの利用をすべて妨げる問題のあるコードを導入しました。

破損したバージョンのcolorsは、9万5,000回以上ダウンロードされました。colorsは、コマンドラインのプロンプトを扱うヘルパー（週約50万回ダウンロード）やAWS独自のaws-cdk（週約200万回ダウンロード）など、ほかの多くのプロジェクトでも使われているため、大きな懸念となっています。

同じ保守担当者が管理する人気npmパッケージfakerでも、同様の事態が発生しました。保守担当者は、Fortune 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 Open Sourceを活用する6つのメリット

Snyk Open Sourceは、開発者を第一に考えたセキュリティツールです。アプリケーションセキュリティをソフトウェア開発パイプライン全体に組み込むことで、オープンソースソフトウェアを活用したアプリケーションの開発とデプロイを可能にしながら、コードを脆弱性やライセンス上の問題から保護します。

1. DevSecOpsに対応

Snyk Open Sourceは、最初の1行目からSDLCに組み込めます。セキュリティとライセンスのスキャンをできる限りシームレスに行えるよう、連携機能に多大な投資をしてきました。これにより、開発者がアプリケーションのセキュリティに直接責任を持てるようになり、セキュリティチームや運用チームとの生産的な連携が可能になります。

また、組織がセキュリティを効果的に組み込んだDevOps文化を醸成できるよう、テクノロジー、プロセス、人材に焦点を当てたDevSecOps Hubを作成しました。さらに、サポートポータル、オンラインおよび対面イベント、セキュリティチャンピオンとSnykをより直接的につなぐアンバサダープログラムを通じて、開発者とセキュリティリーダーを結びつけるDevSecOps Communityも運営しています。

2. 開発者のワークフローに組み込んで問題を修正

Snyk Open Sourceは、Atlassian Bitbucket、Visual Studio Code、Maven Central、GitHub、JetBrainsなどの開発者向けツールに組み込めます。開発者は使い慣れたツールからSnykにアクセスし、脆弱性やライセンス上の問題を見つけることができます。

3. 誤検知が少ない

Snykのセキュリティ専門家チームがデータベースを管理し、誤検知を抑えています。データベース内の各項目を分析・テストし、各脆弱性にCVSSスコアとベクトルを割り当て、新たな脆弱性を発見するための独自調査にも投資しています。また、該当する場合はコードスニペットを含む、専門家が作成した概要も提供します。

4. 依存関係ツリーの表示

Snykはアプリケーションのパッケージマネージャーを使用して依存関係ツリーを作成し、SnykのUIに表示します。これにより、問題の原因となっているコンポーネントを視覚的に確認し、推移的依存関係であってもSnykで対処できます。また、開発者のワークフロー内でソフトウェア部品表（SBOM）を直接作成するプロセスも自動化できます。SBOMを作成したら、SnykのSBOM Checkerでセキュリティ脆弱性を確認できます。

5. 修正の自動化

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

6. ガバナンス／ライセンス

Snyk Open Source License Compliance Managementを利用すると、自動化されたポリシー適用ときめ細かな管理により、開発者のワークフロー内でライセンスを管理できます。コードの最初の1行からアプリケーションのデプロイまで、あらゆる段階を監視し、プロジェクトがライセンスに違反しないようにします。

Play Video: Snyk Open Source Security Overview

よくある質問

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

オープンソースセキュリティとは、アプリケーションでサードパーティ製のオープンソースコードを使用する際に、開発者やセキュリティチームが直面するリスクと、それらを軽減するために導入するプロセス、手法、ツールを指します。近年、オープンソースコードの脆弱性を悪用する攻撃によって組織は大きな損害を受けており、オープンソースセキュリティの重要性と、関連するセキュリティ戦略を実施・監視する必要性が浮き彫りになっています。

オープンソースセキュリティが重要なのはなぜですか？

今日目の当たりにしているデジタルトランスフォーメーションを支えているのがオープンソースであり、あらゆる業界の大小さまざまな企業で利用されています。しかし、リスクも伴います。こうしたリスクを認識することは重要な第一歩ですが、継続的なセキュリティテストと監視を含む、明確なオープンソースセキュリティ計画への投資と維持も欠かせません。

オープンソースにはどのようなリスクがありますか？

開発者は、セキュリティ管理や可視性がないまま、膨大な量のオープンソース依存関係を取り込んでいます。こうしたオープンソースコンポーネントは組織外のボランティアによって保守されていますが、メンテナーにはコンポーネントを更新・保護する義務はありません。また、公開されている性質上、開発者が脆弱性を認識すると、悪意ある攻撃者がその情報を知り、悪用する可能性があります。これらは、オープンソースソフトウェアがもたらすリスクの一例です。