Linux Foundationと取り組むオープンソースソフトウェアのサイバーセキュリティ課題への対応

SnykはLinux Foundationと共同で、オープンソースソフトウェア（OSS）のセキュリティの現状に関するレポートを作成しました。このレポートは、OSSのメンテナーとサイバーセキュリティの専門家を対象とした550件以上のアンケート回答と15件のインタビューに基づいています。

レポートの公開後、Snykの専門家がLinux Foundationとウェビナーを開催し、主な調査結果について議論しました。オープンソースソフトウェアのサイバーセキュリティ課題への対応：専門家パネル。ウェビナーの参加者は、Mic McCully（Snyk、フィールドストラテジスト）、Matt Jarvis（Snyk、デベロッパーリレーションズ担当ディレクター）、Steve Hendrick（Linux Foundation、リサーチ担当VP）です。

オープンソースのセキュリティと持続可能性を高める方法について、ぜひご覧ください。

ソフトウェアサプライチェーンの脆弱性

ソフトウェアサプライチェーンが複雑化するにつれ、オープンソースのセキュリティはこれまで以上に重要になっています。たとえば、現在のソフトウェアの大半には、可視化やアプリケーションセキュリティの観点からの評価が難しい、間接依存関係や推移的依存関係が数多く含まれています。

開発者がオープンソースパッケージを取り込むと、そのパッケージ内には別のオープンソースプロジェクトへの参照が含まれていることがよくあります。そのため依存関係が階層構造になり、下位のパッケージは間接依存関係、または推移的依存関係と呼ばれることがよくあります。

最近のレポートによると、OSSプロジェクトには平均49件の脆弱性があり、直接依存関係は79件に及びます。ただし、エコシステムによって状況は異なり、JavaScriptプロジェクトの脆弱性は、Python、Go、Java、.NETのプロジェクトより大幅に多くなっています。

脆弱性がパッケージ内のどこにあるかを見ると、さらに重要な実態が明らかになります。レポートによると、こうしたセキュリティ問題の40%以上が間接依存関係で見つかっています。つまり、開発チームは脆弱なコードをプロジェクトに取り込んでいることに気づいていない場合が少なくありません。

Snykで見てきたように、こうした脆弱性は非常に深い階層に潜んでいることがあります。ソフトウェアサプライチェーンにおける問題の中には、依存関係を4、5階層たどった先にあるものも少なくありません。

SBOMとOSSセキュリティポリシーの必要性

セキュリティ上の問題は複雑な依存関係ツリーの奥深くに潜んでいることが多いため、注目を集めているのが

ソフトウェア部品表（SBOM）を作成する取り組みが広まりつつあります。SBOMは、透明性の向上を目的として、ソフトウェアの構成要素とサプライチェーン上の関係を正式に記録したものです。

実際のところ、コンポーネントに何が含まれているかを把握する必要があります。どれほど使いやすいのか、信頼できるのかを理解しなければなりません。推移的依存関係がある場合、こうした情報を得るのは非常に困難です。

多くの企業がSBOMを作成していない理由の一つは、オープンソースセキュリティ全般への取り組みが不十分なことです。実際、レポートのアンケートでは、オープンソースのセキュリティに対応するポリシーを定めている組織はわずか49%でした。

OSSポリシーがなければ、リスクを効果的に管理することはできません。脆弱性への対応について十分な知識がないため、セキュリティ体制にも悪影響が及びます。

組織はOSSパッケージのセキュリティをどのように確認しているのか？

レポートによると、44%の企業が開発者にソースコードの脆弱性を調査させていますが、そのために使用しているツールは、実に十数種類に及びます。特に広く使われているのが、静的アプリケーションセキュリティテスト（SAST）とソフトウェア構成分析（SCA）です。

OSSパッケージのセキュリティを確認する一般的な方法として、採用前に審査する方法もあります。高い評価を得ていること、活発なコミュニティがあり頻繁に新しいコード変更をリリースしていること、セキュリティポリシーを公開していることなどを確認します。しかし、プロジェクトのメンテナーがOSSセキュリティ対策に先を見越して取り組んでいなければ、こうしたコンポーネントにも推移的依存関係を通じて脆弱性が入り込む可能性があります。

業界全体で見え始めているのは、OSSの利用者にセキュリティや信頼性に関する情報を提供する新たな方法です。GitHubのスターから始まりましたが、今ではOpenSSF Scorecardsをはじめ、詳細な情報を提供するほかの情報源も登場しています。

JavaコミュニティにおけるLog4Shellの影響

レポートでは、Javaコミュニティに広く影響を及ぼしたLog4Shellの脆弱性についても、興味深い実態が明らかになりました。特に注目すべき点として、Log4Shellの影響を受けたプロジェクトの79%では、コードベース内に複数のLog4Shell脆弱性があり、そのうち60%が間接依存関係で見つかりました。

Log4Shellは、オープンソースプロジェクトが成功の代償として被害を受けることがある、ということをまさに示しました。Log4jのように幅広いプロジェクトで使われているオープンソースライブラリにセキュリティ上の問題が見つかると、その影響は甚大になり得ます。これをきっかけに、SCAスキャナーの必要性が広く認識されるようになりました。

オープンソースの脆弱性は修正が難しくなっている

ソフトウェアサプライチェーンはますます複雑になり、セキュリティの可視性を確保することが多くの組織にとって大きな課題になっています。その結果、オープンソースの脆弱性も修正が難しくなっています。実際、脆弱性の修正にかかる時間は、2018年の49日から2021年には110日に増加しました。

過去3年間で、修正にかかる時間は2倍以上に増えました。同時に、次の2つの変化も起きています。1）ソフトウェアの利用と開発が驚異的なペースで拡大したこと。2）セキュリティに費やす時間と注意が大幅に増えたこと。

修正にかかる時間が延びる中、組織はリソース不足という課題にも直面しています。重大な問題を以前より迅速に修正できている企業もありますが、アプリケーションセキュリティのリソースが不足しているため、優先度の低い脆弱性への対応は遅れています。そのため、企業がセキュリティ上の懸念への対処に使う手段として、SASTとSCAツールが上位2つを占めています。

SASTおよびSCAのスキャンツールは、CI/CDパイプラインや開発プロセスに統合することで、多くのオープンソースの脆弱性の検出と修正を自動化できます。これにより、組織が抱えるアプリケーションセキュリティのリソース不足を緩和できます。

デプロイパイプラインの自動化とセキュリティ問題の修正にかかる時間には、非常に強い相関関係があります。CI/CDが完全に自動化されていると、セキュリティチェックを組み込めるフックポイントが数多くあるためです。

2022年のオープンソースセキュリティの現状

SnykとLinux Foundationによるこの対談では、レポートの主な調査結果を取り上げましたが、明らかにすべきことはまだ多くあります。レポート全文をダウンロードして、今日のソフトウェアサプライチェーンを取り巻く複雑さとリスクについて詳しくご覧ください。2022年版 オープンソースセキュリティの現状。