SOC 2コンプライアンス向けに監査対応のペンテストレポートを最速で入手する方法

B2B SaaSスタートアップが、コンサルティング会社による4週間の待ち時間を回避し、監査対応のSOC 2ペンテストレポートと証明書（Letter of Attestation）を数週間ではなく数日で入手する方法を解説します。

Sohaib Harraoui 2026年9月16日更新 2026年10月5日

SOC 2コンプライアンス向けに監査対応のペンテストレポートを最速で入手する方法は、自律的な探索とエクスプロイト検証を組み合わせたオンデマンドのAIペネトレーションテストプラットフォームを利用することです。スタートアップはWeb、API、モバイルをまとめてテストし、決定論的なエクスプロイトの実証を受け取り、証明書（Letter of Attestation）を取得できます。Coreアセスメントの所要期間は5～7日と見積もられ、より大きなスコープでは10～20日かかります。

エンタープライズとの商談をまとめることは、アーリーステージのB2B SaaS企業にとって最も困難なマイルストーンの一つです。チームは何か月もかけて製品価値を示し、関係者の合意を取り付け、商業条件を交渉します。ところが最終承認の段階で、企業の調達部門がプロセス全体を止めてしまいます。サードパーティリスク管理（TPRM）チームからベンダーセキュリティ評価が送られてきて、過去12か月以内の日付が入った独立したペネトレーションテストレポートと正式な証明書（Letter of Attestation）の提出を求められるのです。

従来のセキュリティコンサルティング会社では、日程調整に3～5週間のリードタイムが必要で、ある時点のアセスメントに対して15,000ドルから40,000ドルが請求されます。運転資金に限りがあり、四半期の営業ノルマが差し迫っているスタートアップにとって、予定されたテスト枠を1か月待つことは売上の勢いを止めてしまいます。逆に、基本的な自動脆弱性スキャナーを実行してその結果のPDFを提出すれば、企業の調達部門からもSOC 2監査人からも即座に却下されます。

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           FAST-TRACK AUDIT EVIDENCE PIPELINE                            │
└─────────────────────────────────────────────────────────────────────────────────────────┘

   [Target Assets] ──► [Agentic Deep Scan] ──► [Deterministic Proof] ──► [Developer Remediation]
      • Web Apps          • Autonomous Agents     • HTTP Request/Resp        • Actionable Curl PoCs
      • REST/GraphQL      • Contextual Chaining   • Differential Baseline    • Zero Triage Friction
      • iOS & Android     • Logic & Auth Checks   • Low False Positives
                               │
                               ▼
   [1-Click Re-Test] ──► [Finding Review] ────► [Audit Package Export] ──► [Unblock Sales]
      • Risk Rerun Pass     • Named Sign-off      • Attestation Letter (LoA)   • Pass SIG / CAIQ
      • Verified Retest     • Quality Review      • Executive Summary (NDA)    • Close Deals Fast

企業のTPRMチームはペンテストレポートの何を確認しているのか

企業のサードパーティリスク管理（TPRM）チームは、提出されたペンテストについて主に4つの基準を確認します：12か月以内の日付が入った独立した証明書（Letter of Attestation）、包括的なマルチアセットのスコープ（Web、API、モバイル）、未解決の高またはクリティカルの検出結果がゼロであること、そして認知されたフレームワーク（OWASPおよびNIST SP 800-115）に対応付けられたテストです。

企業のセキュリティチームがベンダーリスクを評価する際には、Shared Assessments SIG Lite（v2024/2025）、Cloud Security Alliance Consensus Assessments Initiative Questionnaire（CSA CAIQ v4）、Whisticのベンダープロファイルといった標準化されたフレームワークを利用します。これらの評価は、脅威・脆弱性管理（TVM）のもとでの厳格な検証ルールに重点を置いています。

企業の調達チームが、自社の内部アプリケーションコードや機密性の高い脆弱性の再現手順を確認することはほとんどありません。生の概念実証（PoC）エクスプロイトを共有すると、知的財産上のリスクや運用上の危険が生じます。そのため購入側は、秘密保持契約のもとで次の2つの外部検証文書を評価します。

独立した証明書（LoA）：テスト提供者のレターヘッドに記載された署名入りの宣誓書で、アセスメントの日付、定義されたテストスコープ、標準化された手法、全体的なリスク態勢を確認するもの。
エグゼクティブサマリーレポート：生のエクスプロイトペイロードを公開することなく、テストのカバレッジ、重大度別の脆弱性の分布、修復状況をまとめた、機密情報を除去した経営層向けの概要。

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           ENTERPRISE TPRM EVALUATION WORKFLOW                           │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   Enterprise Prospect                                     Startup / Vendor              │
│  ┌────────────────────┐   Sends Questionnaire (SIG / CAIQ) ┌─────────────────────────┐  │
│  │ Procurement & TPRM │ ─────────────────────────────────► │ Sales & Security Team   │  │
│  └─────────┬──────────┘                                    └────────────┬────────────┘  │
│            │                                                            │               │
│            ▼ Verifies Attached Evidence                                 ▼ Evidence      │
│  ┌───────────────────────────────────────────────────────────────────────────────────┐  │
│  │ 1. Independent Third-Party Letter of Attestation (LoA) (Signed, < 12 months)      │  │
│  │ 2. Scoping Document (Production Web, APIs, Mobile Apps, Cloud Boundaries)          │  │
│  │ 3. Remediation Verification (Zero unresolved Critical / High findings)             │  │
│  │ 4. Recognized Methodology (OWASP Top 10, OWASP WSTG, NIST SP 800-115, PTES)        │  │
│  └───────────────────────────────────────────────────────────────────────────────────┘  │
│            │                                                                            │
│            ├─► Raw Scanner Export (Nessus/ZAP) ──────────► REJECTED (Deal Blocked)      │
│            │                                                                            │
│            └─► AI Pentest Attestation + PoC Traces ──────► APPROVED (Deal Unblocked)    │
└─────────────────────────────────────────────────────────────────────────────────────────┘

企業の調達審査を通過するには、ペネトレーションテストのパッケージが次の4つの譲れない基準を満たす必要があります。

第三者としての構造的な独立性：自己評価、社内のエンジニアリングレビュー、自社の開発者が実行したツールの生の出力は、即座に審査で不合格となります。購入側は、外部による客観的な評価を求めています。
包括的なスコープの整合：テストスコープは、顧客データを保存する本番環境の境界を反映していなければなりません。アーキテクチャにWebダッシュボード、バックエンドのRESTまたはGraphQLマイクロサービス、モバイルアプリケーション（iOS/Android）が含まれている場合、Webのマーケティング用ドメインだけをテストすると監査上の例外事項となります。
標準化されたテスト手法：アセスメントでは、NIST SP 800-115、OWASP Web Security Testing Guide（WSTG）、OWASP API Security Top 10、OWASP Mobile Application Security Verification Standard（MASVS）など、認知された業界フレームワークを引用する必要があります。
修復と再テストによる検証の文書化：企業の購入側は、重大度がクリティカルまたは高の未解決の脆弱性を抱えるベンダーを失格とします。初回のテストで欠陥が見つかった場合、パッケージには修正完了を示す検証済みの再テスト文書を含める必要があります。

SOC 2監査人が自動脆弱性スキャンを却下する理由

SOC 2監査人が自動脆弱性スキャンをペネトレーションテストの代わりとして認めないのは、AICPAのトラストサービス規準（Trust Services Criteria）が、脆弱性の検出（CC7.1）と運用上の統制の評価（CC4.1）を分けているためです。自動スキャンは既知の脆弱性を特定するという要件（CC7.1）を満たしますが、監査人と企業のセキュリティチームは、内部統制が攻撃者からの圧力のもとで機能するかどうかを能動的に検証する独立した評価（CC4.1）を求めます。これは、単独のスキャナーによるチェックでは満たせない基準です。

創業者からは、Nessus、Qualys、OWASP ZAPといった自動脆弱性スキャナーを実行すれば、SOC 2コンプライアンスのペネトレーションテスト要件を満たせるのかという質問がよく寄せられます。実際には、SOC 2監査人は自動脆弱性スキャンとペネトレーションテストを区別しています。スキャンは既知のシグネチャに基づいて潜在的な欠陥を特定するものであるのに対し、ペネトレーションテストでは、制御を回避できるかどうかを能動的に検証し、エクスプロイトが成立することを実証する必要があります。

その理由は、米国公認会計士協会（AICPA）のトラストサービス規準（TSP Section 100）の文言そのものにあります。

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                       AICPA TRUST SERVICES CRITERIA & AUDIT MAPPING                     │
├──────────────────────────────────────────┬──────────────────────────────────────────────┤
│ CC7.1: Vulnerability Identification      │ CC4.1: Monitoring & Separate Evaluations     │
├──────────────────────────────────────────┼──────────────────────────────────────────────┤
│ • Goal: Detect vulnerabilities & patches │ • Goal: Evaluate if controls actually WORK   │
│ • Tooling: Vulnerability Scanners        │ • Tooling: Penetration Testing               │
│   (Nessus, Qualys, Trivy, Dependabot)    │   (Autonomous Agents + Human Validation)     │
│ • Mechanism: Version checks & signatures │ • Mechanism: Active Adversary Simulation     │
│ • Artifact: Scan summaries, patch logs   │ • Artifact: Proof of Concept (PoC), LoA      │
│ • Audit Role: Core Evidence for CC7.1    │ • Audit Role: Industry Benchmark for CC4.1   │
└──────────────────────────────────────────┴──────────────────────────────────────────────┘

CC7.1とCC4.1の違い

トラストサービス規準は、脆弱性管理と運用上の統制のテストを分けています。

CC7.1（システム運用：脆弱性管理）：構成の変更やシステムの脆弱性を特定するための検出手順を実装することを事業体に求めます。自動脆弱性スキャン、依存関係のチェック、コンテナイメージのスキャンは、チームが既知のソフトウェアの欠陥をスキャンしていることを示すことでCC7.1を満たします。
CC4.1（COSO原則16：日常的評価および独立的評価）：内部統制の構成要素が存在し、能動的な圧力のもとで機能しているかを確かめるための独立した評価を求めます。セキュリティポリシーを確認すれば、ルールが書面上存在することは確認できます。稼働中のアプリケーションを攻撃すれば、その制御が不正アクセスに実際に耐えられることを確認できます。AICPAの規準はペネトレーションテストを名指しで義務付けてはいませんが、監査人と企業のTPRMチームは、独立したペネトレーションテストをCC4.1の評価を裏付ける標準的な統制活動として扱っています。

生の脆弱性スキャンが抱える4つの構造的欠陥

生の脆弱性スキャンがCC4.1の基準を満たせない理由は、次の4つです。

悪用の実証がまったくない：スキャナーはソフトウェアのバナーや正規表現パターンを照合し、推測に基づく仮説（「Apacheの欠陥の可能性」など）を出力します。エンドポイントが到達可能か、実行可能か、上流のファイアウォールで保護されているかを確かめるために攻撃を実行することはありません。
ビジネスロジックの欠陥をテストできない：スキャナーは個々のHTTPリクエストを単独で送信します。オブジェクトレベルの認可の不備（BOLA/IDOR）、マルチテナント環境でのデータ漏えい、認証済みロール間の権限昇格といった、複数ステップにわたる認可ワークフローを評価することはできません。
誤検知率が高い：自動スキャナーは日常的に20%から50%の誤検知（フォールスポジティブ）によるノイズを生み出します。CPA監査人は検証されていないアラートのトリアージを拒否するため、ベンダー側が手作業で妥当性を証明しなければなりません。
攻撃者の視点が欠けている：監査人は、攻撃者が複数の低重大度の問題を連鎖させて、重大なデータ持ち出しの経路を作れないことを示すエビデンスを求めます。スキャナーはパラメーターを個別に評価するため、攻撃ステップを連鎖させることができません。

監査で受け入れられるための記名による説明責任の役割

監査人は、実行時にAIツールが使われたかどうかでアセスメントを判断するわけではありません。評価するのは、エビデンスの信頼性、手法の透明性、そして記名された人間による説明責任です。人間の監督なしに、検証されていない自動スクリプトだけで生成されたレポートは、検証されていない自己評価として受け止められます。

監査基準を満たすには、アセスメントのパッケージに次のものが必要です。 * 実際の影響を示す、検証可能なリクエストとレスポンスによる実証。 * 確立された基準に対応付けられた、文書化され検査可能な手法。 * 検出結果の正確性を検証し、証明書に署名する、記名された有資格者によるレビュー。 * SOC 2のシステム記述書に直接対応付けられた、明確なスコープの境界。

選択肢の評価：従来のコンサルティング会社、スキャナー、Ostorlab AIペンテストの比較

ペネトレーションテストの選択肢を検討するスタートアップには、3つの異なる提供モデルがあります。それぞれの構造的な違いを理解することで、営業のスピードとコンプライアンスの厳密さに合ったアプローチを選べます。

評価軸	従来のブティック型コンサルティング会社	生の自動脆弱性スキャナー	Ostorlab AIペンテスト（Agentic Deep Scan）
所要期間	3～5週間（日程調整とレポート作成）	1～4時間	見積もり5～7日（Core）、より大きなスコープでは10～20日
一般的な費用	アセスメント1回あたり15,000ドル～40,000ドル以上	年間ライセンス2,000ドル～8,000ドル	499ドルから（Coreパッケージ、アセットのスコープに応じて変動）
監査人による受け入れ	受け入れられる（従来の標準）	却下される（CC4.1の基準を満たさない）	主要な監査人が受け入れ（PoCによる実証と検証済みのLoA）
エクスプロイトの検証	手作業のメモとスクリーンショット	なし（仮説的なパターン一致）	決定論的なエクスプロイトの実証
誤検知率	低（手作業で除外）	高（20%～50%以上）	低（エクスプロイトの実証により検証）
スコープのカバレッジ	Webまたは単一のAPIに限定されることが多い	表層的なパラメーターのファジング	統合マルチアセット：Web、API、モバイル、クラウド
修復後の再テスト	1～3週間の遅れ（追加料金）	速いが検証されない	ワンクリックで即時に実行できるRisk Reruns
人間による検証	含まれる（手動テスト）	なし（ソフトウェアの出力のみ）	AIエージェントによるエクスプロイト検証。人間による検証のオプションはプランを参照
SOC 2 Type 2への適合性	ある一時点の静的なスナップショット	頻繁なスキャンだが深さは浅い	リリースサイクルをまたいだ継続的なテスト

Ostorlabがコンサルティングの待ち時間なしに監査レベルの厳密さを実現する方法

Ostorlabは、自律型のAgentic Deep Scan技術とエクスプロイト検証を組み合わせています。仮説的なアラートを生成するのではなく、自律エージェントがアプリケーションの状態を探索し、文脈に即した攻撃仮説を立て、検証済みのエクスプロイトを実行します。確定した検出結果にはそれぞれ、実際に動作するエクスプロイトが添えられます。

エグゼクティブ向けのリスク評価、対象アーキテクチャのスコープ、スキャン所要時間、分類された検出結果を示すOstorlab Agentic Deep Scanのアセスメントレポート概要 — Ostorlab Agentic Deep Scanのアセスメントレポート概要

図1：Ostorlab Agentic Deep Scanのアセスメントレポート概要。ダッシュボードには、全体的なリスク評価、対象アーキテクチャのスコープ、スキャン所要時間、そして監査人による確認にそのまま使える分類済みの脆弱性の内訳が表示されます。

1. 決定論的な悪用可能性の実証（PoC）

監査人と企業のレビュー担当者は、検証可能なエビデンスを求めます。Ostorlabの検出結果は、主観的な信頼度スコアに頼りません。報告されるすべての検出結果には、対象アセットに合わせた決定論的な実証が、正確な根本原因分析とあわせて提供されます。WebとAPIについてはcurlコマンド付きの完全なHTTPリクエストとレスポンスのペア、モバイルアプリケーションについてはIPCトリガーと実行時ログ、コードレベルの問題については検証済みの実行パスです。

重大度、根本原因の説明、脆弱なコードのトレース、トリアージのワークフローを示す、機密情報を除去したAgentic Deep Scanの検出結果の詳細 — 機密情報を除去したAgentic Deep Scanの検出結果の詳細

図2：Ostorlabプラットフォーム内の検出結果の詳細ビュー。レポートでは重大度、根本原因の確認、影響を受けるコードパス、明確な再現手順が示されるため、開発者は曖昧さなく根本的な欠陥を修正できます。

認証済みAPIのアセスメント中に発見された、機密情報を除去したオブジェクトレベルの認可の不備（BOLA）の検出結果を見てみましょう。

POST /api/v2/workspaces/ws_89234/billing/invoices HTTP/1.1
Host: target-api.internal-saas.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "target_tenant_id": "tenant_enterprise_7710",
  "request_export": true
}

サーバーのレスポンスから、組織の境界を越えてテナントのデータが持ち出されたことが確認できます。

HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 11 Sep 2026 14:22:04 GMT

{
  "status": "success",
  "tenant_id": "tenant_enterprise_7710",
  "invoices": [
    {
      "invoice_id": "inv_99812",
      "amount_usd": 124500.00,
      "billing_contact": "finance@fortune500-client.com",
      "payment_method": "ACH_****8812"
    }
  ]
}

ユーザー固有の認可なしにデータが持ち出されることを再現可能な形で実証する、機密情報を除去した復号済みレスポンスペイロード — 決定論的な実行時の悪用エビデンス

図3：エージェントが生成した実行時の悪用の実証。復号されたレスポンスは実際のデータ露出を示しており、理論上のヒューリスティックではなく、侵害の明白な証明を監査人に提供します。

この検出結果には、脆弱でないエンドポイントでは厳格なテナント分離のチェックが適用されていることを示す差分ベースラインチェックが添えられています。開発者は実行可能な再現コマンドを受け取り、監査人は悪用の明白な実証を受け取ります。

2. 統合マルチアセットスタック：Web、API、モバイル

現代のSaaSアーキテクチャは、従来のWebアプリケーションにとどまりません。バックエンドのマイクロサービス、GraphQLゲートウェイ、ネイティブのモバイルクライアント（iOSとAndroid）が、企業顧客のデータを直接扱います。

計画エージェントの目標、アタックサーフェスのマッピング、段階的な実行タスクを示す、文書化され検査可能なテスト手法 — 検査可能なテスト手法

図4：Ostorlab Agentic Deep Scanの検査可能なテスト手法。監査人は、名前の付いた計画エージェント、明示された目標、段階的な実行タスクを確認でき、正式なペネトレーションテスト基準への準拠を実証できます。

単一用途のWebスキャナーでは、モバイルバイナリを逆コンパイルしたり、証明書ピンニングを回避したりすることはできません。Ostorlabは統合されたマルチアセットテストを提供します。 * WebとAPIのディープスキャン：自律的な状態探索、OpenAPIおよびPostmanコレクションの取り込み、認可制御の動的テスト。 * モバイルの動的計装：Monkey動的テストフレームワーク、実行時の計装、ローカルストレージのリスク検出を用いた、Android（APK）およびiOS（IPA）アプリケーションの自動テスト。 * アセット横断のピボット分析：モバイルアプリにハードコードされたシークレットを発見し、それを連鎖させてバックエンドAPIのリソースを不正に取得すること。

3. Risk Rerunsによるワンクリックの修復後再テスト

従来のペネトレーションテストでは、脆弱性を修正しても作業はまだ半分しか終わっていません。修正を確認するには、コンサルティング会社に連絡し、対応可能なテスターを待ち、多くの場合は再テストの追加料金を支払う必要があります。

Ostorlabは、Risk RerunsとSingle Vulnerability Assessment（SVA）によって、こうした運用上の摩擦をなくします。 1. 開発者が正確な再現ペイロードを確認し、コードの修正をステージング環境または本番環境に反映します。 2. エンジニアリングチームがワンクリックで、影響を受けるエンドポイントに対して対象を絞ったRisk Rerunを直接実行します。 3. 自律エージェントが、新しいセッションの認証情報を使って、まったく同じエクスプロイトチェーンを再実行します。 4. 攻撃がブロックされた場合、プラットフォームは検出結果のステータスを「Remediated」に更新し、タイムスタンプ付きの検証エントリを監査ログに記録します。

修復済みの検出結果を対象に絞って再テストするためのOstorlab Risk Rerunsインターフェース — Ostorlab Risk Rerunsの再テストインターフェース

図5：ワンクリックのRisk Rerunsインターフェース。開発者はパッチを適用した攻撃ベクトルを即座に再テストでき、監査人が修復完了の承認に用いる、暗号学的にタイムスタンプが付与された検証記録が作成されます。

4. 検証と説明責任を伴う証明

各AI Pentestパッケージには、エージェントが確定したすべての検出結果に対する実際に動作するエクスプロイトと、再テスト期間が含まれます。人間による検証はすべてのパッケージに含まれるわけではありません。どのプランに含まれるか、またはアドオンとして利用できるかは、プランの比較をご覧ください。最終的なレポートパッケージには次のものが含まれます。 * 秘密保持契約のもとで経営層と企業の購入側に提供する、概要レベルのリスク指標を含むエグゼクティブサマリー。 * 包括的な技術スコープと手法の対応付け（NIST SP 800-115、OWASP WSTG）。 * 未解決のクリティカルまたは高の脆弱性がゼロであることを示す、検証済みの修復ログ。 * 主要なコンプライアンスプラットフォーム（Vanta、Drata、Secureframe）で受け入れられる、署名入りの正式な証明書（Letter of Attestation）。

スタートアップが約1週間で監査対応のペンテストレポートを入手する方法

スタートアップは、4つのフェーズからなるペンテストワークフローに従うことで、Coreアセスメントであれば最初のスコープ定義から署名入りの監査対応の証明書（Letter of Attestation）まで、推定5～7日で進めることができます（Advancedは10～14日、Eliteは15～20日）。以下のフェーズは作業の順序を示したもので、所要期間を保証するものではありません。

2026年10月1日更新：本記事の所要期間と人間による検証に関する記述を、現在のプランページに合わせて修正しました。2026年10月5日更新：提供していないセキュリティバッジに関する記述を削除しました。

フェーズ1：スコープの受け付けとシード認証情報：SOC 2のシステム記述書に記載された顧客データの境界を定義します。WebのURL、APIスキーマ、モバイルバイナリを取り込み、マルチテナントの認可制御をテストするために、異なる2つのユーザー認証情報を提供します。
フェーズ2：自律型のAgentic Deep Scan：自律エージェントがアプリケーションの状態をマッピングし、インデックスされていないエンドポイントを発見し、認証、認可、ロジックのワークフロー全体でエクスプロイトチェーンを実行します。
フェーズ3：開発者による対象を絞った修復：開発者は、優先順位付けされたクリティカルおよび高の検出結果をレビューします。各検出結果には、アセットに応じた再現エビデンス（Web/APIについてはHTTPトレースとcurlコマンド、モバイルアプリケーションについてはIPCトリガーと実行時ログ、コードレベルの検出結果については検証済みの実行パス）が添えられているため、エンジニアはトリアージで迷うことなく根本原因を修正できます。
フェーズ4：ワンクリックの再テストとLoAのエクスポート：エンジニアリングチームは、含まれている再テスト期間内に、パッチを適用した攻撃ベクトルに対してRisk Rerunsを実行します。検証済みの修正完了が記録され、証明書（Letter of Attestation）と監査パッケージが提供されて、調達プロセスの停滞が解消されます。

SOC 2のペンテストに関するよくある質問

SOC 2監査人はAI主導のペネトレーションテストレポートを受け入れるか

はい。AICPAのトラストサービス規準（TSP Section 100）が定めているのはテストの厳密さとエビデンスの基準であり、テスターが生身の人間であるかどうかではありません。主要なCPA監査法人は、アセスメントが確立された手法（NIST SP 800-115やOWASP WSTGなど）に従い、決定論的な悪用の実証を含み、定義されたテストスコープを提示し、修復を確認する、人間がレビューした独立した証明書（Letter of Attestation）を含んでいれば、エージェント型のペネトレーションテストを受け入れます。

オンデマンドのエージェント型ペンテストは自動脆弱性スキャンとどう違うのか

自動脆弱性スキャナーは、静的なパターンマッチング、個別のペイロードチェック、バージョンバナーの検査に依存しており、悪用可能性を確認することなく高い誤検知率を生み出します。エージェント型のペネトレーションテストは、アプリケーションのワークフローと能動的にやり取りし、動的にエクスプロイトを生成し、複数の弱点を連鎖させ、異なるアカウント間で認可の境界を検証し、検証済みの概念実証（PoC）エビデンスを提供します。

企業の調達部門が求めるのは完全な技術レポートか、それとも証明書だけか

企業の購入側は通常、秘密保持契約のもとで、署名入りの証明書（LoA）と機密情報を除去したエグゼクティブサマリーを求めます。生の技術的な脆弱性レポートを共有すると、機密性の高いアプリケーションのエンドポイントや悪用手順が露出しますが、企業のリスクチームはそれらを必要としていません。証明書（Letter of Attestation）は、第三者としての独立性、スコープの網羅性、そして緩和されていない高またはクリティカルの脆弱性が存在しないことを確認するものです。

Ostorlabの料金は従来のペネトレーションテストと比べてどうか

従来のペネトレーションテストのコンサルティング会社は、ある時点のアセスメントに対して15,000ドルから40,000ドルの見積もりを提示し、数週間の待ち時間が発生します。Ostorlabは透明性のある段階的な料金体系を提供しており、スコープを定めたCore AI Pentestパッケージはオンデマンドで499ドルから利用でき（アプリケーションのスコープと複雑さに応じて透明性をもって変動）、マルチアセット対応と再テスト期間が含まれます。人間による検証の有無はプランによって異なります。プランの比較をご覧ください。

エージェント型のペネトレーションテストはSOC 2 Type 2の観察期間に対応できるか

はい。SOC 2 Type 2監査では、3～12か月の期間にわたって統制が継続的に有効であることの実証が求められます。従来の年1回のペンテストでは、何か月分ものコード変更がエビデンスのないまま残ります。オンデマンドのエージェント型テストであれば、セキュリティチームは主要なリリースのたびに定期的なアセスメントを実行でき、監査期間全体を通じて途切れのないエビデンスの記録を確立できます。

基準と一次参考文献

American Institute of Certified Public Accountants (AICPA). Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (TSP Section 100).
National Institute of Standards and Technology (NIST). Technical Guide to Information Security Testing and Assessment (NIST SP 800-115).
Open Web Application Security Project (OWASP). Web Security Testing Guide (WSTG v4.2).
Open Web Application Security Project (OWASP). API Security Top 10.
Shared Assessments. Standardized Information Gathering (SIG Lite) Questionnaire.
Cloud Security Alliance (CSA). Consensus Assessments Initiative Questionnaire (CAIQ v4).

タグ：

SOC 2, Penetration Testing, Compliance, AI Pentest, Agentic Deep Scan, Vendor Risk Assessment