IntelliJでSnyk Codeをやってみた～実装してしまった脆弱性を検知してみる～

「安全なソフトウェア開発を、迅速に」を掲げているSnyk（スニーク）サービス。
アジャイル開発センターのメンバーが、実際にSnyk Codeを使ってみました。

まずはSnyk Codeを使ってみよう

開発をしていたら避けては通れないソースコード。
まずはソースコードの脆弱性をチェックしてみましょう、ということでSnyk Codeをアジャイル開発センターで利用している統合開発環境で使ってみます。

チェックしたいソースコードはJavaで実装されているので、IntelliJでSnyk Codeをどう使って、結果をどうやって見ていくのかという点を調べてみます。

Snyk Codeを使う前に確認したいこと

契約内容の確認をしてみましょう

自分たちがどんな契約をしているのか、できる範囲はどこまでなのかを確認してから色々と触ってみましょう。
まず、アジャイル開発センターが契約している内容を確認しました。
契約はBusinessになっているようです。Snyk Codeが実行できる契約になっているので、ソースコードの脆弱性チェックができる状態になっています。
よしよし、問題なし、と。

どうやら、Freeの契約でもTeamの契約でもSnyk Codeは実行できる契約のようでした（Freeだと、実行上限回数があるみたいですが）。

Snyk Codeで何ができるのか、再確認

Snyk Codeで何ができるのかについても、再確認してみます。
前回、「Snykのポイントを解説」でまとめていましたから、その内容を確認します。
下記のような機能でしたね。

案件ごとにコーディングしているソースの脆弱性を検知する機能です。
案件向けにコーディングしたソースコードのエリアに存在する脆弱性を検知します。

機能

1. コーディング中のプロジェクトを対象に脆弱性をチェック
2. 脆弱性のある実装をしている箇所や、シークレットキーなど漏れたら影響が大きい情報が記載されている箇所を検知
3. 検知された内容に対して、修正案を提供

プラグインのインストールと設定

統合開発環境で他のサービスを使う場合、なにはともあれプラグインをインストールする必要があります。
（初期の状態では入っていないので、インストールが必要です）
いつか統合開発環境をインストールしたらSnykのプラグインがインストール済みになる日が来るのを夢見て......
今はインストールを実施しましょう。

IntelliJのSnykプラグインをインストール

検索サイトの結果を参考に、IntelliJにSnykプラグインをインストールしていきます。
インストールするプラグインはSnyk Securityですね。
インストールが完了したら、IntelliJの画面下部に、Snykを実行するためのコンソール（のようなもの？）を表示するボタンが出てきます。下記画像の赤枠の部分です。犬の耳が少し見えていて、かわいい......

Snykプラグインの設定

このまま実行するとあなた誰ですか？と聞かれて、実行できません。
それもそのはず、まだ契約者の情報を設定していません。

次はプラグインの設定をしていきましょう。
どんな情報が必要なのかを確認するために、Snykの設定画面を表示しました。
どうやら、トークンと組織の情報が必要なようです。トークンはSnykの契約サイトで発行できるAPIトークンを入れればよいですし、組織はどのダッシュボードに表示させたいかを入れれば良さそうです。

ということで、Snykの契約サイトでAPIトークンを発行して、ダッシュボードの名前と一緒に設定へ入れてみましょう。

Product Selectionは、チェックがついていたら検査可能な気がなんとなくするので、Snyk Code SecurityとSnyk Code Qualityにチェックを入れておきます。公式ドキュメント^※では上記の設定画面で行っていないようですが、ここでもできることを期待しましょう。

※ JetBrains plugins - Snyk User Docs

いざ、Snyk Codeを実行！

Snyk Codeの実行

ワンちゃんのアイコンをクリックして、Snykのコンソールを表示させてみました。
再生ボタンがあるので、これをクリックすると検査実行してくれるのかな？

クリックしてみたら、検査が開始しました。
検査結果が出てくるまで待ちましょう。
待ちましょう。
まちま......、結構時間かかりますね。そんなにステップ数はないのですが、時間がかかるようです。

実行結果

検査は5分ほどで終わりました。
画面の前で待っていたから時間がかかった気分になったのでしょう。

出てきた実行結果を見てみます。
わざと脆弱性を入れたソースコードだったから（という言い訳をしながら）なのか、脆弱性が沢山検出されました。
「こんなに脆弱性があるのか！」とショックを受けるタイミングはここです。

SQL Injectionの脆弱性が検知されたようなので、検査結果をクリックしてみましょう。
下記画像の赤枠部分ですね。

おっと？何か出ましたよ？

検知した脆弱性が実装されているソースコードの該当部分と、脆弱性の詳細が表示されたようです。
脆弱性の詳細画面に表示されている内容は、脆弱性の概要や脆弱性の詳細情報ページへのリンク、修正方法案が表示されていますね。

検知した脆弱性は、結果ウィンドウにソースコード毎にまとめて表示され、階層構造で確認できるようになっています。
また、脆弱性の原因となる内容（今回のSQL Injectionの場合は、リクエストパラメータをそのままSQL文として文字列結合した値）が、実装したソースコード全体でどのようなデータの流れになっているかがData Flowとして表示されていることがわかります。
検知した脆弱性を、どこでどのように対応すれば解決するのかという確認に有効な情報です。
Data Flowのリンクをクリックすれば、当然のことながらソースコードの該当箇所が表示されました。

がんばって読み解いて、検知した脆弱性を解決していけばよいですね。

最後に

脆弱性の検査は、システムがステージング環境で稼働しており、ある程度までの不具合が解消してから、期間を取って実施することが多いと思います。そうなると、脆弱性検査を行えると判断する時期はプロジェクトの後の方となりがちで、大きな手戻りが発生した場合にプロジェクトが破綻してしまうかもしれません。

それに対し、Snyk Codeでのチェックは意図的に実行させる必要はありますが、ソースコードに潜む脆弱性を一定程度まで開発担当者が見つけられる点で非常に有益です。早いタイミングで脆弱性を見つけて、より早く対応ができれば、期間を取って行う脆弱性検査で検知される脆弱性の数も少なくなり、対応を行うタスクの量が大幅に減るというアドバンテージが生まれてきます（セキュリティの専門家でしか見つけられない脆弱性は、やはりあるものです......）。

Snyk Codeでのチェックを、開発中の特定のタイミングで実施し、脆弱性が検知された場合は対応するようにルール化すると、品質の向上が見込まれるものになります。