Skip to main content
Snyk ブログ

In this article

開発者がセキュリティを担うべきだと考える人は81%、しかし十分な準備ができていない

著者
Headshot of Liran Tal

Liran Tal

the state op open source small

2019年2月26日

0 分で読めます

Snykの年次レポート「State of Open Source Security 2019」へようこそ。本レポートは複数の記事に分かれています。

この情報をはじめ、さらに多くの内容をまとめた、手作りのPDFレポートもダウンロードできます。

2019年版 State of Open Source Securityレポートをダウンロード

オープンソースセキュリティの責任の所在

アプリケーションやライブラリのセキュリティ責任を、現在実際に誰が担っているのか、またユーザーが誰が責任を担うべきだと考えているのかを調査しました。

回答者の81%が、アプリケーションコードのセキュリティは開発者が担うべきだと回答しました。これは、開発者に期待される関与と積極性の度合いを強く示すものであり、今日多くの組織が取り入れているDevSecOpsの大きな潮流を後押ししています。

「セキュリティの責任者は誰か？」というタイトルの棒グラフ。開発者81%、セキュリティチーム28%、運用チーム23%、担当者なし12%、その他3%を示しています。

SDLCの一環としてセキュリティを取り入れる健全な方法は、設計から本番環境まで、開発ライフサイクル全体にセキュリティを組み込むことです。これは、定期的に実施する単発のセキュリティテストという従来型の手法とは大きく異なります。従来型の手法は、現代の迅速なソフトウェアデリバリーモデルには適していません。しかし、プロセスやガイドラインだけでは十分とは限らず、組織でセキュリティプラクティスを健全に定着させるには、教育、使いやすいツール、そしてR&Dチームやステークホルダーとの連携も同じくらい重要です。

脆弱性の発見

自分のコードに潜むセキュリティ脆弱性を適切にコードレビューで見つけるには、豊富な知識と経験、そして鋭い洞察力が必要です。簡単な作業ではないため、そもそもレビューが行われない場合もあり、脆弱なコードが長い間見過ごされ、誰かに発見されるまで残り続ける可能性があります。

ユーザーの37%はCIでセキュリティテストを実施していない

DevOpsを実践するチームや、成熟したCI/CDパイプラインを持つチームは、ビルドの自動化プロセスにセキュリティテストを導入しやすいかもしれません。しかし、ユーザーのほぼ40%がCIの実行時に何らかのセキュリティテストを実施していないことがわかりました。一方で心強いのは、その半数以上が少なくともオープンソースの依存関係にある脆弱性をテストしていることです。

調査では、セキュリティを業務に組み込んでいるチームほど、継続的デリバリーの成果も高いことがわかりました。そのための重要な要素は、情報セキュリティチームが、開発者やIT運用担当者が業務で使える、事前承認済みで使いやすいライブラリ、パッケージ、ツールチェーン、プロセスを提供することです。

Nicole Forsgren、『Accelerate』

「CI中のセキュリティテスト」と題した棒グラフ。オープンソースの依存関係のテストが57%、自動テストなしが37%、ソースコードが36%、コンテナが

脆弱性を把握する

ユーザーの視点から、アプリケーションの依存関係にある脆弱性についてどのように知り、発見された潜在的な脅威にどう対応しているのかを把握することは興味深い点です。

懸念されることに、回答者の27%は、アプリケーションで新たに発見された脆弱性を把握するための、プロアクティブまたは自動化された方法がないと回答しました。脆弱性の検出に依存関係管理ツールやスキャンツールを利用していると回答したユーザーは、わずか36%でした。

開発者が脆弱性をどのように把握しているかを示すドーナツグラフ。36%が依存関係スキャンツールを利用し、27%は脆弱性を把握できる可能性が低く、その他の回答も示されています。

Snykの統計

  • 2018年後半だけで、SnykはMaven、RubyGems、npmのエコシステムを横断して、ユーザーのプロジェクトにある脆弱性を修正するため、7万件を超えるPull Requestを作成しました。

  • スキャンしたJavaプロジェクトの依存関係のうち、脆弱性が見つかったものの60%で、Snykは修正方法を提示できました。直接依存関係と、間接依存関係の修正済みバージョンに互換性がない場合は、修正方法を提示できないこともあります。こうしたケースの一部では、Snykのセキュリティチームがカスタムパッチを提供できます。

セキュリティ修正を適用するまでの期間

既知の脆弱性を修正する新しいリリースが公開された後、ユーザーがそれを適用するまでにどれくらいかかるのでしょうか。例としてPythonのPyPIレジストリにあるwebsocketsパッケージを取り上げ、脆弱性の修正がリリースされた後も、脆弱性のあるリリースがどれほど広く使われ続けたかを調べました。

websocketsプロジェクトは比較的人気が高く、2013年に始まった、現在まで定期的にリリースが続く、よくメンテナンスされたパッケージです。

2018年8月、パッケージのバージョン4.0および4.0.1に影響するサービス拒否の脆弱性がコミュニティに公開されました。公開時には、すでにセキュリティ修正を含む新しいバージョンがレジストリに存在していました。しかし、脆弱なバージョンのダウンロード数を見ると、その後も多くのユーザーが脆弱性のあるwebsocketsのバージョンを取得し続けていたことがわかります。

2018年12月になっても、websocketsの脆弱性を含むパッケージが1万1,000回ダウンロードされていました。websocketsバージョン5.0としてメジャーアップグレード版の修正版が提供されていたにもかかわらずです。

脆弱性のあるPyPIパッケージ「websockets」のダウンロード数が、2018年8月の30,000件から12月の11,000件へ減少したことを示す折れ線グラフ。

続きを読む：

CTFを始めよう

オンデマンドのバーチャル入門ワークショップを視聴して、CTFの課題の解き方を学びましょう。

今すぐ視聴

カテゴリー:
オープンソースセキュリティDevSecOpsアプリケーションセキュリティ