目次
1. シフトレフト・テストとは
2. アプリケーション・セキュリティ・テストとは
3. Snykの製品紹介
4. Snykを導入する５つのメリット
シフトレフト・テストとは
シフトレフトテストとはアプリケーションやインフラのテストでテストをソフトウェア開発ライフサイクル（SDLC）の早い段階で実施する手法です。
シフトレフト・テストの考え方
ケント・ベックとシンシア・アンドレスの共著 Extreme Programming Explained: Embrace Chang（邦題: エクストリームプログラミング) の一節に
Here is the dilemma in software development: defects are expensive, but eliminating defects is also expensive. However, most defects end up costing more than it would have cost to prevent them.
ソフトウェア開発のジレンマ: バグや不具合がシステムにあることは決して安くないが不具合自体をなくすことも高価である。しかし、ほとんどの場合、不具合に対する修正コストは、それを防ぐために払うコストよりも高くなる。
とあります。言い換えるとソフトウェアの品質を確保する上で最もコストのかからない方法とは不具合を早期に発見し対応することとなります。
シフトレフトは開発の初期段階でテストを実行して不具合を発見し、修正コストが低いうちに対処すると言う考え方です。
シフトレフトに従わないとどうなるのか
シフトレフトの考え方がプロジェクトで採用されなかった場合どうなるのでしょう。
例えば不具合がプロジェクトの中盤〜後半で発見された場合、不具合を修正する時間は少なくなっているでしょう。そのため修正が後のインクリメントやバージョンに先送りされる可能性が高くなります。
また、もしも次のリリースでも不具合を修正する時間が確保できなかった場合技術的負債は大きくなりプロジェクトは破綻します。
シフトレフト・テストとはプロジェクトを炎上させない、もしくは破綻させないためのテスト手法の一つであるとも言えそうです。
アプリケーション・セキュリティ・テストとは
アプリケーション・セキュリティ・テスト(AST)はアプリケーションのコードや状態を解析し、脆弱性を検知します。アプリケーション・セキュリティ・テスト(AST)の分類方法は個人や組織により様々だと思います。この記事ではSnykとはどのようなサービスか？が理解しやすくなるように分類して説明します。
静的解析
静的解析（SAST）はソースコートを実行せずに脆弱性を検知します。非常に数多くのテストがあります。一例を挙げると
- SQLインジェクション
- クロスサイトスクリプティング
- バッファオーバーフロー
- 秘匿情報の混入
- コードの規約違反
などの脆弱性を静的に検知します。
動的解析
動的解析（DAST）はアプリケーションを稼働させ（主にはQA環境）外部から攻撃を加え脆弱性を検知します。動的解析（DAST）はブラックボックステストとも呼ばれます。サービス提供側がユーザーからの意図しない操作をソフトウェアに対して実行し脆弱性が発見されないかを調べる事が多いかと思います。
- 侵入テスト
- 総当たり攻撃
この辺りがよく行われます。
インタラクティブ・アプリケーション・セキュリティ・テスト(IAST)
インタラクティブ・アプリケーション・セキュリティ・テスト（IAST）は静的解析（SAST）と動的解析（DAST）を合わせたテスト手法です。
具体的にはコードからビルドした成果物もしくは稼働中のソフトウェアに対して
- ライブラリ
- フレームワーク
- スタック・トレース
- データフロー
- HTTPリクエスト/レスポンス
などのソフトウェアのコンポーネントやデータフローを解析し脆弱性を検知します。
静的解析（SAST）と動的解析（DAST）がシステムの一時的な状態の脆弱性を検知するのに対してインタラクティブ・アプリケーション・セキュリティ・テスト（IAST）は継続的に脆弱性を検知します。
アプリケーション・セキュリティ・テストにおけるシフトレフト・テスト
アプリケーション・セキュリティ・テスト(AST)においてテストをソフトウェア開発ライフサイクル（SDLC）の初期に実行すると効果が大きいものは何でしょうか？
一般的には静的解析（SAST）とインタラクティブ・アプリケーション・セキュリティ・テスト（IAST）に分類されるテストとされる傾向があります。
Snykの製品紹介
Snykはアプリケーションの脆弱性を調べるサービスです。Snykの得意分野は静的解析（SAST）とインタラクティブ・アプリケーション・セキュリティ・テスト（IAST）です。
Snykの導入方法
Snykは以下のうちのいずれか、もしくは複数の方法で導入できます。
- IDEへプラグインとしてインストールする
- CLIから実行する
- 各種ソフトウェア構成管理（SCM）と連携させる
- 各種コンテナレジストリと連携させる
Snyk Code
コードの静的解析（SAST）を行うツールです。
IDEと連携しリアルタイムにコードの不具合を表示します。また各種ソフトウェア構成管理（SCM）と連携しコードレビューにも採用できます。
参考サイト
- Snyk Code で究極のShiftLeftを体験する【Snyk アドベントカレンダー】 - Qiita
- 脆弱性検出ツール「Snyk Vulnerability Scanner」 vs. 脆弱性だらけのWebアプリケーション「EasyBuggy」 - Qiita
- Snyk Code - Snyk User Docs
Snyk Open Source
ソフトウェアで利用されているOSSライブラリの脆弱性を検知します。各種ソフトウェア構成管理（SCM）と連携します。以下の機能があります。
- 脆弱性を検知し自動もしくは手動でpullリクエストやmergeリクエストを作成する
- 各言語のパッケージマネジャーからインストールされるパッケージの脆弱性を検知しスコア、対処方法などを表示する
- ソフトウェアライセンスのコンプライアンス違反の検知
- パッケージの依存関係をグラフィカルに表示する（pipdeptree、npm lsのような機能）
参考サイト
Snyk Container
コンテナイメージにインストールされているパッケージの脆弱性を検知します。以下のサービスやツールと連携し脆弱性が検知されます。
- CLIツール
- SCM（リポジトリに登録されたDockerfileを解析する）
- ローカル環境下でビルドされたコンテナイメージ
- CIツール（Snykから提供されるAPIを通じてCIパイプラインの処理で検出する）
- ACR、GCR、ECRなどの各種コンテナレジストリ（対応コンテナレジストリ一覧)
参考サイト
Snyk Infrastructure as Code
Terraform・CloudFormation・Kubernetesの３つのソフトウェアの設定ファイルの脆弱性を検知します。
ソフトウェア構成管理（SCM）と連携したりCLIでも動作します。
参考サイト
Snykを導入する５つのメリット
簡単にSnykの機能を見てきました。Snykを導入すればアプリケーション、コンテナ、バッケージ、ライセンス、IaCなど様々な場面で脆弱性を検知できることが分かりました。
最後にSnykを導入するメリットについて見てみます。
コードの修正コストが大幅に下がる
おそらくSnykを導入する最大のメリットです。Snyk製品を導入すればgit commit・push前およびリリース・デプロイ前にシステムの脆弱性を検知できます。
シフトレフト・テストを導入することによりコードの修正コストが大幅に下がります。
アプリケーション・セキュリティ・テストが簡単に導入できる
SnykはSnyk自身がコードやビルドされたコンテナイメージを解析します。既存のCIパイプラインに組み込まなくても独立して動きます。そのためSnykの導入はCIパイプラインのコードに変更を加える必要がありません。
スケールさせやすい
最近のWebアプリケーションはKubernetesなどのコンテナオーケストレーションツール環境下で稼働する事も多くアプリケーション単位、もしくは機能単位でGitリポジトリが分かれている事も多いと思います。
通常CIパイプラインの処理の中で静的解析（SAST）をしたい場合CIパイプラインへコードベースで処理を書いていきます。この手法は何らかの変更があった時に（例えばlinterがアップデートされた、脆弱性スキャナツールをAからBへ変更するなど）全てのリポジトリで修正が発生します。
Snykは導入するのにコードへ書かなくても良いため管理対象のGitリポジトリが増えても対応しやすいのです。
脆弱性情報の共有がしやすい
Snykには検知された脆弱性に対して詳細でグラフィカルなレポートを出力する機能があります。レポートは脆弱性の危険度、修正方法などがすぐに確認できるように整理されています。また脆弱性を修正するためのpullリクエストやmergeリクエストもSnykから作成することができます。
メンバー同士でのシステムの脆弱性の共有が容易になります。
製品のリリースが速くなる
例えばアプリケーションをコンテナで運用する場合、ビルドされたコンテナイメージのソフトウェアパッケージに脆弱性がないか調べたいことがあります。実はこの処理はCIツールとは相性が悪いです。
CIは通常直線的に流れていきます。またCIの実行結果は成功か失敗かのどちらかです。そのため脆弱性スキャナで検知された脆弱性に対して脆弱性をゼロにしようとしているといつまでたっても製品のリリースができません。なぜなら脆弱性を完全に無くすのは不可能だからです。
なのでまずは製品をリリースし、脆弱性はあとから対応する。脆弱性への対応は出来る範囲でやるのが良いでしょう。