Webサービスやアプリの開発では、リリース直前になって脆弱性が見つかり、改修のために公開がずれ込む、という手戻りが起こりがちです。こうした事態を防ぐために、開発の工程へセキュリティ検査を組み込む動きが広がり、その中心にあるのが「SAST」と「DAST」という2つの検査手法です。
名前は資料やツールの営業で見かけるものの、それぞれが何を・いつ・どのように検査するのか、両者がどう違うのかは分かりにくいものです。SASTとDASTはどちらか一方で十分なのか、それとも両方を使うべきなのかも、判断に迷う部分です。
違いを一言でいえば、SASTはアプリを動かさずにソースコードを内側から、DASTは実際に動かして外側から検査する点にあります。両者は見つけられる脆弱性が異なるため、まずはそれぞれの正体から順に見ていきます。
目次
一括ダウンロードする
SASTとは（静的アプリケーションセキュリティテスト）
SAST（静的アプリケーションセキュリティテスト、Static Application Security Testing）とは、アプリケーションを動かさずにソースコードそのものを解析して脆弱性を見つける手法です。コードの中身を見ながら検査するため、内部構造が分かっている状態で行う「ホワイトボックステスト」に分類されます。
OWASP（Webアプリのセキュリティ標準を策定する国際的な非営利団体）は、SASTを開発の実装フェーズで行うコードレビューの一部と位置づけ、プログラムを実行せずにソースコードを調べる手法だと説明しています。開発の早い段階から、コードを書きながら繰り返し実行できる点が特徴です。
出典・参考資料（1件）
SASTが検出できるもの
SASTが得意とするのは、コードの書き方そのものに原因がある脆弱性です。OWASPは、SQLインジェクション（データベースを不正に操作する攻撃を許す欠陥）やバッファオーバーフロー（想定を超えるデータでメモリ領域を壊す欠陥）といった、よく知られた脆弱性を検出できると挙げています。
また、ソースコードの中に直接書き込まれたパスワードやAPIキー（ハードコードされた認証情報）のように、コード上に文字列として存在する問題も見つけやすい対象です。検出した箇所はファイル名・行番号まで示されるため、開発者が修正に取りかかりやすいという利点もあります。
出典・参考資料（1件）
DASTとは（動的アプリケーションセキュリティテスト）
DAST（動的アプリケーションセキュリティテスト、Dynamic Application Security Testing）とは、実際に動いているアプリケーションに対して外部から攻撃を模した通信を送り、脆弱性を見つける手法です。ソースコードを見ずに、外側から挙動を確かめる「ブラックボックステスト」にあたります。
OWASPは、DASTをブラックボックステストと位置づけ、SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃につながる欠陥を、実行中のアプリに悪意あるデータを送り込んで見つける手法だと説明しています。ソースコードやフレームワークを用意しなくても検査できる点が、SASTと明確に異なります。
DASTが検出できるもの
DASTは、実際に動かさないと現れない問題を見つけるのが得意です。OWASPは、外部から自動でスキャンするDASTの検出対象として、XSS・SQLインジェクション・コマンドインジェクション（サーバーに不正な命令を実行させる攻撃）・パストラバーサル（本来は見えないファイルを不正に読み出す攻撃）を挙げています。
あわせて、サーバーの設定不備（insecure server configuration）も検出対象としています。
サーバーの設定ミスや認証・セッション管理の欠陥のように、コードを読むだけでは判断しにくく、稼働環境で初めて表面化する脆弱性は、DASTの守備範囲です。攻撃者と同じ外側の視点で試すため、実際に悪用されうる状態かどうかを確かめられます。
出典・参考資料（1件）
SASTとDASTの違い（比較表で一望）
ここまでの定義を、検査の観点ごとに並べて比較します。SASTは「コードの内側から」、DASTは「動かして外側から」という視点の違いが、検査対象・タイミング・見つけられる脆弱性のすべてに影響します。
| 観点 | SAST（静的） | DAST（動的） |
|---|---|---|
| 検査の仕組み | ソースコードを実行せず解析（ホワイトボックス） | 動いているアプリに外部から攻撃を模す（ブラックボックス） |
| 検査するタイミング | 開発の早い段階（コードを書く・コミットする時点） | 開発の後半（テスト環境・本番前の稼働アプリ） |
| 主な検査対象 | ソースコード・バイトコード | 実行中のWebアプリ・API |
| ソースコードの要否 | 必要 | 不要（外部からアクセスできれば可） |
| プログラミング言語への依存 | 対象言語・フレームワークに対応が必要 | 言語・フレームワークに依存しない |
| 見つけやすい脆弱性 | SQLインジェクション、バッファオーバーフロー、ハードコードされた認証情報 など | XSS、SQLインジェクション、コマンドインジェクション、サーバー設定の不備、認証・セッションの欠陥 など |
| 見つけにくい脆弱性（限界） | 実行環境・設定の不備、認証・アクセス制御の問題 | ソースコード内部の問題（内部の作りが見えない） |
| 誤検知の傾向 | 多くなりやすい | 実際の応答にもとづくため比較的少ないとされる |
| 実行頻度・所要時間 | 1回が短く、繰り返し実行しやすい | 稼働アプリ全体を外部から試すため相対的に時間を要する |
各手法の定義・強み・限界はOWASPの技術ドキュメントにもとづく（2026年11月時点）
同じSQLインジェクションが両方に挙がっていますが、検出のアプローチは異なります。SASTはコード上の危険な書き方として静的に指摘し、DASTは実際に攻撃を試して反応から検出する、という違いです。
SAST・DASTそれぞれが苦手・見逃す脆弱性（限界）
比較表のとおり、2つの手法は見える範囲が逆です。片方だけで安心すると抜け漏れが生まれるため、それぞれが何を見逃しやすいかを押さえておく必要があります。
SASTはコードを読む手法のため、OWASPは、認証の問題・アクセス制御の不備・暗号の不適切な利用といった脆弱性の自動検出は難しく、コードに表れない設定不備は見つけられないことが多いとしています。あわせて、誤検知が多いこと、自動で見つけられるのはアプリケーションの脆弱性のうち比較的小さな割合にとどまることも指摘されています。
出典・参考資料（1件）
一方のDASTは外側から挙動を見る手法で、OWASPは、DASTはサーバーの応答から脆弱性の有無を判断するものの、アプリの内部の作りは見えない（have no visibility of the internal workings of the app）としています。どのコードが原因かを特定しにくく、ソースコードの中に潜む問題は取りこぼしやすいということです。
さらに、SAST・DASTを含む自動検査には共通の限界があります。OWASPのWeb Security Testing Guideは、自動ツールは「広く検査する」用途には向く一方、自社固有のコードや業務ルールに踏み込めず、ビジネスロジックや独自設計に絡む深刻な欠陥は見逃しやすいと述べています。こうした領域は、専門家による手動の診断が必要になります。
These tools are still generic. They are built for applications in general, not for your custom code and business rules. They can find many common problems, but they often lack the application-specific context needed to detect deeper flaws.
出典：Web Security Testing Guide（Introduction）｜OWASP
SASTとDASTの使い分け（基本は併用）
ここからは、SASTとDASTをどう使い分けるかを整理します。結論から言えば、どちらか一方で十分ということはなく、基本は両方を併用します。両者の見える範囲は補い合う関係にあり、片方だけでは検査に穴が残るためです。
SASTは、OWASPが実装フェーズのコードレビューに位置づけるとおり、開発の早い段階で使います。コードを書いた直後やコミット時に実行し、問題を早く見つけて修正コストを抑える、いわゆる「シフトレフト（検査を開発工程の前方へ寄せる考え方）」の中心になります。
DASTは、実行中のアプリがないと検査できないため、テスト環境や本番前の段階で使います。SASTが見逃す設定不備や実行時の問題を、稼働状態で確かめる役割です。開発の早い段階はSAST、リリース前はDAST、と工程に沿って補い合わせると、リリース直前の手戻りを仕組みとして減らせます。
とはいえ、体制や予算の都合で、いきなり両方は難しいこともあります。まず一つから始めるなら、コードを書くそばから短時間で繰り返し回せるSASTを先に導入し、リリース前の確認としてDASTを加えていくと無理がありません。
開発工程・CI/CDのどこに組み込むか
ここからは、SASTとDASTを実際の開発フローのどこで動かすかを見ていきます。手動で都度実行するのではなく、CI/CD（コードの変更を自動でビルド・テスト・デプロイする仕組み）に組み込んで自動実行するのが基本です。
SASTは、開発者のエディタ（IDE）やコミット・プルリクエストの段階で動かします。OWASPも、SASTは夜間ビルドやCI（継続的インテグレーション）で繰り返し実行できるとしており、コードが変わるたびに自動で検査する運用に向いています。問題のあるコードは、修正されるまでマージできないように制限するのが効果的です。
出典・参考資料（1件）
DASTは、アプリをテスト環境へデプロイした後に実行します。CIパイプラインの後半や、本番前の確認ステップに組み込み、アプリを変更するたびに走らせるのが理想です。
開発の流れに沿って整理すると、各検査はおおむね次の位置に入ります。
- エディタ（IDE）・コミット／プルリクエスト：SASTで、コードを書くそばから検査する
- CIパイプライン：SAST（と、外部部品を調べるSCA）を自動実行し、問題があればマージを止める
- テスト環境へのデプロイ後・本番前：DASTで、稼働中のアプリを外側から検査する
IAST・SCAを含む4手法の位置づけ
SAST・DASTを調べると、IASTやSCAという略語も目にします。これらは別物というより、SAST・DASTで足りない部分を補う手法です。ここで4つの関係を整理します。
アプリケーションセキュリティテスト（AST）とは
SAST・DAST・IAST・SCAは、いずれもアプリケーションの脆弱性を検査する手法で、これらをまとめてアプリケーションセキュリティテスト（AST：Application Security Testing）と呼びます。それぞれ検査の仕組みと見る範囲が異なり、組み合わせて使うことで検査の抜けを減らせます。
IASTとは（実行時にアプリ内部から観測する手法）
IAST（インタラクティブアプリケーションセキュリティテスト、Interactive Application Security Testing）は、アプリのコードに組み込んだセンサー（ソフトウェアライブラリ）を通じて、アプリが動作している間に内部の挙動を観測する手法です。OWASPは、IASTの中核をアプリケーションコードに含めるセンサーモジュールだと説明しています。
外側からしか見えないDASTと違い、内部のコードやデータの流れまで見えるため、SASTとDASTの中間に位置づけられます。実行中の環境で使える柔軟さがある一方、アプリへの組み込みが前提になります。
SCAとは（OSS・ライブラリの既知脆弱性を調べる手法）
SCA（ソフトウェア構成分析、Software Composition Analysis）は、アプリが利用しているオープンソースや第三者製のコンポーネント（部品）を洗い出し、既知の脆弱性やライセンスの問題を調べる手法です。OWASPは、SCAがコードベースの脆弱なコンポーネントを見つけてサプライチェーン攻撃などのリスクを防ぎ、各コンポーネントのライセンス情報も提供すると説明しています。
自社で書いたコードを検査するSAST・DASTとは対象が異なり、外部から取り込んだ部品に潜むリスクを補う関係にあります。OWASPはこの領域をコンポーネント分析（Component Analysis）と呼び、そのソフトウェアに限定した呼び方がSCAだと整理しています。
出典・参考資料（1件）
4手法の比較
4つの手法を、検査の仕組みと見る範囲で並べると、それぞれが補い合う関係が見えてきます。
| 手法 | SAST（静的） | DAST（動的） | IAST（対話型） | SCA（構成分析） |
|---|---|---|---|---|
| 検査の仕組み | コードを実行せず解析（ホワイトボックス） | 稼働アプリに外部から攻撃を模す（ブラックボックス） | アプリ内部のセンサーで実行時に観測 | 利用コンポーネントを突き合わせて分析 |
| 主な対象 | 自社のソースコード | 実行中のWebアプリ・API | 実行中のアプリ内部 | OSS・第三者製の部品 |
| 得意なこと | コードの書き方に起因する欠陥を早期に発見 | 実行時・設定の問題を外側から発見 | 内部まで見える、SAST/DASTの中間 | 既知脆弱性・ライセンスの問題を発見 |
| 補う範囲 | 開発の早い段階で検査 | 本番前の実環境で検査 | 実行環境で内部を観測 | 外部部品のリスクを補う |
各手法の定義・位置づけはOWASPの技術ドキュメントにもとづく（2026年11月時点）
ただし、どの手法も自動検査である以上、前述のとおりビジネスロジックや独自設計に絡む深い欠陥は見逃しやすく、重要なシステムでは専門家による手動の診断と組み合わせることが現実的です。
一括ダウンロードする
自社に合うツール・診断サービスの選び方
SASTとDASTの役割が分かったら、次は自社に何を導入するかです。ツールや診断サービスを選ぶときは、以下のような観点を自社の体制に当てはめて確認しておきたいところです。
- 対応言語・フレームワーク：SASTは対象言語に対応している必要があるため、自社が使う言語をカバーしているかが重要な確認ポイントになります。
- CI/CD・IDEとの連携：GitHubやGitLab、Jenkinsなどのパイプラインや、開発者のエディタに組み込めるかで、継続的に回せるかが決まります。
- 誤検知への対応：特にSASTは誤検知が多くなりやすいため、結果を絞り込んだり優先度を付けたりする機能があると運用負荷を抑えられます。
- レポートの分かりやすさ：脆弱性の箇所や修正方針が具体的に示されるかは、対応のスピードに直結します。
- 運用負荷と料金：自社で回す体制があるか、どこまで費用をかけられるかで、取れる選択肢が変わります。
SASTツールにはSonarQube・Semgrep・Checkmarx・Veracode・OpenText Fortifyなど、DASTツールにはOWASP ZAP・Burp Suiteなど、無料で始められるオープンソースから商用まで幅があります。これらを自社で運用するか、専門家に委託するかが、最初に決めるべき分かれ道です。
DASTのツールそのものを具体的に比べたい場合は、無料のオープンソースと商用サービスの違い・対応範囲・料金・選び方を整理した「DASTツールとは？無料OSSと商用サービスの違い・対応範囲・料金・選び方を比較」も参考になります。
自社運用（ツール導入）か、専門家委託（診断サービス）か
選択肢は大きく2つに分かれます。1つは、SASTやDASTのツールを自社に導入し、開発フローの中で継続的に回す「自社運用」です。CI/CDに組み込んで毎回自動で検査でき、頻度を上げやすい一方、誤検知の切り分けや結果の判断に一定の体制が必要になります。
もう1つは、脆弱性診断の専門会社に依頼する「専門家委託」です。自動検査では見つけにくいビジネスロジックの欠陥まで踏み込んだ診断を受けられ、セキュリティ人材や知識が社内に不足していても、専門家が結果を精査してレポートまで作成します。導入のハードルを抑えながら、質の高い検査を得たい場合に向いています。
どちらか一方に限る必要はなく、普段はツールでCI/CDを回しつつ、節目で専門家の診断を受ける、という組み合わせも有効です。自社の開発体制と予算に合わせて、現実的な形を選ぶとよいでしょう。
専門家への委託も含めて、脆弱性診断サービスを費用相場や選び方から広く見比べたい場合は、カテゴリの比較記事が参考になります。診断方法の種類ごとの費用の目安、依頼先を選ぶときの確認ポイント、無料で使えるツールまでをまとめています。
ツール導入・診断依頼の選択肢（サービス活用）
ここからは、前述の選び方の観点をふまえ、自社運用と専門家委託それぞれの代表例を取り上げます。先に挙げたSonarQubeやOWASP ZAPなどのOSS・商用ツールも選択肢になりますが、ここでは複数の手法を1つにまとめて扱えるサービスとして、1つのSaaSで自社運用できるサービスと、専門家が複数の診断をまとめて請け負うサービスを対比します。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス |
|---|---|---|
| 提供形態 | 自社運用SaaS （ツール導入） | 専門家委託 （診断サービス） |
| 対応する検査 | SAST・DAST・SCA・クラウド設定診断（CSPM）などを1つの管理画面でまとめて実行 | 静的（ソースコード）診断・動的（Web/API）診断・ペネトレーションテストを1社に依頼 |
| 料金 | 無料プランあり 有償は月額5万円台〜 （株式会社AndGo、年間契約・利用者10人まで） | ソースコードAI診断15万円〜 動的診断を含むプランは50万円〜 （MCB FinTechカタログ掲載情報） |
| 特徴 | 複数のスキャナーを1画面に統合。自動トリアージで誤検知を削減。日本窓口の株式会社AndGoが日本語対応・日本円の請求書払いに対応 | 自社開発AI「Red Agent」で高速に解析し、社内のセキュリティ専門家が最終確認してレポートを作成 |
| 向く企業 | CI/CDに組み込んで継続的に自社で回したい内製の開発チーム | 社内にセキュリティ人材が十分でなく、専門家に診断を委ねたい企業 |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
1. Aikido Security（株式会社AndGo）
Aikido Security（アイキドセキュリティ）は、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを、1つの管理画面でまとめて検査できるSaaSです。SASTやSCA、DASTといった複数の検査を単一のツールで自社運用でき、開発元はベルギーのAikido Security、日本では株式会社AndGoが窓口を務めます。
OWASPのツール一覧でも、SASTとDASTの両方にAikidoが掲載されており、複数のスキャナーを1つのシステムに束ねる構成が特徴です。アラートの自動トリアージで誤検知を減らす仕組みや、Slack・Jira・AWSなどとの連携も備えます。無料のDeveloperプランから始められ、日本窓口では日本円の請求書払いにも対応するため、まず自社で試したい開発チームに向いています。
出典・参考資料（2件）
- 出典：Aikido Security 公式サイト
- 出典：Source Code Analysis Tools｜OWASP（ツール一覧への掲載。OWASPは一覧掲載により特定ツールを推奨するものではないとしています）
開発工程の早い段階からセキュリティ検査を組み込むという考え方について、同サービスの日本窓口を務める株式会社AndGoの原氏は、開発現場での捉え方の変化を次のように語っています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker 脆弱性診断サービスは、自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた診断サービスです。ソースコードを読み取る静的診断、稼働中のWebアプリ・APIに対する動的診断、そして実際の攻撃を想定したペネトレーションテストまでを、1社でまとめて依頼できます。
自社運用のツールではなく専門家への委託を選びたい場合の選択肢です。料金は、ソースコードAI診断が15万円から、Web・APIの動的診断を含むプランやペネトレーションテストまで段階的に用意されています。AIで検査を高速化しつつ最終的に人の目で確認する体制のため、社内にセキュリティ人材が十分でない企業でも、定期的な診断を進めやすい点が特徴です。
出典・参考資料（2件）
なぜ定期的な診断が必要とされるのか。同サービスを提供するCoWorker株式会社の一ノ瀬氏は、攻撃する側の変化について次のように述べています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
まとめ
SASTはソースコードを実行せずに解析する静的な手法、DASTは稼働中のアプリを外部から試す動的な手法で、検査する側面が異なります。どちらか一方では検査に穴が残るため、SASTを開発の早い段階で、DASTを本番前で、というように工程に沿って併用するのが基本です。
さらにIAST・SCAを加えれば、実行時の内部や外部部品のリスクまで補えます。ただし自動検査にはビジネスロジックの欠陥などの限界があるため、重要なシステムでは専門家の診断も検討するのが現実的です。自社運用のツールと専門家への委託、どちらが自社に合うかを踏まえて、具体的なサービスの比較へ進んでみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. SASTとDASTとは何ですか？
A. SASTはアプリを動かさずにソースコードを解析する静的な検査手法、DASTは稼働中のアプリを外部から攻撃して試す動的な検査手法です。
SAST（静的アプリケーションセキュリティテスト）は内部構造が見えるホワイトボックステスト、DAST（動的アプリケーションセキュリティテスト）は外側から挙動を確かめるブラックボックステストにあたり、見える範囲が逆になります。OWASPもSASTをコードレビューの一部、DASTをブラックボックステストと位置づけています。
Q. SASTとDASTは、どちらか一方だけでよいですか？
A. SASTとDASTは、基本は両方を併用します。どちらか一方では検査に穴が残ります。 SASTはコードの書き方に起因する欠陥を早期に見つけられる一方で実行環境・設定の問題を見逃しやすく、DASTは稼働環境の問題を外側から見つけられる一方でコード内部の問題を取りこぼします。両者の守備範囲は補い合う関係のため、SASTを開発の早い段階、DASTを本番前に配置して補い合わせるのが現実的です。
Q. ペネトレーションテストとDASTは同じものですか？
A. ペネトレーションテストとDASTは同じではありません。 DASTはツールで自動的に外部から攻撃を模し、既知の脆弱性を幅広く検出する手法です。
これに対しペネトレーションテストは、専門家が攻撃者の視点で手動も交えて侵入を試み、ビジネスロジックの欠陥など自動検査では見つけにくい問題まで踏み込みます。OWASPも、自動ツールは汎用的で自社固有のコードや業務ルールに絡む深い欠陥は見逃しやすいとしており、重要なシステムでは専門家による診断と組み合わせるのが現実的です。
Q. DASTはWebアプリケーション専用ですか？
A. DASTはWebアプリに限定されず、外部からアクセスできるWebアプリやAPIを主な検査対象とします。 DASTはソースコードを見ずに外側から通信を送って試すため、言語やフレームワークに依存せず、稼働していて外部からアクセスできれば検査できます。実務上の中心はWebアプリ・APIで、XSSやSQLインジェクション、サーバー設定の不備などを稼働状態で確かめます。
Q. IAST・SCAは、SAST・DASTと何が違いますか？
A. IASTはアプリ内部に組み込んだセンサーで実行中の挙動を観測する手法（SASTとDASTの中間）、SCAはOSSや第三者製の部品の既知脆弱性・ライセンスを調べる手法です。
SAST・DAST・IAST・SCAはまとめてアプリケーションセキュリティテスト（AST）と呼ばれ、それぞれ検査の仕組みと見る範囲が異なります。IASTは外側からは見えない内部の挙動まで観測でき、SCAは自社コードではなく外部から取り込んだ部品のリスクを補う点で、SAST・DASTと補完関係にあります。
Q. SAST・DASTでは見つけられない脆弱性には何がありますか？
A. ビジネスロジックや独自設計に絡む欠陥は、SAST・DASTを含む自動検査では見つけにくい代表例です。 OWASPは、自動ツールは一般的なアプリ向けに作られており、自社固有のコードや業務ルールの文脈を踏まえた深い欠陥の検出は苦手だとしています。
加えてSASTは実行環境・設定や認証・アクセス制御の問題を、DASTはソースコード内部の問題を見逃しやすいため、重要なシステムでは専門家による手動診断と組み合わせるのが現実的です。
Q. SAST・DASTに、無料で始められるツールはありますか？
A. SAST・DASTには無料で始められるオープンソースのツールがあります。 SASTではSonarQubeやSemgrep、DASTではOWASP ZAPなどが代表例で、無料のオープンソースから商用まで幅があります。
複数の検査を1つのSaaSで扱える商用サービスのように、無料プランから始められるものもあります。ただし誤検知の切り分けや結果の判断には一定の体制が必要なため、運用負荷も踏まえて選ぶことが大切です。
Q. SAST・DASTのツール導入と専門家への診断依頼は、どちらを選ぶべきですか？
A. SAST・DASTの導入形態は、自社の開発体制と予算で選び分けます。継続的に回したいならツールの自社運用、社内にセキュリティ人材が不足し深い診断まで求めるなら専門家への委託が向きます。
自社運用はCI/CDに組み込んで毎回自動で検査できる一方、誤検知の切り分けや結果の判断に体制が必要です。専門家委託はビジネスロジックの欠陥まで踏み込んだ診断とレポートを得られます。普段はツールで回しつつ、節目で専門家の診断を受ける組み合わせも有効です。
脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、SAST・DASTに対応した脆弱性診断サービスやツールの最新資料を無料で一括請求できます。検査手法・対応範囲・料金を並べて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
