Snykとは？CLIでの脆弱性スキャンとCI組み込み・料金の実額を実装視点で解説

Snyk（スニーク）は、アプリケーションが取り込んだOSSライブラリ、自社が書いたコード、コンテナイメージ、IaCの定義ファイルを対象に脆弱性を検出する開発者向けのセキュリティ基盤です。特徴はコマンドラインとCIから同じ検査を回せる点にあり、検出だけでなく「どのバージョンへ上げれば直るか」まで提示します。

この記事では、Snyk CLIの導入からsnyk test・snyk monitorの実行、終了コードでCIの合否を決める設計、GitHub Actionsへの組み込み、無料枠と有料プランの実額までを手を動かす順序で整理します。後半では受託開発で導入したときに詰まる箇所と、TrivyやSemgrepではなくSnykを選ぶ条件を条件付きで示します。

まとめ：Snykで検査できる範囲とCIに入れる前に決める設定

先に結論から示します。Snykは入れれば動く道具ですが、設定を決めずにCIへ差し込むとビルドが赤いまま放置される結末になります。

• 検査対象は4系統に分かれる：OSS依存関係（Open Source）、自社コード（Code）、コンテナイメージ（Container）、IaC定義（Infrastructure as Code）で、それぞれCLIのサブコマンドが異なります。
• CIの合否は終了コードで決める：snyk testは脆弱性を見つけると終了コード1を返します。初日から全件で失敗させず、--severity-thresholdと--fail-onで止める範囲を絞ってください。
• testとmonitorは役割が違う：testはその場の判定、monitorはスナップショットをSnyk側へ送って継続監視する指示です。CIでは両方を別ステップで回します。
• 費用は人数に連動する：課金単位は過去90日にプライベートリポジトリへコミットした開発者数です。リポジトリ数やスキャン回数ではありません。
• OSSツールで足りる場面もある：コンテナイメージのCVE検出だけが目的ならTrivyで用は足ります。Snykの投資が効くのは修正提案と継続監視を運用に組み込む場合です。

Snyk CLIのインストールと認証｜snyk authでトークンを通す手順

まずローカルで動かします。SaaSの画面を触る前にCLIを通しておくと、CIで詰まったときの切り分けが速くなります。

Snyk CLIの導入方法｜npm・Homebrew・スタンドアロンバイナリの選び分け

導入経路は複数あります。Node.jsが入っている環境ならnpm、macOSならHomebrew、CIコンテナ内ではNode.js非依存のスタンドアロンバイナリという使い分けが基本です。配布物と対応プラットフォームの一覧はSnyk CLIのリポジトリで公開されています。

# npm経由（Node.js環境）
npm install -g snyk

# Homebrew経由（macOS）
brew tap snyk/tap
brew install snyk

# インストール確認
snyk --version

CIで使う場合、npm経由はNode.jsのセットアップ工程が前提になります。ビルドイメージにNode.jsを含めていないパイプラインでは、スタンドアロンバイナリをダウンロードして実行権限を付ける方式のほうが工程数が減ります。

snyk authでの認証とCI向けのSNYK_TOKEN環境変数の設定手順

ローカルではsnyk authを実行すると、ブラウザが開いてSnykアカウントと紐づきます。保存先はローカルの設定ファイルで、値はsnyk config get apiで取り出せる仕組みです。CI環境ではブラウザを開けないため、この値をSNYK_TOKEN環境変数として渡す方式に切り替えます。CLI全体のコマンド体系はSnyk CLIの公式Overviewにまとまっています。

# ローカル：ブラウザで認証
snyk auth

# 保存されたトークンを確認
snyk config get api

# CI：環境変数で渡す（値はシークレットストアから注入）
export SNYK_TOKEN="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
snyk test

トークンはアカウント単位で発行されるため、個人のトークンをCIへ貼るとその人の退職時にパイプラインが止まります。サービスアカウントを作り、そのトークンをCIへ登録してください。

snyk testで依存関係の脆弱性を検出し終了コードで合否を決める

Snykの中心はsnyk testです。ここでの設計がCIの運用しやすさを決めます。

snyk testの基本実行とseverity-thresholdで報告範囲を絞る指定

snyk testはマニフェストファイル（package.json、pom.xml、requirements.txtなど）を読み、依存ツリーを構築してSnykの脆弱性データベースと突き合わせます。既定では全重大度を報告するため、初回実行では数十から数百件が並ぶことも珍しくありません。--severity-thresholdで報告する下限を引き上げると、視界が一気に整理されます。オプションの完全な一覧はsnyk testコマンドの公式リファレンスで確認できます。

# 高・致命的のみ報告
snyk test --severity-threshold=high

# 修正可能な脆弱性がある場合だけ失敗させる
snyk test --severity-threshold=high --fail-on=upgradable

# 開発依存を含めて検査
snyk test --dev

--fail-onの値はall（アップグレードまたはパッチで直せるものが1件以上）、upgradable（アップグレードで直せるものが1件以上）、patchable（パッチで直せるものが1件以上）の3種です。修正手段が存在しない脆弱性でビルドを止めない構成にしたいときに効きます。

終了コード0・1・2・3の意味とCIの失敗条件を決める判断基準

CIの合否設計で押さえるべきは終了コードです。公式リファレンスでは、0が「スキャン完了・脆弱性なし」、1が「スキャン完了・脆弱性あり」、2が「失敗（再実行が必要／-dでデバッグログ）」、3が「サポート対象のプロジェクトが見つからない」と定義されています。

ここで見落とされがちなのが2と3です。ネットワーク不調やトークン失効による2、マニフェストのパス指定ミスによる3を「脆弱性なし」と同じ扱いにしていると、検査が動いていないのにCIが緑になります。次のように分けて扱ってください。

#!/usr/bin/env bash
set -uo pipefail

snyk test --severity-threshold=high
code=$?

case "$code" in
  0) echo "脆弱性なし" ;;
  1) echo "脆弱性を検出（要トリアージ）"; exit 1 ;;
  2) echo "スキャン自体が失敗（設定・接続を確認）"; exit 1 ;;
  3) echo "対象プロジェクト未検出（パス指定を確認）"; exit 1 ;;
  *) echo "想定外の終了コード: $code"; exit 1 ;;
esac

all-projectsとjson出力でモノレポの結果を機械処理する手順

単一リポジトリに複数のマニフェストが同居するモノレポでは、既定の実行はカレントディレクトリの1件しか見ません。--all-projectsを付けると作業ディレクトリ配下を自動検出し、Yarnワークスペースも対象に含めます。結果をチケット起票や集計へ回すなら--jsonで構造化出力を取ります。

# 配下の全プロジェクトを自動検出
snyk test --all-projects --severity-threshold=medium

# JSONで出力してjqで件数を集計
snyk test --all-projects --json > snyk-result.json
jq '[.[].vulnerabilities[]] | group_by(.severity) | map({severity: .[0].severity, count: length})' snyk-result.json

--all-projectsは検出範囲が広がる分、実行時間も伸びます。プルリクエストのステップでは変更のあったディレクトリに絞り、夜間のスケジュール実行で全件を回す二段構えにすると、待ち時間の不満が出にくくなります。

snyk monitorで継続監視を有効にしtestとの使い分けを決める

testだけを回している現場をよく見ますが、それでは「昨日まで安全だった依存が今日CVEを持った」という変化を捉えられません。

snyk monitorが送るスナップショットとtestとの役割の違い

snyk monitorは依存ツリーのスナップショットを作成してSnyk側へ送り、プロジェクトとして登録します。以後は新しい脆弱性が公開されたタイミングでSnykが照合し、通知が届きます。testがその瞬間の合否判定であるのに対し、monitorは登録行為である点が違いです。挙動の詳細はsnyk monitorコマンドの公式リファレンスに記載があります。

# 依存関係のスナップショットを送信して継続監視を開始
snyk monitor --all-projects

# 組織を指定して登録
snyk monitor --org=<ORG_ID> --all-projects

実行位置にも注意が必要です。プルリクエストのたびにmonitorを走らせると、マージされないブランチのスナップショットがプロジェクト一覧に溜まります。monitorはメインブランチへのマージ後、testはプルリクエスト時、という分担が扱いやすい形です。

project-nameとtarget-referenceでブランチ別に結果を分ける

複数のリポジトリやブランチを登録すると、一覧上でどれがどれか分からなくなります。--project-nameで表示名を、--target-referenceでブランチ名やリリースバージョンを指定しておくと、後から追える形になります。

snyk monitor --all-projects \
  --project-name="ec-backend" \
  --target-reference="$GIT_BRANCH"

--target-referenceを付けずに複数ブランチからmonitorを実行すると、同じプロジェクトのスナップショットが上書きされ、本番の状態が検証ブランチの内容に置き換わります。ここは運用に入る前に決めておく設定です。

GitHub Actionsへ組み込みプルリクエストで脆弱性を止める設定

CIへの組み込みは公式のアクションを使うのが早道です。Snyk GitHub Actionsには、Node、Python、Golang、Maven、Gradle、Ruby、PHP、Docker、Infrastructure as Codeなど言語・ビルドツール別のアクションが揃っています。

snyk/actionsを使ったワークフローYAMLの記述とSNYK_TOKENの渡し方

基本形は次のとおりです。公式READMEに掲載されている構成をそのまま使えます。

name: Example workflow using Snyk
on: push
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

継続監視まで有効にするならwithでcommand: monitorを指定します。argsにCLIのオプションをそのまま渡せるため、しきい値の指定もここで行えます。

      - name: Monitor dependencies
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: monitor
          args: --severity-threshold=high --all-projects

フォークからのプルリクエストでトークンが渡らない制約への対処

公式READMEが明記している制約があります。GitHub Actionsは、リポジトリに設定したシークレットをフォークから作られたプルリクエストへは渡しません。したがってトークンを必要とするSnykのアクションは、フォークPRでは実行されず、外部コントリビューターの変更は検査されないまま通ります。

対処は2つです。フォークPRではSnykのステップをスキップし、マージ前にメンテナ側のブランチで検査する運用にするか、pull_request_targetを使う方式に切り替えるかです。ただし後者はPRのコードを特権付きで実行する形になり得るため、チェックアウト対象を明示的に制御しない限りは前者を選んでください。CIへセキュリティ検査を組み込む全体設計はDevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断で扱っています。

Snyk Open Source・Code・Container・IaCの検査対象の違い

Snykは単一の製品ではなく、検査対象ごとに分かれたプロダクト群です。どれを有効にするかで費用も検出内容も変わります。

6つのプロダクトが担当する検査領域とCLIサブコマンドの対応

公式サイトが挙げているプロダクトは、Snyk Open Source（SCA）、Snyk Code（SAST）、Snyk Container、Snyk Infrastructure as Code、Snyk API & Web（DAST）、Snyk Secretsの6つです。CLIから直接叩けるのは前半4つで、サブコマンドが対応します。

# 自社コードの静的解析
snyk code test --severity-threshold=high

# コンテナイメージの検査（Dockerfileも渡す）
snyk container test node:20-alpine --file=Dockerfile

# Terraform定義の検査
snyk iac test ./terraform

手法としての位置づけを押さえたい場合はSASTとは？DAST・SCAとの違いとCI/CDへの組み込みとDASTとは？SASTとの違い・ZAPでのCI/CD組み込みを先に読むと、どのプロダクトが何の穴を埋めるのか判断しやすくなります。

SnykとTrivy・Semgrep・OSV-Scannerの守備範囲の重なりと差

同じ領域にはOSSツールが揃っています。守備範囲は重なりますが、性格が違います。Trivyはコンテナイメージとファイルシステムのスキャンで広く使われ、OSV-ScannerはGoogleが公開するOSVデータベースを参照する依存関係スキャナ、Semgrepはルールを自分で書ける静的解析ツールです。

Snykの差は、検出後の提示にあります。どのバージョンへ上げれば解消するか、修正のためのプルリクエストを自動で作れるか、そして検出結果を組織単位のダッシュボードで継続管理できるかという点です。検出そのものはOSSツールでも到達できるため、この差に費用を払う価値があるかが判断の分かれ目になります。検出結果を資産管理へつなぐならSBOMとは？ソフトウェア部品表の目的・フォーマットもあわせて設計してください。

Snykの無料プランのテスト回数と有料プランの課金単位を実額で確認する

費用は「人数に連動する」という一点を理解しておけば、見積もりを外しません。

Free・Team・Ignite・Enterpriseの料金と無料枠のテスト上限

公開されているSnykの料金プランでは、2026年9月時点でFreeが0ドル、Teamが開発者1人あたり月額25ドル、Igniteが開発者1人あたり年額1,260ドル、Enterpriseは個別見積りとなっています。Freeプランには月あたりのテスト回数上限があり、プロダクトごとに異なります。

この上限は、CIで毎プッシュごとに検査を回すと早い段階で届きます。1日に10回プッシュする開発が2週間続けば、Code側の100テストは尽きる計算です。無料枠で始めるなら、プルリクエスト時のみ実行する、あるいは対象を絞る設計にしてください。

contributing developer課金で費用が跳ねる条件と抑える運用

有料プランの課金単位は「contributing developer」で、公式には過去90日間に監視対象のプライベートリポジトリへコミットした開発者と定義されています。ここが見積もりの肝です。リポジトリ数を増やしても、スキャン回数を増やしても、人数が変わらなければ費用は動きません。

逆に費用が跳ねるのは、短期の応援メンバーや業務委託が一時的にコミットした場合です。90日間はカウント対象として残ります。監視対象リポジトリの範囲を必要なものに絞る、検証用リポジトリを監視から外す、といった管理が人数の膨張を抑える手当てです。パブリックリポジトリはこの定義から外れる点も、OSSを併営している組織では効いてきます。

受託開発でSnykを後から導入して詰まった箇所と回避に使った設定

ここからは、導入手順の紹介では出てこない部分です。既存プロジェクトへ後から入れるとき、必ず同じところで止まります。

初回導入で数百件の検出が出たときのベースラインの引き方と除外の期限管理

数年動いている案件へ導入すると、初回のsnyk testで三桁の検出が並びます。ここで全件を止める設定にすると開発が進まず、逆に全件を無視すると導入した意味がなくなります。現実的な進め方は、初回の検出を「既存分」として扱い、新しく増えた分だけを止める線を引くことです。

Snykでは.snykポリシーファイルに除外を書けます。ここで手を抜くと形骸化するため、除外には必ず期限を入れてください。期限を書かない除外は永久に残ります。

# .snyk（ポリシーファイル）
version: v1.25.0
ignore:
  SNYK-JS-LODASH-567746:
    - '*':
        reason: 該当機能を使用しておらず影響なし。次期改修で依存ごと入替
        expires: '2026-12-31T00:00:00.000Z'

あわせて、直せない検出の扱いも決めておいてください。フレームワークが依存バージョンを固定していて上げられない、修正版がまだ出ていない、という状況は頻繁に起きます。このとき--fail-on=upgradableにしておけば、直せる脆弱性が増えたときだけCIが赤くなり、手の打てない検出でパイプラインが止まり続ける事態を避けられる構成です。コンテナ側の同種の運用はDockerの脆弱性診断をCI/CDに組み込む手順とツール選定で扱っています。

Snykを採用する条件と見送る場面｜他ツールとの選択の判断基準

最後に判断を言い切ります。すべての案件に入れるべき道具ではありません。

Snykを選ぶ条件｜修正提案とプライベートリポジトリ運用が要る場合

次の条件が2つ以上そろうなら、有料プランを含めて検討する価値があります。プライベートリポジトリで継続的に開発していること。依存の更新を担当する人がいて、修正提案がそのまま作業指示になること。OSS依存・自社コード・コンテナ・IaCのうち3系統以上を1つの管理画面でまとめたいこと。そして脆弱性の検出履歴を、監査や顧客報告に使う必要があること。

逆に言えば、検出結果を受け取って動く人がいなければ、どのプランでも成果は出ません。ツールの導入と同時に、トリアージの担当と対応期限を決めてください。

見送るべき3条件｜OSSツールで足りる場面と体制が整わない場合

見送ってよい条件を挙げます。第一に、検査対象がコンテナイメージのCVEだけである場合。TrivyやOSV-Scannerで同じ検出に到達でき、費用は発生しません。第二に、パブリックリポジトリのOSS開発が中心である場合。GitHubの標準機能とOSSスキャナの組み合わせで足ります。第三に、検出結果を仕分ける担当を置けない場合です。

3つ目が最も多い失敗の型です。導入から3か月後にダッシュボードを誰も開かなくなり、契約だけが残ります。受託開発では、ツール導入と並行してリリース前の手動診断をどう挟むかまで設計しておくと、検出できない領域が残りません。ツールと手動診断の役割分担から相談するなら、脆弱性診断・セキュリティ診断のように両方を扱える相手のほうが工程がつながります。診断そのものの費用感は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準で確認できます。

よくある質問

Snykの導入検討で挙がることの多い質問をまとめました。

Snykは無料でどこまで使えますか？

Freeプランは0ドルで、Open Source 200テスト、Code 100テスト、IaC 300テスト、Container 100テストという月間上限のもとで利用できます（2026年9月時点）。個人利用や小規模プロジェクトの評価には十分ですが、CIで毎プッシュ検査を回すと上限に届きます。まずはローカルとプルリクエスト時に限定して回し、検出の質を確かめてから有料プランを判断する順序が無駄になりません。

snyk testとsnyk monitorはどちらを実行すればよいですか？

両方です。役割が異なります。testはその時点の判定で、CIの合否に使います。monitorはスナップショットをSnykへ送って登録する操作で、以後に公開された新しい脆弱性を検知させるためのものです。プルリクエスト時にtest、メインブランチへのマージ後にmonitorという分担にすると、不要なプロジェクト登録が増えません。

TrivyがあればSnykは不要ですか？

目的によります。コンテナイメージのOSパッケージに含まれるCVEを検出したいだけなら、Trivyで到達できます。Snykに費用を払う意味が出るのは、依存関係・自社コード・IaCまで対象を広げたい場合、修正先バージョンの提案や自動プルリクエストを運用へ組み込みたい場合、そして組織横断で検出状況を管理したい場合です。検出能力ではなく運用機能の差で選んでください。

CIで終了コード1が返り続けてビルドが止まります。どうすべきですか？

止める範囲を絞ります。--severity-threshold=highで報告対象を高・致命的に限定し、さらに--fail-on=upgradableを付けて「アップグレードで直せる脆弱性がある場合だけ失敗」に変更してください。修正版が存在しない脆弱性でパイプラインが赤いままになる状態を避けられます。既存分は.snykファイルへ期限付きで除外を登録し、期限日に再評価する運用にします。

フォークからのプルリクエストが検査されないのはなぜですか？

GitHub Actionsの仕様です。リポジトリに設定したシークレットはフォークから作られたプルリクエストへ渡されないため、SNYK_TOKENを必要とするSnykのアクションは実行されません。公式READMEにも明記されています。外部コントリビューターの変更を検査したい場合は、メンテナ側のブランチへ取り込んでから検査する運用にするのが安全です。

関連記事

• Trivy（トリビー）とは｜使い方・インストール・読み方の入門ガイド：コンテナ検査でSnykと比較されるOSSツールの導入手順です。
• OSV-Scannerとは？Google製OSS脆弱性スキャナの使い方とTrivyとの違い：依存関係スキャナの選択肢を広げる際に役立ちます。
• SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説：Snyk Codeが担う検査手法の位置づけがわかります。
• DevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断を実装視点で解説：検査をパイプラインへ組み込む前提の設計を扱っています。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：ツールで検出できない領域を手動診断で埋める判断に使えます。