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

サイバー攻撃の件数が毎年過去最高を更新し、オープンソースコードに的を絞った攻撃の数が増え続けているにもかかわらず、回答があった組織の多くは、いまだにソフトウェアコンポジション解析 (SCA、オープンソースの依存関係に対処するテクノロジー) と静的アプリケーションセキュリティテスト (SAST、オープンソースコードやプロプライエタリコードの非公開実装に対処するテクノロジー) という 2 つの最も基本的なサプライチェーンセキュリティテクノロジーを使用していません。また、Infrastructure as Code ツールの設定チェックやシークレットスキャンなどのクラウドネイティブのセキュリティ対策の導入数は、それらをさらに下回っています。

オープンソースパッケージのセキュリティ態勢の確認は、ソフトウェアサプライチェーンセキュリティを維持するうえできわめて重要であり、パッケージがセキュリティのベストプラクティスに従っていることを確認する、Snyk Advisor や OpenSSF Scorecard などの自動化されたシステムは、プログラムでリスクを解析するための最も信頼性の高い方法です。ただし、これらのシステムは、オープンソースパッケージの安全性を確認する方法としては最も人気がなく、Snyk Advisor を使用している調査回答者とセキュリティスコアカードを使用している調査回答者の割合は、それぞれわずか 40% と 34% にすぎません。

驚いたことに、すべてのパッケージに (使用されているパッケージの最低限の要件であるべき)「責任ある開示」ポリシーが設けられていることを確認している調査回答者は、わずか 52% となっています。

セキュリティのシフトレフトは、積極的にコードセキュリティを強化してソフトウェアの開発中にコードに組み込まれてしまう脆弱性を減らそうとしている、多くのエンジニアリング組織の優先事項となっています。セキュリティをシフトレフトすると、導入前のテストでブロックされて修正のために開発者に戻されるビルドが減るため、SDLC のスピードと効率が向上します。自身の組織が IDE にセキュリティツールを配置していると答えた調査回答者がわずか 40% であることから、シフトレフトも完了しているとは言えず、ローカルでコマンドライン上でセキュリティツールを使用している組織の割合はさらに少ないのが実情です。  セキュリティツールが配置されている最も一般的な場所は、ビルドツールとコードリポジトリであり、いずれも約 65% となっています。

多くの調査回答者は、ソフトウェアサプライチェーンセキュリティの危機に直面しており、さまざまな面で組織が影響を受けていると述べています。そして調査回答者の大多数が、過去 1 年以内に 1 つ以上のサプライチェーンに関する問題の影響を受けています。具体的な影響としては、53% が 1 つ以上の脆弱性にパッチを適用せざるを得なくなり、61% がオープンソースとサプライチェーンのセキュリティを確保するために新しいツールやベストプラクティスを実装しており、多くの組織がサプライチェーン攻撃の影響を直接受けて初めて対策を講じているということを示しています。 

実際のソフトウェアサプライチェーンセキュリティに関するベストプラクティスの導入は散発的であり、正式なサプライチェーンセキュリティプログラムを有している組織は 53% にすぎません。その原因は、ソフトウェアサプライチェーンセキュリティが全般的なセキュリティプラクティスの一部とみなされているからかもしれませんが、これはサプライチェーンセキュリティが組織にとって差し迫った問題 (またはプログラムレベルでの検討や計画に値するほどの差し迫った問題) になっているのかどうかという疑問を提起します。より具体的なプラクティスの観点から言うと、SBOM を使用している組織はわずか 42%、コードの特定のためにコード署名を実装している組織は 58%、(SLSA などの) ソフトウェアライフサイクル保証プロセスを導入している組織は 62% となっています。

組織が無視している脆弱性のタイプは、意識的に、または無意識に受け入れられている攻撃対象領域とリスクに関する有益な情報となります。少なくとも 50 のアカウントで無視されている CVE のうち、圧倒的に優勢だった脅威のタイプは、サービス拒否 (DoS) に類するものであり、これらの脆弱性は、無視されている脆弱性全体の 31.3% を占めていました。深刻ではあるものの、DoS 攻撃は多くの場合、CDN またはインフラストラクチャレベルでプロアクティブに緩和されるため、当然のことながら、多くのチームがこれらの CVE の優先度を下げています。次に、信頼できないデータのデシリアライズが 50 を超えるアカウントが無視している CVE の 14.3% を占めていました。これは、複数の言語に影響を及ぼす可能性がある比較的広範な部類の脆弱性であり、それを深刻な脆弱性に発展させる、連鎖的な攻撃や複合的な攻撃の第一歩になることが少なくありません。3 番目に多かったのはプロトタイプ汚染 (12.5%) でしたが、これは主に JavaScript コミュニティに影響を及ぼします。 

オープンソースの黎明期から、オープンソースソフトウェアは実際にクローズドソースソフトウェアより安全なのかどうかという議論が盛んに交わされてきました。脆弱性は、その修正プログラムと同じように公開されてオープンになるため、脆弱性データベースを使用して修正時間 (TTF) に関するデータを追跡することが可能です。当社は過去 4 年間にわたって TTF を追跡し、2019 年以降にプロプライエタリアプリケーションの TTF が着実に増加する一方、オープンソースアプリケーションの TTF が着実に減少していることに気付きました。公平のために言うと、2021 年にはどちらのジャンルの TTF も減少しましたが、当社がこのメトリックを追跡してから初めて、オープンソースアプリケーションの TTF がプロプラエタリアプリケーションの TTF を下回りました。これは、オープンソースエコシステムが時間とともにセキュリティ対応を改善し、クローズドソース環境よりセキュリティを向上させつつあることを示しています。

重大な脆弱性と優先度の高い脆弱性の平均 TTF が大幅に急増するのを目の当たりにした後、平均 TTF は過去 2 年間で大幅に減少しました。この急激な変化は、その数年間でオープンソーススキャンが増加し、以前は検出されていなかった脆弱性が検出されるようになったことの表れであると考えられます。それら 2 つの重要なターゲットの平均 TTF は、2021 年から 2022 年にかけて約半分に減少し、重大な脆弱性では -51%、優先度の高い脆弱性では -49.4% になりました。このような着実な減少の理由としては、SCA などのオープンソースセキュリティツールの導入の拡大、重大なオープンソースの脆弱性の修正に向けた資金や人員の拡充、セキュリティが最優先事項となるオープンソースプロジェクトに対する認識の高まりなどが考えられます。いずれにしろ、こうした兆候は素晴らしいことであり、OSS セキュリティの継続的な改善に向けて着実に正しい方向へと進んでいることを示しています。 

TTF はオープンソースエコシステムごとに大きく異なっていましたが、Snyk が追跡している主要なオープンソースエコシステムでは著しい減少が見られました。平均 TTF が最も減少したのは Java と Python であり、その減少率はそれぞれ 50.8% と 43.4% でした。また、減少を記録した 5 つすべてのエコシステムで 2 桁の減少が見られました。日数の観点から見て全体的な減少幅が最も大きかったのは Go と Python であり、それぞれの平均 TTF は -147 日と -115 日でした。逆に平均 TTF が増加したエコシステムは 2 つあり、C エコシステムと Ruby エコシステムは、それぞれ TTF の平均日数で 144.7% と 102.1% の増加率を示し、合計日数が +55 日と +49 日となりました。オープンソースエコシステムは、セキュリティ対応の時間を短縮するとともに、脆弱性の公開から処置までの時間を短縮することによってサプライチェーンセキュリティを強化しています。