はじめに - 今までのツラミ（Snyk のない世界）
突然ですが皆さん、アプリケーションコードに関するセキュリティ脆弱性の対応・管理をちゃんとやってますか？
👨💻「セキュリティ脆弱性？重要なのはわかるけど、なんかモチベ上がらんのよね…」
ツラい。なんで、モチベが上がらないんだろう。まずは、モチベが上がらない（個人的な）理由を挙げてみることにしました。
1. 優先度をつけて対応しにくい
GitHub の dependarbot が「このパッケージに脆弱性がありまーす！」と言ってくるが、どのように優先順位を付けて対処すればいいかわからない。
👨💻「Critical が 100 件もある！！どれからやればいいんじゃー 😭」
2. package.json / dependencies の内、どのパッケージに脆弱性が含まれてるのかわかりにくい
末端のパッケージに脆弱性があるとアラートが出ているが、依存関係をたどって親パッケージを特定しにくい。
🤖「handlebars のバージョンを上げる必要があります × 12」
👨💻「えっ？ package.json の dependencies のどのパッケージだろう？？（末端のパッケージにパッチを当てるんじゃなくて、親パッケージのバージョンを上げたいんだけどな…）」
3. アプリケーションコード内の依存関係まで見て、本当に影響のあるセキュリティ脆弱性がわからない
package.json / dependencies に追加したパッケージに脆弱性があった場合、脆弱性を含むコードがアプリケーションコード側で依存関係にあるかどうか知りたい（使ってないから無視できる脆弱性なのか判断がつかない）
👨💻「その脆弱性、アプリケーションコード内で使われてるんだっけ？ 何もわからん…」
4. 自分たちが書いたコード自体の脆弱性（コードの書き方の問題）について検知できていない
GitHub の dependarbot はあくまでパッケージに含まれる脆弱性のみを検知するだけで、実際のソースコードに含まれる脆弱性は何もわからない。
👨💻「セキュリティの観点から見ると、脆弱性を含んだヤバいコードを自分自身が書いてしまっているかもしれない…🤔」
A さん「うーん、困ったなぁ。何かいいツールはないものかなぁ…チラッチラッ 👀」
B さん「まさか、そんな便利なツールがこの世の中に存在するなんて考えられないよー 🙄」
Snyk「へい、旦那！ いいツールがありやすぜ！へっへっへ 😎」
そんな面倒ごとも一気に解決！？ そう、Snyk ならね（ホントか？）
ではここからは、Snyk の基本的な機能についてまとめていきたいと思います。
Snyk の主な機能（Snyk のある世界）
主に、以下のファイル群をチェックし、セキュリティ脆弱性を含むポイントを特定します。
- package.json
- Dockerfile
- CloudFormation テンプレート
- ソースコード自体
などなど（Podfile, build.gradle などもチェック対象）
1. Snyk Priority Score: Snyk 独自の優先度スコア
Snyk スコアという独自スコアにより、優先度順にセキュリティ脆弱性がリストアップされます。なので、優先度が高い順に対処すればいいわけです。わかりやすい（以下例）
👆 Snyk の診断結果リスト例（優先度順）
Snyk スコアとはなにか？
Snyk の独自スコアとはいったい何なんでしょうか？大まかには、脆弱性の深刻度（CVSS スコア）だけでなく、そもそも脆弱性をついた攻撃が可能なのか、到達可能性も考慮して独自のスコアリングをしています。
例えば、深刻度が高い（CVSS スコアが高い）けど、到達可能性が低ければ、スコアは低く見積もられます（セキュリティを突破されたらやばいけど、そもそも突破すること自体が至難の業…みたいなケース）
更に詳しい計算方法については、以下の Snyk 公式ドキュメントを参照ください。
👇 Snyk 公式ドキュメント
Snyk Priority Score - Calculation of Priority Score
Exploit Maturity（到達可能性・攻撃される可能性）とは？
Snyk スコア以外にも、Exploit Maturity と呼ばれるステータス（脆弱性をついた攻撃手段が確認されているかどうか）が付いています。この意味についても理解しておきましょう。
👆 Exploit Maturity の例
| ステータス名 | 説明 |
|---|---|
| Mature | Snyk が、この脆弱性に対する悪用コードを公開している（攻撃手段が一般公開されている状態） |
| Proof of concept | Snyk が検証した、この脆弱性を悪用する方法の概念実証または詳細な説明が存在する（Snyk 側で攻撃手段が確認できている状態） |
| No known exploit | Snyk としては、本脆弱性の概念実証や公開されている脆弱性を発見できていない（Snyk 側で攻撃手段を確認できていない状態） |
| No data | データなし。脆弱性の問題ではない（むしろ、ライセンス等の問題） |
基本的に、Mature と Proof of concept のステータスになっている脆弱性は優先的に対処しておくと良いかもしれません（なぜなら、攻撃手段がすでに明らかになっているため）
👇 Snyk 公式ドキュメント
Evaluating and prioritizing vulnerabilities
2. 脆弱性を含む親パッケージの特定
末端のパッケージに脆弱性が含まれている場合、そのパッケージと依存関係にある親パッケージの情報（パッケージの依存性のパス）も教えてくれます。
以下の例の場合、 express-validator というパッケージ内の lodash パッケージに脆弱性があるとわかります。
対応としては、lodash パッケージにパッチを適応するか、express-validator 自体のバージョンアップを検討すれば良い…と解釈できます。
👆 脆弱性パッケージの依存関係の例
3. Reachable Vulnerabilities: アプリケーションコード内で使われているパッケージの依存関係からセキュリティ脆弱性を検知
package.json 内で定義されているパッケージの脆弱性を単に検索しているのではなく、アプリケーションコード内の依存関係まで見て、本当に影響のある（reachable な）セキュリティ脆弱性を検知してくれます。
逆に、アプリケーションコードと直接の依存関係にない unreachable な脆弱性のついては、Snyk スコアは低く見積もられます（最高かよ！）
デフォルトでは OFF になっているので、この機能を使いたい場合は ON にしておきましょう（コードが snyk 側に clone される点はご注意ください）
👆 Snyk の設定画面
👇 Snyk の公式ブログ
Reachable vulnerabilities: how to effectively prioritize open source security | Snyk
4. Code Analysis: 私たちが書いたソースコード自体に含まれるセキュリティ脆弱性の特定
私たちが書いたソースコード自体に含まれるセキュリティ脆弱性（書き方の問題）についても指摘してくれます。ときどき問題となる credential 情報をリポジトリに含めて commit してしまったなんてものも検出してくれます。CI の Snyk によるチェックを入れておくと、より安心ですね。
また、有名なパッケージの場合、以下のように具体的な修正案まで提案してくれます。Disable X-Powered-By header のように、セキュリティ意識の高いメンバーが教えてくれなきゃわからないポイントも Snyk がカバーしてくれるので、マジ感謝。
👆 ソースコードの指摘ポイント例
こちらの機能もデフォルトでは OFF になっているので、この機能を使いたい場合は ON にしておきましょう（コードが snyk 側に clone される点はご注意ください）
👆 Snyk の設定画面
👇 Snyk の公式ドキュメント
Code Security & Code Quality Scanning | Snyk Code
Snyk Learn でセキュリティ脆弱性に詳しくなろう！
「お恥ずかしい話、この脆弱性の意味わかんないんだよなぁ…」と思ったそこのあなた！（私も一緒です）
Snyk Learn というページで、対象の脆弱性の意味について詳しい解説を読むことができます。Learn about this type of vulnerability and how to fix it のリンクから Snyk Learn のページに飛ぶことができます。
👇 Snyk Learn のドキュメント（XSS）
Snyk Learn/Lessons/Cross-site scripting (XSS)
検知された脆弱性を Ignore したい（誤検知 etc... ）
Snyk も万能ではなく、あくまで脆弱性と思しき箇所を指摘しているに過ぎません…。
誤検知だと確認できた場合は、理由を明記した上で Ignore してリストから除外しましょう。
[おまけ] Snyk Advisor
snyk にはセキュリティだけではなく npm パッケージのメンテナンス状態（Popularity, Maintenance, Security, Community 等）をスコアで出してくれるサービスもあります。
👆 ちょい前の larna（スコアが低い例）
👆 AWS CDK（スコアが高い例）
👇 Snyk Advisor のサイト
snyk Advisor
最後に
「セキュリティ脆弱性？？ なんかめんどいなぁ…。どこから手を付けていいかわかんないんだよなぁ…」
「パッケージの更新って重要なのはわかるけど…、Biz とか関係者をうまく説得できないんだよなぁ…」
と思っているそこのあなた！
Snyk を使えば、もっと楽に、セキュリティ脆弱性のポイントを可視化・管理できます。
Snyk のない世界
👨💻「えぇっと、アプリケーションコードに依存しているパッケージのバージョンが古くて…、バージョンを上げる必要があるのです。」
👨💻「（具体的にはよくわかってないけど…）やらないとセキュリティリスクを抱えることになるのです。」
Snyk のある世界
👨💻「我々のプロダクトには、優先して対処すべきセキュリティ脆弱性が 5 件存在します（キリッ）」
👨💻「これらに対処しなかった場合、これこれこういった攻撃（XSS, Prototype Pollution など）を受けて、最悪の場合、顧客の個人情報を引き抜かれたり、システムを乗っ取られるリスクがあります。」
👨💻「ゆえに、〇〇と △△ のパッケージのバージョンを上げる必要があります。これらのアップデート作業を計画に盛り込ませてください！」
（ちょっと大げさだけど、例えばの話）
セキュリティ脆弱性の対応を行って、リストから脆弱性が消えていくのはやった感が出て気持ちいいです。開発チームとしては、内部品質向上 Day を月１で開催するなど、ゲーム感覚でワイワイチームで対応できるとなお良いですね。
Discussion