はじめに
本記事はSnykを使ってコードをセキュアにした記事を投稿しよう！ by Snyk Advent Calendar 2023に基づいて、プロダクト開発にSnykを導入する際の考え方について記載しています。
組織でセキュリティを担当する者として、脆弱性評価について考えながら、Snykの基本的なことについてまとめています。
これからSnykを導入検討している方のご参考になれば幸いです。
脆弱性評価
手段は目的ではありません。
従ってSnykを導入することを目的にしてはいけません。何故、Snykを導入するのか？何故について考えるところからはじめましょう。
目的
脆弱性はシステムにおけるアプリケーションの設計及び実装の欠陥です。
技術的な脆弱性の例について以下に記載します。
| 技術的な脆弱性 | 概要 |
|---|---|
| TCP/IP | HTTP、FTP、ICMP、SMTPなどの安全性 |
| OS | 脆弱性のあるパッケージなどのパッチマネジメント |
| NWデバイス | ルータ、FW、SWなどネットワークデバイスの脆弱性（例：認証機能など） |
| クラウドセキュリティ | AWSのS３バケットを誤って公開するなどクラウドの設定不備 |
| Webアプリケーション | XSS、CSREF、SQLiなどWebアプリケーションの開発で作り込まれる脆弱性 |
| アカウント管理 | システムアカウントの推測しやすいパスワード |
脆弱性評価の目的は、システムの潜在的な脆弱性を特定し、悪意のある攻撃者がそれらを利用するリスクを低減するプロセスです。
脆弱性評価のライフサイクルの一例について、以下に記載します。
- 資産の特定とベースラインの作成
- 脆弱性スキャン
- リスク評価
- 改善
- 検証
- モニタリング
脆弱性は、深刻度（低〜高）や悪用範囲（ローカル、リモート）によって分類された上でCVEが付与されます。CVEについては、以前書いた脆弱性とエクスプロイトについて理解するをご参照ください。
手段
脆弱性評価に使用される脆弱性スキャンのツールは、以下に示す無償なものから有償なものまで様々なツールが存在します。
上記に挙げたツール以外にもたくさんの脆弱性スキャンのツールがある中、Snykを導入するメリットは何でしょうか？
Snyk導入
Snykは「So Now You Know」の略です。
基本的にはスニークと発音しますが、時々スニックと呼ぶこともあります。
開発を行う組織にSnykを導入するためには、色々な検討事項が発生します。
大規模な組織ほど、導入に対するハードルは上がると思いますが、大規模な組織での一斉展開はリスクが生じやすいため、戦略が必要です。まずはPoCを行なうことで、組織として脆弱性評価を行うことができるか見極めましょう。
導入を見据えた検討事項などについて、以下に記載します。
アカウント設計
前提として、SnykではGoogle、Github、Bitbucketなどの外部IDプロバイダ（IdP）を介したフェデレーションによってユーザーを認証します。従ってユーザー名と、パスワードによる認証メカニズムは提供されていないため、パスワードの管理は不要です。
はじめてSnykを使用する場合は「Snyk を使ってみる」を押して開始します。
以下の様な画面が表示されるのでGitHubやGoogleまたは、それ以外の認証方法を選択します。
個人の場合は基本的にGitHubでも良いと思いますが、会社など組織で利用する場合は考慮が必要です。例えば、会社でGoogle Workspaceなどを使用している場合、Googleアカウントを選択することで、アカウント管理に対するリスクを低減できます。
プラン
Snykの料金プランのページの通りに以下3種類のプランが存在します。
- 無料
- チーム
- エンタープライズ
組織やグループの管理を行いたい場合は、エンタープライズプランが必要です。スタートアップなど小規模な組織の場合はチームプランで十分だと思いますが、大規模な組織やPSIRTなど横断組織として導入を検討する場合は、エンタープライズプランの導入を検討するのが良いと思います。
組織で導入検討を行うにあたり予算の確保は重要なプロセスです。予算の見積りについては、昨今の円安ドル高傾向を踏まえて、為替の変動にも気を配ることが重要です。
PoC
トライアルに申し込むことで、エンタープライズ機能について14日間試すことができます。
なお、申し込み後すぐには使用できないため、余裕を持ってPoCを計画するのが良いと思います。
PoCを行うにあたって、PoCのゴールやPoCで評価すべき内容について、事前に整理しておきましょう。また、導入する組織の協力も必要になってくるため、事前の調整などやるべきことや考えないといけないことはたくさん出てきます。
判断基準
組織で脆弱管理を行うにあたって、Snykなど脆弱性スキャンの仕組みも重要ですが、検出された脆弱性に対する対応の判断など、ルールの整備も重要です。
Snykでは、リスク管理を行うための指標として、以下に示すSeverity levelsやRisk Scoreという値を用いることで、対応に関する意思決定を支援します。
Severity levelsは、各脆弱性の優先度を決定する際に使用される1つの要素です。Critical、High、Medium、Lowの4種類のレベルに分類されます。また、CVSS 3.1を用いてレベルを決定しています。
Risk Scoreは、潜在的な影響と悪用可能性の可能性に基づいて自動計算され、スコアは0～1,000の範囲でリスクを表し、リスクベースの優先順位付けアプローチを可能にします。
CVSSやSSVCなどを用いて判断基準を設けることはできますが、組織の実態に合わせたルール作りが大切です。
Github Organization
組織のGithub OrganizationでSnykを使用するためには、Organizationの管理者からの承認が必要です。
Snykでプロジェクトを追加するときに、Github Organizationのリポジトリが参照できない場合は、以下の記事をご参照ください。
Snykの機能
Snykは、デベロッパーファーストのセキュリティプラットフォームです。クラウドにおけるアプリケーション開発のセキュリティを強化します。
Snykのプロダクトとしては、以下の様な機能があります。これらの機能をソフトウェア開発工程に組み込むことで、DevSecOpsが実現できます。
- Snyk Code（SAST）
- Snyk Open Source（SCA）
- Snyk Container
- Snyk Infrastructure as Code
- Snyk AppRisk（ASPM）
習うより慣れろとは言いますが、サンプルアプリなどを使用して実際に手を動かしてみるのが良いと思います。以下snykのリポジトリには、検証で使えるコードが用意されています。
開発時のセキュリティ
SnykはWeb、CLI、IDE、APIの方法で実行できます。
エディタにVisual Studio Codeを使用している場合は、Visual Studio Code extensionでSnykの機能を使用することができます。
以下はOWASP API Security Projectによって開発されている脆弱性の存在するAPIのアプリケーションです。
上記リポジトリをクローンして、Visual Studio Codeのワークスペースから開いてスキャンした結果が以下になります。
以下のCODE SECURITYの例では、Severity levelsはHighとして、SQL Injectionの脆弱性が検出されています。また、脆弱性のあるコードに対して修正案のコードを提案します。
DockerfileはGit integration（SCM）でスキャンでるものの、CLI/IDEではスキャンできないなど機能差異があります。また、OPEN SOURCE SECURITYについは、Open source and licensing (Snyk Open Source)の通りにサポートされているパッケージマネージャが異なるため、注意が必要です。
運用時のセキュリティ
インポートしたプロジェクトは定期的にスキャンが行われます。
Web（Snyk Web UI）から検出された脆弱性を確認して、修正のプルリクエストを行うことことで、修正に関する時間を大幅に短縮できます。
以下の様にダッシュボードなどからスキャンされた脆弱性を確認して「Fix vulnerabilities」を押します。
以下の様な画面が表示されるので「Open a Fix PR」を押します。
再度「Open a Fix PR」を押します。
GitHubのデフォルトブランチに対して、自動でプルリクエストが作成されます。
脆弱性の検出及び修正案の提供など脆弱性対応に関する工数を削減できます。
SBOM
昨今話題のSBOMについてですが、Snykでは以下のSBOMツールが用意されています。
API及びCLIツールについては、エンタープライプランのみサポートされています。
おわりに
Snykはアプリケーションのセキュリティを強化するために、脆弱性評価を行う手段として、一つの選択肢です。
組織でツールなどを導入する際は、予算をはじめ組織の実態に合わせて導入を考えることが重要です。