オープンソース セキュリティの専門企業である Snyk は、利用可能なパッケージの脆弱性に関するデータと、開発者や DevOps チームから、これがもたらす課題にどのように対処しているかという回答を組み合わせた新しい調査を発表しました。
クリックして拡大（Snyk経由）
問題は簡単に説明できます。今日のソフトウェア開発では、オンラインリポジトリのパッケージを利用するのが一般的です。開発者はWebアプリケーションを開発する際に、まずnpm.js（100万以上のJavaScriptパッケージから選択可能）、Maven（Javaの場合）、NuGet（.NETの場合）、PyPI（Pythonの場合）からライブラリをインストールすることから始めます。
各パッケージは、依存する他のパッケージをプルダウンする可能性があります。その結果、アプリケーションと共にデプロイされる大量のコードが、開発者によって書かれたものではなく、セキュリティ上の脆弱性を含んでいる可能性があります。
間接的な問題
Snyk社の調査は、500人の開発者、セキュリティ専門家、運用担当者からの回答、同社独自の脆弱性データベースのデータ、Snyk社が「現在監視している数十万のプロジェクトからの相関データ」、そして多数のコードリポジトリを管理しているGitHub、GitLab、Bitbucketなどのソースから公開されたデータに基づいています。
報告書によると、問題の大部分は開発者にとって最も見えにくい間接的な依存関係に起因している。npm.jsの場合、脆弱性の約80%が間接的な依存関係に起因している。朗報としては、「最も人気のあるエコシステム」全体で新たな脆弱性が約20%減少しているが、依然として懸念すべき点は多い。
どのような脆弱性でしょうか？リストのトップはクロスサイトスクリプティングです。これは、適切にサニタイズされていないユーザー入力などの技術によってJavaScriptがサイトに挿入されるものです。
昨年2番目に多かった脆弱性は悪意のあるパッケージで、信頼できるパッケージが攻撃用に作成されたパッケージに汚染されるものです。さらに詳しく調査したところ、研究者たちは「現在スキャンされたプロジェクトに影響を与えている」脆弱性のトップはプロトタイプ汚染、つまりオブジェクトのベースクラスを変更することで動作を改変するJavaScript攻撃であることを発見しました。プロジェクトへの影響度別に脆弱性のトップをリストアップすると、プロトタイプ汚染に続いて、信頼できないデータのデシリアライゼーション、サービス拒否、正規表現によるサービス拒否（奇妙なことに、正規表現は独自のカテゴリに分けられています）、そして任意コード実行が続きました。
歴史的に大きな問題であったSQLインジェクションは、減少傾向にあるようです。しかしながら、研究者らはPHPパッケージにおけるSQLインジェクションの脆弱性が増加していると報告しています。
Snykは、アプリケーションデプロイメントのトレンドであるコンテナとKubernetesに関する問題にも着目しました。Dockerイメージには、ベースとなるLinuxのバージョンに起因する深刻な脆弱性が含まれていることが多いと報告されていますが、ベースイメージをスリム化することでその問題は改善されるとのことです。
Kubernetesクラスターへのデプロイ時に、ITチームはHelmチャートやその他のマニフェストのセキュリティを確認していますか？ほとんどのITチームは手動レビューに頼っていますが、31%は「わからない」と回答しました。
Snyk 氏は次のように指摘しています。「Kubernetes クラスターを定義するときに、そのクラスターのセキュリティに直接影響を与える重要な構成上の決定が数多くあります。」
Snyk社にこの報告書の文脈について説明を依頼しました。開発者がオープンソースへの依存関係を通じて意図せずアプリケーションに脆弱性を加えてしまう問題は、どれほど深刻なのでしょうか？
「この問題は非常に深刻です」と、Snykの社長兼共同創業者であるガイ・ポジャーニー氏は語った。「あるオープンソースパッケージを使う開発者は、通常、無意識のうちに他の何十ものパッケージも使ってしまいます。既知の脆弱性のほとんどはこれらのパッケージに存在し、一般的なアプリは数百ものライブラリを使用しているため、その中のどれかに深刻な脆弱性が存在する可能性は高いのです。」
さらに、OSの脆弱性は、脆弱なコードが容易に発見でき、1つの脆弱性で多くの被害者が発生するため、攻撃者にとって格好の標的となります。そのため、最も経験の浅い攻撃者でさえもこうした問題を悪用することができ、結果としてボットネットがこれらの脆弱性を狙うようになります。
「これらを合わせると、システムで OSS の脆弱性が悪用される可能性はかなり高くなり、独自のコードに欠陥が見つかり悪用されるリスクをはるかに上回ります。」
では、DevOpsチームに求められる行動とは何でしょうか？「最初のステップは明らかに可視性です。使用しているコンポーネントを把握し、Snykのような脆弱性データベースと比較する必要があります」とPodjarny氏は述べています。
しかし、次のステップは組織全体でトリアージを行うことではなく、問題の解決に着手することです。トリアージにエネルギーを費やしすぎて解決を怠ると、結果としてより大きなリスクを負うことになります。つまり、優先順位付けは重要ですが、実際に解決すること以上に重要なことはありません。
1つのオープンソースパッケージを使用する開発者は、通常、無意識のうちに数十のパッケージを組み込んでしまいます。既知の脆弱性のほとんどはこれらのパッケージに存在し、一般的なアプリでは数百のライブラリが使用されているため、それらのパッケージに深刻な脆弱性が存在する可能性は高くなります。
開発者がプロジェクトに腰を据えて取り組むには、大変な要求のように思えます。これほど多くのパッケージや依存関係を詰め込むことが間違っているとしたら、開発者は一体何をすべきでしょうか？「開発者は部品表（BOM）を理解することが重要です」と、Snykの開発者リレーション担当副社長、サイモン・メイプル氏は述べています。
どのような脆弱性が存在するかを把握すれば、「リスクを軽減する方法はいくつかあります。アップグレードパスは存在するか？あるいは、修正されていない脆弱性が存在する場合、十分な入力検証など、そのコードパスが攻撃されるのを防ぐために必要な対策を講じるなど、防御的なコードを書く必要があるか？また、オープンソースパッケージを選ぶ場合、メンテナーは何人いるか？脆弱性が発見された場合、どれくらい迅速にパッチを提供するか？」
人間がそこまで詳細に依存関係をすべて把握できるでしょうか？自動化は避けられないようです。「ライブラリの健全性に関する情報を提供してくれるツールはたくさんあります」とMapleは述べています。そして、これはまさにSnykの事業であり、同社の推奨事項には利己的な意図があることにも留意してください。
開発者は使用するパッケージの数を最小限に抑えるべきでしょうか？「慎重に行動したいですが、開発におけるアジャイルな側面は維持したいと思っています」とメイプル氏は言います。「オープンソースは活用する必要がありますが、それが私たちにどのような影響を与える可能性があるかを考慮し、責任を持って活用する必要があります。」
ログインに多要素認証を必要とするファイアウォールの背後にあるアプリケーションはどうでしょうか。開発者は、こうしたアプリケーションは攻撃を受ける可能性が低いと主張できるでしょうか？「ハッカーはそのような開発者を好みます」とメイプル氏は言います。「ファイアウォールを突破すれば、たちまちパーティータイムになるからです。」®
