Snykでpackage.jsonに対する修正のプルリクエスト自動作成機能を試してみました

こんにちは、AWS事業本部コンサルティング部に所属している今泉(@bun76235104)です。

みなさんは各種ライブラリの脆弱性対応やバージョンアップへの追従に疲れたことはありませんか？

私はあります。

Githubにも Dependabotなどの機能がありますよね。

調べたところ、Snykにも依存パッケージの脆弱性を検知して、自動でPRを作成してくれる機能があるようですので、今回はSnykのGitHub統合機能を活用して、リポジトリ上のpackage.json中のライブラリの脆弱性について検知・修正のプルリクエストを自動で出してくれる機能を試してみました!

なお、今回テストのためにあえて古いバージョンのライブラリを使用するように package.jsonを作成しておりますが、本番環境等でのご利用は当然お控えください。

脆弱性が検出されるようなpackage.jsonを用意

今回自動PR(プルリクエストのこと。以降本記事ではPRと略します。)作成のテストをするために以下のようにわざと非常に古いバージョンを指定したpackage.jsonを用意しました。

{
  "dependencies": {
    "axios": "^0.10.0"
  }
}

こちらのファイルをGithubのリポジトリにプッシュしました。

なお、GitHub integration - Snyk User Docsによると現在自動PRはプライベートリポジトリに対応していそうなので、プライベートリポジトリを作成しました。

SnykのWeb UIからGithub統合機能を有効化

以下手順に従って、Snyk Web UIのダッシュボードからGitHubの統合機能を有効にします。

以下のようにリポジトリがプロジェクトとして追加されました。

自動でPRが作成されるように、 Settings => GitHub integration と遷移して、以下のように設定をしました。

SnykからPRを作成できるようにGithubのアクセストークンを発行

Githubのアクセストークンの発行をします。

こちらの記事を参考に発行しました。

実行させたいアクションによって、付与すべき権限の範囲を設定する必要があります。

今回は Brokered GitHub Integrations の表を参考に、Automatic fix and upgrade pull requests を実行して欲しいので repo の全ての権限を付与してみました。

発行したアクセストークンをSnyk Web UIで登録

先ほどGithubで発行したアクセストークンをSnyk Web UIから設定します。

以下、公式サイトの手順に従って設定しました。

画面右上の歯車マーク => Integrations => Github の Edit settings からTokenの設定画面に遷移できました。( Setting an account to open Snyk PRsを参照)

いざ自動PRの作成を待つ・・・

ここまで設定できたので自動でPRが作成されるのを待ってみましたが、どうにもPRが作成される気配がありません。

上で設定したGithubのアクセストークンの不備や権限不足かもしれないため、試しに以下のようにpackage.jsonに古いバージョンのライブラリを追加して直接mainブランチにプッシュしてみました。

{
  "dependencies": {
    "axios": "^0.10.0",
    "express": "1.0"
  }
}

すると以下のように修正のためのPRがSnykにより自動で作成されました。

どうやら権限の問題でPRが作成されなわけではないようです。

Automated pull requests for known vulnerabilities (backlog)のページを詳しくみてみると以下のような記述がありました。

If a scan is manually run (you clicked Retest now for the project), the 24-hour window is marked as having been run and no automatic PR is created until the next automated scan runs

Retest now を実行することで既知の脆弱性(Snyk Web UIにて検出済)についても自動でPRが作成されると勘違いして、私がSnyk Web UIで Retest now を手動で実行してしまっていました。

そこでさらに24時間待つことで、以下のように package.jsonの古いライブラリのバージョンアップを行うためのPRが作成されることを確認しました。

感想

• 依存パッケージのバージョンアップを手動で行う苦行から解放されそう
  • 今回はpackge.jsonのテストでしたが、他の言語の依存性管理ツールにも対応している(Open Source - Supported languages and package managers - Snyk User Docsを参照)
• Snykの場合、他にもDockerfileのチェックや開発中のソースコードのチェックなど機能が充実しているため各種セキュリティチェックも一元化できそう

ローカル環境での開発段階においても、お使いのIDEで危険なコードの検出やアドバイスを出してくれるため、セキュリティ対策がより開発者に近くなりそうです。