脆弱な依存関係に対処する4つのステップ

数週間前、SnykのGitHubとの緊密なインテグレーションをリリースしました。開発にあたっては、既知の脆弱性にできるだけ簡単に対処できるようにしたいと考え、必要なアクションを最もシンプルかつ明確にする方法を検討しました。最終的に4つのステップにまとめることができ、npmやMavenから、ChefやPuppetなどのInfrastructure as Codeツールまで、あらゆる環境で有効であることがわかりました。

この記事では、各ステップと、Snykを使ってnpmで実践する方法を説明します。Snykの例ではGitHubを使ったアプリケーションのテストを取り上げていますが、これらのステップはSnyk CLIでも実行できます。

各ステップ

ツールや環境を問わず、依存関係にある既知の脆弱性に対処するには、次のステップが必要です。

1. 脆弱な依存関係を見つける

2. 脆弱性を修正する

3. 新たな脆弱なパッケージの追加を防ぐ

4. 新たに公表された脆弱性に、迅速かつ効率的に対応する。

最初の2つのステップで、脆弱性のない状態を実現できます。問題を見つけても対処しなければ意味がありませんが、そもそも把握していない問題は修正できないため、どちらのステップも必要です。修正を簡単にすることが重要なのは、すぐに対応できないアラートはつい無視してしまいがちだからです。したがって、ツールは修正をサポートするだけでなく、極めて簡単に実行できるようにする必要があります。

脆弱性のない状態を実現したら、次の2つのステップで、コードの進化や新たな脆弱性の公表後もその状態を維持できます。アプリケーションも脆弱性に関する公開情報も絶えず変化するため、この問題には継続的な対策が必要です。

1）リポジトリ内の脆弱性を見つける

最初のステップは、すべてのプロジェクトをテストして既知の脆弱性を調べることです。

Snykでは、すべてのリポジトリを一括でテストできる画面を用意しています。このブログページまたはテストページで「リポジトリをテスト」をクリックするだけで、npmを使用するすべてのリポジトリに存在する脆弱性を確認できます。

npmを使用する各リポジトリについて、Snykは依存関係をマッピングし、オープンソースの脆弱性データベースと照合します。優先順位を付けやすいよう、脆弱性は重大度に応じて「高」「中」「低」に分類され、クリックすると詳細なテストレポートを確認できます。

2）脆弱性を修正する

依存関係に脆弱性があるプロジェクトでは、次にその脆弱性を取り除きます。問題を見つけるだけでも現在のリスクを評価するうえで役立ちますが、本当に必要なのは問題を修正することです。修正を簡単にするツールへの投資が重要です。そうしなければ、こうしたエラーにすぐ慣れてしまい、無視するようになるでしょう。これは、リンティングやパフォーマンステストなど、ほかの品質テストでも同様です。

Snykは、修正を簡単にすることを最優先にしています。「修正」ボタンをクリックするだけで、脆弱性を解消するために必要なコード変更を自動生成できます。上記の画面からリポジトリをモニタリングし、Snykのプロジェクトページ（「プロジェクトを表示」からアクセス）を開いてください。右上にある「脆弱性を修正」ボタンをクリックすると、問題を修正してすぐにコーディングに戻れるよう、必要最小限の変更を含むプルリクエストが作成されます。

問題を修正するため、Snykはまず、該当パッケージを脆弱性のないバージョンにする最小限の直接アップグレードを探します。そのようなアップグレードがない場合は、脆弱性データベースにあるオープンソースのパッチを使って脆弱性の修正を試みます。

"features-alert.png3）脆弱なパッケージの追加を防ぐ

セキュリティは品質と同様、継続的に取り組むものです。脆弱性のない状態を実現したら、プロジェクトの進化に伴って新たな脆弱な依存関係を追加しないようにする必要があります。また、ほかの品質上の問題と同様、早期に発見するほど、修正は容易でコストも抑えられます。

問題を早期に見つけるには、継続的なテストのフローに組み込む必要があります。一般的には、CI実行時のテストやGitHubのプルリクエストに含めるテストが該当します。

GitHubプロジェクトをSnykと連携すると（上記の「モニタリング」ボタンをクリック）、Snykのテストがプルリクエストの検証手順に追加されます。開発者がプルリクエストを作成するたびに、Snykが変更をテストし、アプリケーションに脆弱性が生じていないか確認します。脆弱性が見つかった場合はテストが失敗し、対処方法の詳細が表示されます。

プルリクエストにテストを追加すると、作業を妨げることなく脆弱なパッケージを見つけやすくなります（しきい値を設定できます）。チームメンバーが不注意によるミスを早期に発見するのに役立ち、オープンソースプロジェクトでは、セキュリティ上の問題を含むコントリビューションを防ぐ有効な手段になります。プルリクエストのテストは通常、マージをブロックしないため、急いでいる場合や影響を考慮した場合は、脆弱性を含む変更をマージすることもできます。

4）新たな脆弱性に対応する

最後のステップでは、セキュリティがほかの品質上の課題と少し異なります。多くの場合、コードを変更したときに新たなバグが生まれます。一方、既知の脆弱性は、コードをまったく変更していなくても発生することがあります。

新たな脆弱性は定期的に公表され、アプリケーションに潜んでいた未知のセキュリティ上の欠陥が明らかになります。こうした欠陥は、ずっとアプリケーション（およびその依存関係）に存在していましたが、公表されると攻撃者に悪用される可能性が大きく高まります。安全を保つには、新たな脆弱性の公表を迅速かつ効率的に把握し、攻撃者に悪用される前に修正できる仕組みが必要です。

Snykは、この対応も簡単にすることを目指しています。GitHubインテグレーションを利用すると、Snykはアプリケーションで使用する依存関係を記録し、package.jsonの変更も継続的に追跡します。新たな脆弱性が公表され、データベースに追加されると、Snykはプロジェクトへの影響を確認します。影響がある場合は、Snyk組織内の全員にメールで通知します。それと同時に、修正プルリクエストを自動作成するため、もう一段階手間を省けます。

すべてのプロジェクトを保護する

テストを実行すると、現在、依存関係に脆弱性があるプロジェクトだけを確認したくなるかもしれません。確かに、2つ目のステップである「修正」が必要なのは、そうしたプロジェクトだけです。

しかし、今日脆弱性がないプロジェクトでも、明日脆弱性が見つかる可能性があることを忘れないでください。新たな脆弱な依存関係が見つかったときに適切に防止し、対応できるよう、すべてのプロジェクトをモニタリングしましょう。

まとめ

以上が、脆弱な依存関係に対処するための4つのステップです。npmの依存関係なら、Snykを使って非常に簡単に実行できます。ほかのプラットフォームでは、利用可能なツールから選べますが、4つすべてのステップに取り組むようにしてください。

今すぐ始めましょう。「リポジトリをテスト」をクリックすれば、準備完了です！