Snyk DASTによるWebアプリ脆弱性診断をやってみた

リリース前に「脆弱性診断やった？」とヒヤッとした経験はありませんか。この記事では、Snyk DASTを使ってWebアプリの脆弱性診断をチーム内に取り込み、自動化する手順を紹介します。

2026.07.07

こんにちは。
ゲームソリューション部/業務効率化ソリューション部の西川です。
リリース前に「脆弱性診断やった？」と聞かれて、ヒヤッとした経験はありませんか。

外部ベンダーに依頼して、数週間待って、結果を受け取って、というのが脆弱性診断のよくある姿です。

でも2週間スプリントで回しているチームからすると、このサイクルは噛み合っていません。

この記事では、Snykの動的解析（DAST）製品「Snyk API & Web」を使って、Webアプリの脆弱性診断をチームの内側に取り込み、自動化していく手順を紹介します。
 脆弱性診断が抱える3つの問題 1. リリース頻度と診断頻度のミスマッチ外部に診断を依頼する時は、依頼するたびに準備も調整もそれなりの手間がかかります。

そう何度も頼めるものではなく、現実的には年1〜2回が限界というチームもあると思います。
一方で開発のほうで2週間ごとにリリースしている場合、年に何十回もアプリが変わるのに、診断は年2回なんてこともあるかと思います。

この時点で、守れている期間のほうが圧倒的に短いわけです。

リリースサイクルと診断サイクルが、そもそも別の時間軸で動いてしまっています。
 2. 待ち時間がリリースを止める依頼してから結果報告まで、2週間〜1ヶ月待ちになることはよくあると思います。

その間、チームは「診断が終わるまでリリースを止める」か「診断対象外のまま出す」かの二択を迫られます。
 3. 脆弱性診断の内製化が進められない診断のノウハウが外部ベンダー側に溜まっていって、チームの中に残らない、という問題もあると思います。

担当者が変わるたびにベンダー選定や調整からやり直しになりますし、いざ「脆弱性診断のエビデンス出して」と言われたときに、すぐ出せない状態が常態化してしまうかもしれません。
 [解決策] Snyk DAST（Snyk API & Web）とは何かそこで登場するのが、SnykのDAST製品「Snyk API & Web」です。

DAST（Dynamic Application Security Testing）は、コードを読む静的解析（SAST）とは対照的に、実際に動いているアプリケーションを外側から攻撃してみて脆弱性を見つけるアプローチです。

攻撃者と同じ目線で、動いているWebアプリやAPIにリクエストを投げて挙動を確かめる、実地の健康診断のようなものだと考えるとイメージしやすいと思います。
Snyk API & Web は、2024年にSnykが買収したDASTプロバイダ Probely の技術がベースになっています。
外部ベンダーに依頼する場合との比較ポイントは、CI/CDに組み込めることです。

パイプラインに一度組み込んでしまえば、リリースのたびに自動で診断が走り、日常のフローの一部になります。
 [実際にやってみた] Snyk DASTハンズオン今回は検証用に、意図的に脆弱なWebアプリ「OWASP Juice Shop」をAWS上に立て、それをターゲットにして試しました。
 Step1 Snyk DASTのセットアップまずは Snyk API & Web のアカウントを作成し、Snyk API & Web の Targets 画面を開きます。

右上の「Add」から診断対象を登録していきます。
対象の名前とURLを指定します。
 Step2 スキャンの実行ターゲットを登録したら、あとはスキャンを実行するだけです。

「Scan」から「Scan now」を選ぶと、その場でスキャンが始まります。後述するようにCI/CDやAPI経由でも起動できます。
実行すると「Scan started successfully」と表示され、Snykが実際にリクエストを投げながらアプリを探索していきます。
 Step3 脆弱性レポートの確認スキャンが終わると、検知された脆弱性が Findings に一覧で表示されます。

それぞれに深刻度（Critical/High/Medium/Low）と、どこで何が起きているのかの説明が付くので、どれから直すべきかの優先度がひと目で分かります。

今回の Juice Shop でも、/rest/products/search や /rest/user/login の SQL Injection（Critical）や、通信の平文化（Unencrypted communications）など、実際に動かしてみないと分からない類の問題がしっかり挙がってきました。
 Step4 エビデンスの取得レポートをその場でエクスポートできます。Findings画面の「Download CSV」から、出力する項目を選んでダウンロードすることができます。
ID・深刻度・URL・CVSSスコアなど、必要な列を選んで出力できます。

これで「脆弱性診断のエビデンス出して」と言われても、その日のうちに提出できます。
 CI/CDへの組み込み（応用編）ここまで来たら、最後は自動化です。

GitHub Actionsのワークフローにスキャン起動を組み込んでおけば、リリースのたびに診断が自動で走ります。
.github/workflows/dast.yml
name: DAST Scan
on:
  push:
    branches: [main]

jobs:
  dast:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Snyk API & Web scan
        run: |
          curl -X POST "https://api.probely.com/targets/${TARGET_ID}/scan_now/" \
            -H "Authorization: Bearer ${SNYK_DAST_TOKEN}"
        env:
          TARGET_ID: ${{ secrets.SNYK_DAST_TARGET_ID }}
          SNYK_DAST_TOKEN: ${{ secrets.SNYK_DAST_TOKEN }}
!上記はAPI経由でスキャンを起動する構成のイメージです。実際のエンドポイントや認証方法は公式ドキュメント（developers.probely.com）に沿って設定してください。
これで、人間が思い出して手動で回すのではなく、コードを出せば勝手に診断が回る状態を作り出せます。
 さいごに今回の話を整理すると、こんなところです。
Snyk DAST（API & Web）なら、動いているアプリを即日・いつでも診断できる
CI/CDに組み込めば、診断はリリースフローの一部として自動で回る
Snyk DASTの導入支援・PoC支援も承っています。

お気軽にお声がけください。
本記事が、脆弱性診断の頻度やスピードに悩んでいる方のご参考になっていれば幸いです。