SAST・DAST・SCAの違い｜Semgrep／Snykで始めるセキュア開発

前提：アプリケーションセキュリティテストの全体像

まず「セキュリティテスト＝1つの手法」ではないことを押さえます。開発ライフサイクルの各段階で見つけたい脆弱性が違うため、複数の手法を組み合わせるのが実務のスタンダードです。

主要な手法の位置づけは次のとおりです。

このうち、フリーランス案件で導入依頼が来る頻度が高いのはSAST・DAST・SCAの3つです。IASTとRASPはエンタープライズ寄りで、扱えると差別化になります。

SAST（静的アプリケーションセキュリティテスト）とは

SAST（Static Application Security Testing）は、ソースコードをそのまま解析して脆弱性を見つける手法です。アプリを起動する必要がなく、ビルドやコミットのタイミングで自動実行できます。

何を見つけるのが得意か

• SQLインジェクションやXSSにつながる書き方（サニタイズ漏れ・エスケープ不足）

• ハードコードされたAPIキー・パスワード

• 認可チェックが欠けているコードパス

• 暗号化アルゴリズムの誤用（弱い乱数・非推奨のハッシュ関数など）

たとえばSQLインジェクションは、ユーザー入力を文字列連結でSQLに埋め込んだ時点で検知されます。攻撃が実際に成立するかは実行してみないと分かりませんが、「危ないパターン」を早期にコードレベルで叩ける点がSASTの強みです。

苦手なところ

• 認証・認可の設計ミスなど、複数ファイルにまたがるロジック上の欠陥

• 環境依存の脆弱性（本番の設定ミス・ネットワーク経路の問題）

• False Positive（誤検知）が多くなりがちで、ルール調整をしないと現場が疲弊する

SASTを入れるときは「まず全部の指摘に対応する」ではなく、深刻度と実行パスを絞ってCI/CDに残す指摘を選ぶ運用設計がセットで必要です。

ミニFAQ：SASTの誤検知が多くて開発が止まったら？

まず全ルールを有効化せず、Critical/High相当のルールに絞って導入します。次に「このリポジトリでは技術的に発生しない」パターン（例：使っていないフレームワーク向けルール）を除外設定に追加します。それでも残るFalse Positiveは、コードコメントで個別に抑制するSuppression機能を使い、承認プロセスをレビュールールとして定めます。

DAST（動的アプリケーションセキュリティテスト）とは

DAST（Dynamic Application Security Testing）は、稼働中のアプリに外側からHTTPリクエストを送って脆弱性を探る手法です。攻撃者と同じ視点で試すため、実際に成立する脆弱性が見つかりやすいのが特徴です。

何を見つけるのが得意か

• 認証・セッション管理の不備（Cookie設定ミス・セッション固定など）

• 実行時にしか判明しない設定ミス（CORS・Content-Security-Policyの不備）

• サーバの応答から漏れる情報（エラーメッセージのスタックトレース露出）

• SQLインジェクションやXSSが「実際に成立するか」の確認

コード内容を知らずにテストする「ブラックボックス」型のため、言語やフレームワークを問わず動きます。バックエンドが複数言語で書かれた案件でも、DASTなら1つの仕組みで横串の確認ができます。

苦手なところ

• コード内部の問題（ロジックバグの検知精度はSASTに劣る）

• スキャン時間が長くなりやすい（対象範囲や認証設定によっては、中〜大規模アプリのフルスキャンが長時間に及ぶことがある）

• 認証が必要な画面のカバーが難しい（ログインフローの設定が必須）

DASTはCI/CDに組み込むというよりも、ステージング環境に対して定期実行し、リリース前ゲートとして回すパターンが多くなります。

ミニFAQ：DASTを本番環境で回すのは危険？

原則として本番では回さず、ステージング環境で実施します。DASTは実際にリクエストを打つため、本番で回すとダミーデータの流入、DoS的な負荷、意図しないメール送信などの副作用が起きる可能性があります。本番で監視したい場合は、DASTではなくRASPやWAFなど別レイヤーの選択肢を検討します。

SCA（ソフトウェア構成分析）とは

SCA（Software Composition Analysis）は、アプリが依存しているOSSライブラリを洗い出し、既知の脆弱性やライセンス違反を検出する手法です。SASTが自社コード、SCAが外部コードを担当する、と分けて理解すると混乱しにくくなります。

何を見つけるのが得意か

• 使っているライブラリのCVE（既知の脆弱性）

• ライブラリのバージョンが古く、パッチ済みバージョンへの更新が必要な状態

• ライセンスの制約違反（GPL汚染など、公開できないコードにGPLライブラリを混入させていないか）

• 推移的依存（Aが依存するBが依存するC、のCに脆弱性があるパターン）

現代のWebアプリ開発では、フレームワーク・ORM・認証ライブラリなど広範囲でOSSに依存する構成が一般的で、SCAを入れずに脆弱性管理を語るのは実務上難しくなっています。

苦手なところ

• 「脆弱なライブラリを使っているが、その脆弱な関数を自社コードから呼んでいない」ケースも同列で警告される

• 誤検知は少ないが、対応必須の指摘が大量に出ると開発の手が止まる

• 独自にビルドしたライブラリ・社内リポジトリ経由のライブラリはカバレッジが落ちる

近年は「その脆弱な関数を実際に呼んでいるか」を判定する到達可能性分析（reachability analysis）を持つツールが増えており、対応優先度をつけやすくなっています。

ミニFAQ：SBOMとSCAは同じもの？

役割が違います。SBOM（Software Bill of Materials）は「このアプリに何のOSSがどのバージョンで入っているか」の部品表そのもので、静的なドキュメントです。SCAはそのSBOMを継続的に生成し、脆弱性DBと突き合わせて警告する仕組みで、SBOMを生成する機能も含みます。SBOMは調達要件で提出が求められるケースが増えており、SCAツールでSBOM出力機能を持つ製品を選ぶ流れが強まっています。

3手法の比較表：使い分けの判断軸

主要な違いを1つの表にまとめます。

3つは「どれか1つで十分」ではなく、対象が違うため補完関係にあります。ペネトレーションテストとの違いが気になる場合は、実案件での位置づけをまとめたペネトレーションテスト案件の実情｜フリーランスで多い診断案件と単価・資格もあわせて参考にしてください。

なぜフリーランス案件で3手法が求められるのか

セキュリティテストの導入依頼が増えている背景は、大きく3つあります。

シフトレフトとDevSecOpsの浸透

「本番リリースの直前で見つけた脆弱性は、コードを書いた直後に見つけた脆弱性の数十倍のコストがかかる」という考え方から、テストを開発の左側（早い段階）に寄せるシフトレフトが主流になっています。SASTとSCAをコミット時点で回し、DASTをステージングで回す構成がその実装例です。

CI/CDに脆弱性検知を組み込む文化が広がった結果、GitHub ActionsやGitLab CIのワークフローにセキュリティスキャンステップを追加する案件が増えました。既存のCI/CDパイプラインを設計・運用できるSREやプラットフォームエンジニアがセキュア開発案件に呼ばれるルートも一般化しています。

調達要件・規約による導入圧力

金融・医療・公共系の一部案件では、発注者側のセキュリティ調達要件にSAST／SCAや脆弱性診断の実施が含まれることがあります。要件の記載例：

• 「Webアプリケーションに対して脆弱性診断（動的診断・静的診断）を実施すること」

• 「OSSライブラリの既知脆弱性を把握し、Critical/Highについては修正計画を報告すること」

• 「リリース前にSBOMを提出すること」

このタイプの調達要件は、フリーランス案件では客先セキュリティ要件対応｜ISMS・Pマーク・持ち込みPCの実務で扱うようなISMS運用と地続きで、案件参画時に一気に押し寄せます。

AIコード生成の広がりによるレビュー負荷の増加

Copilot・Cursor・Claude Codeなどのコード生成ツールでコード量が増えた結果、人手レビューが追いつかず、機械的な一次スクリーニングとしてSASTを入れたい、というニーズも増えています。この文脈ではプロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイドのようなLLMアプリ固有の脆弱性対策と並列で語られることもあります。

ミニFAQ：個人開発でも入れるべき？

Publicリポジトリなら、GitHubの標準機能（DependabotやCode scanning）で無料の範囲でSCA・SAST相当が有効化できます。個人開発でも、公開しているOSSやポートフォリオリポジトリなら入れておくと副次的な学習効果もあり、案件でも「自分のリポジトリで運用実績あり」と説明できます。

SAST代表ツール：Semgrepの特徴と導入手順

SASTの領域では、近年Semgrepが急速に採用を伸ばしています。ルールベースで動作し、独自ルールを書きやすい点が特徴です。

Semgrepとは

Semgrepは、コードのパターンマッチングでルールを表現するSAST/SCAエンジンです。読み方は「セムグレップ」。オープンソース版（CLI）と、SaaS版のSemgrep AppSec Platformがあります。ルールは公式レジストリで多数公開されており、Python・JavaScript/TypeScript・Java・Go・Ruby・PHPなど主要言語をカバーしています。

対抗として位置づけられることが多いSnyk Code（DeepCodeベース）とは設計思想が異なり、Semgrepは「人が読めるルールを書ける」ことを重視しています。ツール比較記事や導入事例で「SASTはSemgrep、SCAはSnyk」という組み合わせを見かけることが多く、最初のたたき台としては選びやすい構成です。

導入手順（CLI）

執筆時点で公式ドキュメント（Semgrep Documentation）に記載されている手順は以下のとおりです。バージョンは公式ドキュメントで最新の記述を確認してください。

1. pip install semgrep またはmacOSなら brew install semgrep でCLIを入れる

2. リポジトリのルートで semgrep --config auto を実行し、言語を自動検出させる

3. 検出結果を確認し、対応必須のルール（Critical/High）と抑制するルールを整理する

4. .semgrepignore にスキャン対象外パスを追加し、対象を絞る

5. semgrep --config p/owasp-top-ten のように、目的のルールセットに絞って再実行する

GitHub ActionsでのCI/CD組み込み例

• PRイベントで差分のみをスキャンする設定（semgrep ci コマンド）を採用し、フルスキャンは定期実行に分ける

• Critical/Highの検出をPRの必須チェックにし、Medium以下はレポートのみとする

• スキャン結果をSARIF形式で出力し、GitHubのSecurityタブに集約する

カスタムルールの考え方

Semgrepは「このパターンで書かれたコードを検知する」というルールをYAMLで書けます。たとえば「社内で禁止している非同期処理の書き方を検知する」「特定の認証ヘルパーを経由せずAPI呼び出しをしている箇所を警告する」など、組織固有のガードレールをコードレベルで敷けます。

ミニFAQ：Semgrep OSSと有料版の違いは？

無料のCLI版でも、公開ルールを使ったスキャンとCI/CD組み込みが可能です。有料のAppSec Platformでは、複数リポジトリ横断のダッシュボード、SSO、SAML/SCIMによるユーザー管理、AI支援によるFalse Positive判定、Semgrep Supply Chain（SCA）の到達可能性分析などが追加されます。無料版で始めて、運用が回り出したら有料版を検討する順序が現実的です。

SCA代表ツール：Snykの特徴と導入手順

SCAの領域ではSnykが広く使われています。Snyk Open Source（SCA）、Snyk Code（SAST）、Snyk Container（コンテナイメージ）、Snyk IaC（Terraformなど）の4製品を組み合わせるプラットフォーム型です。

Snykとは

Snykは英国発のセキュリティ企業が提供するSaaSで、開発者向けUX（IDE統合・自動修正PR）が強い点が支持されています。無料プランやトライアルで試しやすい時期が多いものの、対象製品数・スキャン頻度・機能範囲の条件は変わることがあるため、Snyk Pricing の公式ページで最新の料金体系を確認してください。

導入手順

執筆時点でSnykの公式ドキュメントに記載されている代表的な導入フローは以下です。

1. Snyk公式サイトで無料アカウントを作成する

2. npm install -g snyk などでCLIを入れる（Node.js以外の言語でも同じCLIから起動）

3. snyk auth でCLIとアカウントを紐付ける

4. リポジトリのルートで snyk test を実行し、依存関係の脆弱性を検出する

5. snyk monitor でスナップショットをSnykに送信し、新規CVEが公表された時点で通知を受ける

6. Snyk WebコンソールでリポジトリをGitHub/GitLab連携し、PRベースの自動修正を有効化する

到達可能性分析（reachability）で誤検知を減らす

Snykの上位プランには「脆弱な関数を自社コードから実際に呼んでいるか」を判定する到達可能性分析があります。呼んでいないコードパスの警告は優先度を下げられるため、対応必須の指摘だけに集中できます。SCAの運用で最初につまずくのが「警告が多すぎて放置される」問題で、到達可能性分析はこの解の1つです。

ミニFAQ：Snykのオープンソース版と有料版の違いは？

無料枠でも snyk test や snyk monitor は使えますが、月間のテスト実行回数・プロジェクト数・スキャン対象製品（Container・IaCなど）に制限があります。到達可能性分析、レポート機能、SSO/SAMLなどは有料プランで解放されます。個人・OSS用途は無料の範囲で十分回るケースが多い一方、商用案件では最初から有料プラン前提で組む場面が多くなります。

DAST代表ツール：OWASP ZAPの特徴と導入手順

DASTで案件に導入される第一候補はOWASP ZAP（Zed Attack Proxy）です。オープンソースで、CI/CDにも組み込めます。

OWASP ZAPとは

OWASP財団が管理するオープンソースのDASTツールで、GUIとCLIの両方から使えます。プロキシとして動作し、ブラウザ経由の操作を記録して自動再生する機能や、REST APIから自動テストを叩く機能を持っています。

執筆時点でOWASP財団の公式サイト（ZAP by Checkmarx）に記載の使い方は、公開バージョンで確認してください。

導入手順（GitHub Actions例）

1. ステージング環境にテスト対象のアプリを起動する

2. GitHub ActionsのワークフローでOWASP ZAPの公式アクション（zaproxy/action-full-scan）を呼ぶ

3. スキャン結果をHTML/SARIFで出力し、成果物としてPRにアップロードする

4. Critical/Highの脆弱性が検出された場合はワークフローをFailにする

5. スキャン頻度は毎日・毎週など、リリースサイクルに合わせて設定する

認証が必要な画面のスキャン

ログインが必要なアプリでは、事前にログイン処理をZAPに教える必要があります。方法は主に3つ：

• フォーム認証：ユーザー名・パスワードをZAPに登録する

• スクリプト認証：JavaScriptでログイン処理をZAPに実装する

• APIトークン認証：ヘッダーに固定トークンを付与する

セッション切れの検出（ログアウトされたら再ログインする挙動）を組めるかがスキャン品質を左右します。

ミニFAQ：BurpSuiteとどう違う？

Burp Suite（PortSwigger社）は、ペネトレーションテスターの手動診断で広く使われている商用ツールです。GUIの使い勝手・拡張機能の豊富さで支持されていますが、Community版は機能制限があり、Professional版は年間サブスクリプションの有料ライセンスです（金額はPortSwigger公式サイトで最新プランを確認）。案件で「自動化してCIに組み込む」目的ならZAP、「専門家が手作業で診断する」目的ならBurpという棲み分けを見かけることが多いです。

3手法の組み合わせパターン

案件のフェーズや予算に応じて、現実的な組み合わせは主に3パターンに分かれます。

パターン1：SAST＋SCAの最小構成

• Semgrep（無料）でSAST、Snyk（無料枠）またはDependabotでSCA

• コスト：無料〜月数万円

• 想定：スタートアップ初期・小規模チーム

• ポイント：まず「書いた瞬間に叩く」体制を作る。DASTは診断ベンダーへの年1回外注で補う

パターン2：DASTを加えたフルスタック構成

• パターン1に加えてOWASP ZAPをステージング環境で定期実行

• コスト：ツール自体は無料。運用工数が乗る

• 想定：一定規模のBtoCサービス、金融・医療の入口

• ポイント：DASTは実行時間が長いので、CI/CDに毎回組み込まず「毎日1回」「リリース前ゲート」の位置づけにする

パターン3：エンタープライズ向け（IAST・RASP追加）

• パターン2に加えてContrast SecurityなどIASTを導入、本番にRASPを配置

• コスト：対象アプリ数・契約範囲・運用支援の有無で変動が大きく、商用製品・サポート込みで高額化しやすい

• 想定：金融・大規模SaaS・厳しい調達要件がある案件

• ポイント：ここまで来ると、フリーランス単独ではなくベンダー側と一緒に運用設計する構成が多い

ミニFAQ：全部いっぺんに入れるとCIが遅くなる？

なります。対策は「差分スキャン」「並列実行」「ゲートを分ける」の3つです。PRイベントでは差分スキャンだけを回し、フルスキャンは定期実行（毎日深夜など）に逃がします。SAST・SCA・DASTは並列で実行できるので、CIランナーの並列度を上げると総時間は詰められます。Critical/Highだけをブロック条件にし、Medium以下はレポートのみに落とすと、緊急でもマージ経路を確保できます。

ケース別：どこから入れるべきか

チームの状態によって、最初に投資すべきツールは変わります。

個人・少人数開発チーム

• Publicリポジトリや契約プランによっては、GitHubの標準機能（Dependabot・Code scanning with CodeQL）でSCAとSAST相当を低コストで始めやすい（Privateリポジトリ・Enterprise相当プランなど適用条件は公式で要確認）

• 案件でセキュリティ要件が来たら、Semgrep CLIをローカルでも回せるようにしておく

• OWASPのOWASP Top 10とは｜Webアプリの主要リスク10カテゴリ解説で主要リスクを把握しておくと、指摘への対応判断が早い

スタートアップ（グロース期）

• 開発速度を落とさないため、まずSCA（Snyk無料枠）を入れて依存管理を自動化する

• 次にSAST（Semgrep）でPRチェックを入れ、Critical/Highのみブロック

• DASTはリリース頻度に応じて、外注1回で概観を取ってから内製化を判断する

中〜大規模開発チーム

• SAST・SCA・DASTを3点セットで運用。ダッシュボードで指摘を可視化

• セキュリティチャンピオン制度（各開発チームに窓口担当を1名置く）を並行導入

• 監査対応のため、SBOM生成・脆弱性対応履歴の保存を義務化

金融・医療系（高セキュリティ要件）

• 上記3手法に加え、IAST・WAF・RASPまで含めた多層防御を検討

• ペネトレーションテストを年次で外注し、SAST/DASTでは拾えないロジック欠陥をカバー

• セキュリティ資格おすすめ｜支援士・CISSP・CEHの難易度と案件影響で紹介されている資格が調達条件になるケースもある

導入時によくある失敗と対策

失敗1：検出結果が多すぎて放置される

新規導入初日に何百件も出て、対応方針を決めないまま放置され、翌週には誰も見なくなるパターンです。

対策：初日は「全ルールを弱く」ではなく「Critical/Highのみ」で回し、対応可能な件数まで絞ります。Medium以下はレポート出力に留め、四半期ごとの棚卸しで扱うと決めます。抑制ルール（Suppression）の承認プロセスをレビュールールに書き、勝手なignoreを防ぎます。

失敗2：CI/CDが遅くなり開発フローを阻害する

フルスキャンをPRごとに走らせると、10分だったCIが数十分になって開発体験が悪化します。

対策：差分スキャン（変更ファイルのみ）と並列実行を組み合わせます。フルスキャンは深夜バッチに回します。DASTは特にCI組み込みではなく定期実行に寄せます。

失敗3：OSSライセンス違反の見落とし

脆弱性ばかり見てライセンスを放置すると、GPL汚染などで自社製品が公開義務に触れるリスクが残ります。

対策：SCAツールのライセンススキャン機能を有効化し、社内で許可するライセンス一覧を明文化します。新規ライブラリ導入時にライセンス確認を必須にする運用ルールを立てます。

失敗4：本番でDASTを回してしまう

「本番でも検知したい」という善意で本番に向けてDASTを回すと、ダミーデータ流入・DoS的な負荷・意図しない通知送信が発生します。

対策：DASTはステージング固定と明文化します。本番の監視は別レイヤー（WAF・RASP・監視ログ）に任せます。ステージング環境が本番と乖離しないよう、IaCで環境同期を保つ運用が前提です。

失敗5：脆弱なライブラリの警告に埋もれて実際の脅威を見逃す

SCAの警告のうち、実際に自社コードから呼ばれていない関数の脆弱性は優先度が下がります。しかし通知が同列に来ると全部を同じ重さで見てしまいます。

対策：SemgrepやSnykが持つ到達可能性分析（reachability analysis）機能を有効にし、「呼んでいる」ものだけをアラート対象にします。機能名・提供範囲はプランで変わるため、詳細は各ツールの公式ドキュメントで確認してください。機能が使えない場合は、依存関係のインポート箇所を目視で確認する手順を四半期ごとに回します。

フリーランスエンジニアがセキュア開発案件で担う役割

公開案件や参画事例を見る限り、セキュア開発の案件でフリーランスに求められる役割は大きく3層に分かれる傾向があります。

導入・チューニング（初期構築）

• SAST/DAST/SCAツールの選定支援

• CI/CDへの組み込み設計と実装

• 初期の誤検知チューニング、ignore/suppressionのルール整備

• 開発者向けドキュメント整備、社内向けの説明会

継続運用（既存パイプラインの改善）

• 新規ルールの追加、既存ルールの見直し

• 検出結果の三役分担（開発者が直す／セキュリティ担当がレビュー／マネジメントが承認）の定着

• SBOM出力・監査対応の運用整備

開発者兼務型（コードを書きながらセキュリティも見る）

• Webアプリ開発案件で「セキュリティにも詳しい人」として参画

• レビュー時に脆弱性の指摘、ツール出力の解釈支援

• SQLインジェクションとは｜仕組み・主要攻撃4種・実装対策と検知方法やXSSとは｜仕組み・3種類の攻撃・実装対策とCSP設計のような個別脆弱性への実装対策を、開発者にペアプロ形式で伝える

セキュア開発の案件は、専業のセキュリティエンジニアの案件よりも「開発の中で守る」比重が大きく、Web開発の実務経験＋SAST/SCA運用経験の組み合わせで差別化しやすい傾向があります。案件の単価感や参入ルートは、セキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジやセキュリティアナリストとは｜仕事内容・年収・SOCの役割となり方を解説でまとめられているレンジが参考になります。

セキュア開発の実務経験を持つエンジニアが、自分の市場単価をざっくり確認したいときは、無料のフリーランスエンジニア単価診断でスキルセット別の目安をチェックできます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

まとめ

違いを一言でいえば、SASTはコード、DASTは動作中アプリ、SCAは依存ライブラリを見る手法です。3つは対象が違うため補完関係で使い分けるものです。実務ではSemgrep（SAST）＋Snyk（SCA）＋OWASP ZAP（DAST）を組み合わせるパターンを見かけることが多く、CI/CDへの組み込みまでできるとフリーランス案件の幅が広がります。

• SAST＝自社コード、DAST＝稼働中アプリ、SCA＝OSS依存

• 「まずSCA、次にSAST、最後にDAST」の順で入れると失敗が少ない

• 誤検知対策は「Critical/Highのみ」「差分スキャン」「Suppressionの明文化」

• 個別脆弱性の実装対策はSQLインジェクション・XSS・プロンプトインジェクションの各記事を参照

• 案件で使えるレベルまで持ち込みたい場合、GitHubの標準機能（Dependabot・Code scanning）から始めて、Semgrep OSS→Snyk無料枠→OWASP ZAPと広げる順序が現実的

セキュア開発の実務経験を積んだあとに市場での立ち位置を確認したいときは、公開案件ベースでまとめたセキュリティエンジニアのフリーランス単価相場や、案件との相性チェックに使えるペネトレーションテスト案件の実情もあわせて参考にしてください。

参照元・一次情報

• Semgrep Documentation

• Snyk Documentation

• ZAP by Checkmarx（OWASP ZAP公式）

• OWASP Foundation