オープンソースのメンテナーはセキュリティを重視しているが、70%は必要なスキルが不足
2019年2月26日
0 分で読めますSnykの「2019年オープンソースセキュリティの現状」レポートへようこそ。このレポートは複数の記事に分かれています。
オープンソースのメンテナーはセキュリティを重視しているが、70%は必要なスキルが不足
この情報などを1か所にまとめた、手作りの素敵なPDFレポートもダウンロードできます。
「2019年オープンソースセキュリティの現状」レポートをダウンロード
オープンソースのメンテナーのセキュリティ状況
製品の開発やコードの記述において、セキュリティが重要な役割を果たすべきだという点には、ほとんどの開発者やメンテナーが同意するでしょう。しかし、オープンソースプロジェクトの構築にあたってメンテナーが従うべき教科書どおりのルールはありません。そのため、セキュリティ基準には大きなばらつきが生じる可能性があります。
メンテナーは、プロジェクトのさまざまな側面に時間と労力を費やします。機能面に費やすことも多く、その結果、開発プロセスにおいてセキュリティの優先度が下がることがあります。
2017年に前回のレポートを公開して以来、セキュリティへの取り組みと意識は高まる傾向にあります。
オープンソースのメンテナーはセキュリティ知識が向上しているものの、十分ではないと回答。平均は10点中6.6点
今年は、回答者の大半が自身のセキュリティ知識を「中程度」と評価し、平均は10点中6.6点でした。自身を「低い」と評価した人は少数（7%）でした。一方、回答者の大半を占める「中程度」の割合は、昨年の56%から今年は63%に上昇しました。
最も大きな変化が見られたのは、「低い」と「高い」の評価です。昨年、セキュリティ知識を「高い」と評価した人はわずか17%でしたが、今年は約30%に増加しました。また、「低い」と評価した人にも同様の変化が見られ、昨年は26%だったのに対し、今年はわずか7%でした。
オープンソースのメンテナーの70%が、セキュリティに関する知識が十分ではないと回答
セキュリティ監査
セキュリティ監査は、仲間同士でセキュアコーディングのベストプラクティスが守られているか確認するコードレビューの一環として実施できます。また、静的または動的なアプリケーションセキュリティテストなど、さまざまな方法で監査を実施することもできます。手動でも自動でも、監査はアプリケーションの脆弱性を検出・低減するうえで欠かせません。後の段階でのリスク露出やデータ侵害を防ぐため、開発の初期段階からできるだけ定期的に実施する必要があります。
オープンソースのメンテナーの4人に1人はコードベースを監査していない
昨年は回答者の44%がセキュリティ監査を一度も実施したことがないと回答しました。今年はこの割合が大幅に下がり、ソースコードを監査していないと回答した人は26%でした。今年は、昨年のレポートと比較して、すべての監査サイクルで監査を繰り返し実施する傾向が見られます。四半期ごとおよび年ごとに、より頻繁にソースコードを監査する人の割合が平均10%増加しました。
セキュリティの専門家は、アプリケーションのライフサイクルの早い段階でセキュリティ上の懸念や潜在的な問題に対処するため、「シフトレフト」の考え方をよく提唱します。このアプローチでは、自動化によって開発者に役立つ多くの知見を提供でき、セキュリティチームも現代の継続的な開発の速いペースに対応しやすくなります。
セキュリティをシフトレフトすることは、特に重要であり、ときには不可欠です。本番環境で初めて発見されるセキュリティインシデントのコストを抑えられるからです。プロセスの早い段階でセキュリティに取り組み、開発者に実践してもらうには、開発者にとって使いやすく、既存のワークフローに統合できるツールを選ぶことが有効です。
メンテナーはどのように脆弱性を知るのか？
メンテナーが自ら脆弱性を発見するよりも、セキュリティ上の懸念について通知を受ける可能性のほうが高いでしょう。業界で認められているベストプラクティスのひとつが、責任ある情報開示ポリシーです。これにより、セキュリティ研究者や個人がプロジェクトのメンテナーに脆弱性を安全に報告する方法を定めます。
調査データから、回答者のほぼ半数（48%）は、公開チャンネルを通じて自分のコードに脆弱性があると知ることがわかりました。たとえば、誰かが公開の課題を投稿したり、メールで連絡したりする場合です。
72%のユーザーは、自分でコードをレビューした際に脆弱性を発見すると回答しました。しかし、62%は自身のセキュリティ知識を「中程度」と評価し、「高い」と回答したのはわずか30%でした。
さらに、ユーザーの大半（72%）は脆弱性を見つけるために自分のコードをレビューすると回答していますが、48%は、誰かが公開の課題を投稿して初めてコードの脆弱性を知るとしています。これは、セキュリティ知識が十分だと思われる場合でも、メンテナー1人だけのコードレビューに頼ることの難しさを示しています。
脆弱性の混入から開示まで
調査で明らかにしたかったことのひとつは、脆弱性がコードベースに混入してから発見・開示されるまでに、どのくらいの時間がかかるかという点です。そのため、npmエコシステムの主要ライブラリをいくつか選び、2018年に発見された脆弱性を分析しました。
正確な自動化には時間がかかり、容易ではないため、npmの主要ライブラリ6つを調べ、脆弱性を混入させたコミットと修正したコミットの日付の差を確認しました。サンプル数が少ないため、計算には多少の偏りがありますが、それでも数値の範囲や順序には興味深い傾向が見られます。
これら7つのライブラリのうち、混入から修正までが最も短かったケースでも、ほぼ1年、正確には289日かかっていました。中央値は約2年半で、最長は5.9年でした。
注目事例：Equifax、その1年後
米国政府が最近発表したレポートは、悪名高いEquifaxの情報漏えいは完全に防止可能だったと結論付け、開発ワークフローにセキュリティを組み込んでシフトレフトする重要性を示しました。
DevSecOpsの考え方を取り入れ、適切なプラクティスを実践していれば、開発チームは次のような方法で、Strutsの脆弱性による大きな影響を防げた可能性があります。
開発者が、IDEプラグインやコードリンターを使ってワークフローに統合できる、オープンソース依存関係のスキャンツールを導入していれば、問題を発見できたはずです。
CIサーバーで新しいビルドを実行するたびに、CIサーバーのプラグインまたはタスクとしてのCLIの呼び出しを通じて、アプリケーションの依存関係が自動的にテストされていれば、脆弱性をすぐに検出し、CIジョブを停止して、次へ進む前に修正を促せたはずです。
依存関係に新たな脆弱性が見つかったときに開発者へ通知する、監視ソリューションが導入されていれば、気付くことができたはずです。
アプリケーションの挙動や脆弱な関数の呼び出し状況について、監視と実行時の分析をさらに行っていれば、Strutsライブラリの脆弱性を警告できた可能性があります。
修正プログラムのリリース
責任あるセキュリティ情報開示では、修正とリリースの速さが非常に重要です。脆弱性がコード内に存在する期間を短縮するため、できるだけ迅速に問題へ対処するとともに、ユーザーが修正版へアップグレードするための十分な時間を確保する必要があります。できれば、問題が広く知られる前にアップグレードできるのが理想です。
オープンソースコミュニティは、開発者のボランティア活動に大きく支えられています（オープンソースソフトウェアに貢献してくださる素晴らしい皆さんに心から感謝します。皆さんの努力は本当に価値あるものですが、公に認められたり感謝されたりする機会はほとんどありません！）。オープンソースソフトウェアのメンテナーが脆弱性にどれほど速く対応し、修正を提供できるかを測るのは興味深いことです。
圧倒的多数にあたる84%のユーザーが、1週間以内に修正を提供できると回答しました。56%は1日以内に対処できるとし、22%は脆弱性の報告から数時間以内に対応できると回答しました。ヒーローはみな、マントを着けているわけではありません！
修正率
Snyk Vulnerability Databaseを調べると、脆弱性を修正したバージョンをリリースしているパッケージを特定できます。エコシステムによっては、理想的とは言えない状況が見えてきます。JavaScriptのことです！JavaとPythonのエコシステムでは、脆弱性への対応がしっかり行われています。一方、JavaScriptとNode.js全体では、開示された脆弱性に既知の修正があるパッケージはわずか59%です。
注目事例：責任あるセキュリティ情報開示
責任ある情報開示ポリシーを設ける大きなメリットは、ユーザーを危険から守れることです。脆弱性が報告され、プロジェクトのメンテナーと機密を保って優先度が判断されれば、情報が一般公開される前に修正を準備できます。メンテナーが迅速に対応して修正をリリースできれば、ユーザーが修正版にアップグレードするための時間を確保できます。この猶予期間によって、脆弱なバージョンを使うユーザーの数を大幅に減らせます。
責任ある情報開示ポリシーを導入することで、メンテナーがセキュリティに真剣に取り組んでいることも伝えられると考えています。プロジェクトのホームページにバッジを掲載し、リポジトリにSECURITY.MDポリシーファイルを含めることを、ベストプラクティスとして推奨します。
前回のレポートでは、公開されている情報開示ポリシーを設けているメンテナーは、設けていないメンテナーよりも、ユーザーから非公開で脆弱性の報告を受ける可能性がはるかに高いことがわかりました。
公開された情報開示ポリシーを設けていないメンテナーのうち、脆弱性について非公開で通知を受けたのは約21%でした。一方、ポリシーを設けているメンテナーでは73%でした。
ウェブサイトはウェブセキュリティの脆弱性にさらされる可能性があるため、ウェブセキュリティポリシーに関する明確なガイドラインが役立ちます。これを支援する新たな提案として、すでに早期導入が進んでいるSECURITY.TXT（RFC 5785）があります。このようなポリシーファイルは、セキュリティ研究者に連絡先、希望する言語、正確なポリシー、連絡方法を伝えることを目的としています。これには、脆弱性を安全かつ効率的に開示するための公開鍵も含まれます。
続けて読む：
オープンソースのメンテナーはセキュリティを重視しているが、70%は必要なスキルが不足
CTFを始めよう
オンデマンドのバーチャル入門ワークショップを視聴して、CTFの課題の解き方を学びましょう。
