Dev、Sec、Opsでの責任共有の推進は47％が未実施も前進――企業のOSSセキュリティに関するSnykレポート：Node、PostgreSQL、MySQL、nginxなど公式コンテナイメージは安全ではない

セキュリティ企業のSnykは、オープンソースソフトウェアのセキュリティ状況に関する年次レポートの最新版「State of Open Source Security Report 2020」を公開した。

[＠IT] PC用表示関連情報

LINE

Hatena

　ソフトウェアコンポジション解析（SCA）ツールを手掛け、オープンソースソフトウェア（OSS）のセキュリティ支援などを行うSnykは2020年6月24日（米国時間）、OSSのセキュリティ状況に関する年次レポートの最新版「State of Open Source Security Report 2020」（以下、2020年レポート）を公開した。

　Snykは、同レポートのベースになったデータ分析結果の最も重要なハイライトとして、下記5つを挙げている。

企業におけるセキュリティのマインドセットおよび文化が改善している
人気の高いOSSパッケージングソフトで見つかった新しい脆弱（ぜいじゃく）性の件数が減少している
脆弱性の報告件数とプロジェクトへの影響度は相関しない
公式イメージをコンテナに使っても、一般的なセキュリティ対策の代わりにはならない
脆弱性の修正にかかる期間は、コミュニティーの期待にあまり沿っていない

　以下では、Snykが2020年レポートの作成のために収集、分析したデータの概要を示した上で、これらの各ハイライトについて説明する。

レポートで分析されたデータ

Snykとそのパートナーが作成、配布した調査のデータ。500人超の開発者、セキュリティ担当者、運用エンジニアが回答した
Snykの脆弱性データベースの内部データに加え、Snykがモニタリングおよび保護している数十万のプロジェクトから収集された相関データ
「GitHub」「GitLab」「BitBucket」などの数百万のリポジトリをスキャンした結果の集計データなど、さまざまなソースによって公開された調査やデータ

セキュリティ文化の改善

　2020年レポートでは、「企業内のセキュリティ対策の責任は誰が負うのか」に関する企業の認識が明確に変わっているという。

　2019年レポートでは、「企業内でソフトウェア／アプリケーションセキュリティの責任を負うのは誰か」という質問に対し、回答者の80％以上が「開発者」と答えたが、「セキュリティチームや運用チームも責任を負う」と答えた回答者は、いずれも30％に満たなかった。

　2020年レポートでは、同じ質問に対して「開発者」を挙げた回答者が85％で、これは前年に近いが、「セキュリティチーム」を挙げた回答者が55％、「運用チーム」を挙げた回答者も35％と上昇している。

　2020年レポートでは、「企業内でインフラセキュリティの責任を負うのは誰か」という質問も追加された。これに対して回答者が挙げた割合は、「開発者」が63％、「セキュリティチーム」が56％、「運用チーム」も56％に達した。

「企業内のセキュリティ対策の責任を誰が負うか？」に対する回答（紺色がソフトウェア／アプリケーション、黄色がインフラ）（出典：Snyk）

　DevSecOpsの中核的な考え方は、開発、セキュリティ、運用の各チーム間で責任を共有する文化を築くことにあるが、2020年レポートの回答傾向は、こうした文化構築という点で前進している。

　ただし、DevSecOps文化への移行では、責任の共有を推進するプログラムの確立が重要だが、2020年レポートのためにSnykが実施した調査では、「こうしたプログラムは実施されていない」と答えた企業が47％に達している。

OSSパッケージングソフトの新しい脆弱性が20％減少

　人気のあるソフトウェア開発エコシステムで新たに報告されたOSSパッケージングソフトの脆弱性の件数は、2019年に20％減少した。これらのエコシステムには、「Maven Central」「npm」「NuGet」「PyPi（Python Package Index）」「PHP Packagist」が含まれる。

OSSパッケージングソフトの脆弱性における2014〜2019年の件数推移（出典：Snyk）

　パッケージングソフトのエコシステムは急速に規模が拡大していることを考えると、新しい脆弱性の減少は注目に値する。その理由を説明する具体的なデータポイントはないが、この傾向は今後も要注目だという。

脆弱性の報告件数と影響度は相関しない

　2019年に報告されたOSSの脆弱性の内訳を見ると、クロスサイトスクリプティング（XSS）の脆弱性の報告件数が最も多かった。だが、この脆弱性の影響を受けたプロジェクトの数は、比較的少なかった。

2019年に報告されたOSSの脆弱性の内訳（出典：Snyk）

　一方、2019年には、報告件数がそれほど多くない「プロトタイプ汚染」のような脆弱性が、多くのプロジェクトに影響したという。特に、人気の高い「Lodash」「jQuery」に含まれ、広く報じられた2つのプロトタイプ汚染の脆弱性が、スキャンされたプロジェクトの25％以上に影響した。

公式コンテナイメージは安全ではない

　2019年に続いて、人気が高い公式コンテナイメージ10種類のセキュリティを分析したところ、2019年と同様に、公式イメージには既知の脆弱性が多数含まれていた。特に顕著だったのが、「Node」「PostgreSQL」「MySQL」「nginx」だという。Snykは、「開発者の間では、公式コンテナイメージは、本質的に安全だという誤解が広がっているようだ」と指摘し、「これは気掛かりな問題だ」としている。

「コンテナセキュリティの評価をどのように行っているか？」に対する回答（出典：Snyk）

　「公式コンテナイメージを使っても、適切なコンテナセキュリティ対策を継続する必要があることに変わりはない」と、Snykは強調している。開発者と企業は、コンテナイメージに含まれる脆弱性の発見に取り組むとともに、見つかった脆弱性の緩和や修正を行わなければならないという。適切なセキュリティの慣行として、可能な限り軽量化されたコンテナイメージを、最小限のライブラリとともに使うことが挙げられる。

脆弱性の修正に関して、現実は期待に沿えていない

　2020年レポートの調査の中で、OSSプロジェクトで脆弱性の修正にかかる期間について、期待する日数を質問したところ、回答者の47％は「1週間（以内）」、18％弱は「1日以内」と答えた。

脆弱性が修正されるまでの期間（出典：Snyk）

　だが、スキャンされたプロジェクトについて調べたところ、脆弱性の33％が20日以内に修正されているものの、36％は修正に70日以上、要しており、修正にかかる平均日数は68日だった。「企業が全体的なリスク管理を改善するには、この現実を踏まえる必要がある」とSnykは指摘している。

　さらにSnykは、「OSSプロジェクトを利用するときは、脆弱性の修正に関するSLA（Service Level Agreement：サービス品質保証）をよく認識する必要があり、個人のコントリビューターがメンテナンスしているプロジェクトでは、特にそうだ。OSSライブラリを自社のプロジェクトで使用する場合、ライブラリの脆弱性がビジネスやプロジェクトに悪影響を与えないようにするには、ライブラリに関するセキュリティ指標として、脆弱性の修正にかかる日数、イシューが開かれてからプルリクエストがマージされるまでの平均日数、コードを自社で修正する場合の所要日数を追跡する必要がある」とアドバイスしている。