リリース前のSaaSセキュリティチェックリスト：最初に実行する40の項目（2026年版）
リリース前のSaaSセキュリティチェックリストは、まだ取得していないコンプライアンスバッジの山よりも価値があります。ここで不都合な真実を述べます。ほとんどのリリースチェックリストは「何を保護すべきか」は教えてくれますが、「どのように行うか」は決して示しません。このリストはコードを提供します。私たちは Next.js と Supabase を使って構築しており、単一の tenant_id フィルターの欠落がテストアカウントに他の顧客のデータを読み取らせてしまう事例を目の当たりにしてきました。IBMの2024年データ侵害コスト報告書によると、世界の平均コストは488万ドルです。本番公開するためにSOC 2は必要ありません。必要なのは、以下に示すアプリレイヤーのベースラインであり、これはグループ化され、実行可能で、OWASP および NIST にマッピングされています。
主なポイント
- SOC 2やペネトレーションテストなしでもリリースできます。必要なのは以下のアプリレイヤーのベースラインです。
- 最も危険なリリースバグは、
tenant_idチェックの欠落によるクロステナントデータの漏洩です。 - 独自に認証を実装しないでください。Auth.js、Clerk、または Supabase Auth を使用してください。
- デプロイ前に
NEXT_PUBLIC_プレフィックスを監査してください。それがシークレットを漏洩させる最速の方法です。
このベースラインは OWASP ASVS 5.0 および NIST Secure Software Development Framework (SSDF) にマッピングされています。これらはGoogleがこのトピックで最も信頼している2つの参照資料であり、特筆すべきこととして、上位ランクのガイドのいずれも引用を怠っている2つでもあります。
リリース前セキュリティチェックリスト（簡易版）
これらは出荷前の最小限のセキュリティ要件であり、6つのカテゴリに分類されています。全40項目です。上から下へ実行し、コードセクションを開発者に渡し、以下の優先度テーブルでP0とマークされた項目をリリースブロッカーとして扱ってください。
シークレットと設定
.envは最初のコミットから.gitignoreに含まれており、決してコミットされていません。- すべての
NEXT_PUBLIC_およびVITE_プレフィックスが監査されており、機密情報はブラウザに出荷されません。 - サーバーシークレットはリポジトリではなく、マネージャー（プラットフォーム環境変数、AWS Secrets Manager、Vault）に保存されます。
- git履歴に触れたことのあるキーは、リリース前にすべてローテーションされます。
- ログ、エラーペイロード、またはクライアントバンドルにシークレットが表示されません。
- ビルド済みバンドルに対してライブキーをgrepしました（
grep -r "sk_live" .next/）。
認証とアクセス
- 認証は手書きではなく、ライブラリ（Auth.js、Clerk、または Supabase Auth）に基づいて構築されています。
- アカウントでMFA（多要素認証）が利用可能です。
- セッションクッキーには
Secure、HttpOnly、およびSameSiteが設定されています。 - JWTやセッショントークンは
localStorageに保存されません。 - RBAC（ロールベースのアクセス制御）と最小権限のロールは、UIで隠すだけでなく、サーバーサイドで強制されます。
- パスワードは Argon2 または bcrypt でハッシュ化されます（認証を自己管理する場合のみ）。
- パスワードリセットおよびメール確認フローは、悪用に対してテストされています。
データとテナンシー
- すべてのクエリに
tenant_idフィルターが含まれています。 - テナントのスコープ指定は、クエリごとに覚えるのではなく、ORMまたはリポジトリ層で強制されます。
- 行レベルセキュリティ（RLS）が有効になっており、その失敗モードが理解されています。
- すべてのオブジェクトIDエンドポイントは所有権チェックを実行します（これによりIDORを防ぎます）。
tenant_idはキャッシュキーとオブジェクトストレージパスに含まれています。- データは保存時および転送時に暗号化されています。
- 支払いおよびWebhook署名（Stripeなど）はサーバーサイドで検証されます。
依存関係とサプライチェーン
npm auditまたはpnpm auditは高および重大な問題がなくクリーンです（または明示的にトリアージ済みです）。- Dependabot または Renovate が有効になっています。
- Snyk または Socket がより深いSCA（ソフトウェア構成分析）、マルウェア、ライセンスチェックを実行しています。
- ロックファイルがコミットされています。
- クリティカルパスに放棄された、またはメンテナンスされていないパッケージが存在しません。
- Dockerを出荷する場合、コンテナイメージがスキャンされています。
ネットワークとトランスポート
- HTTPSはHSTSプリロードとともにあらゆる場所で強制されます。
- Content-Security-Policy（CSP）が設定されています（最初はreport-only、その後enforce）。
X-Content-Type-Options: nosniffおよびX-Frame-Options/frame-ancestorsが設定されています。Referrer-PolicyおよびPermissions-Policyが設定されています。- CORSは許可リストを使用し、資格情報付きで
*を使用することはありません。 - レート制限が認証および高コストのエンドポイントを保護しています。
- すべてのエンドポイントはスキーマ（Zodなど）を使用して入力を検証します。
モニタリングと対応
- 集中型監査ログが、誰が何にいつアクセスしたかを記録しています。
- エラー処理はスタックトレースをユーザーに漏らしません。
- 認証の異常（ログイン失敗の急増、不可能な移動）に対してアラートが発火します。
- 自動バックアップが実行され、復元テストが行われています。
- インシデント対応の連絡先と1ページのランブックが存在します。
- 稼働時間およびエラーモニタリング（Sentryまたは同等品）が稼働中です。
- ペネトレーションテストを導入するトリガーを知っています。
修正優先順位
すべての項目がリリースをブロックするわけではありません。このトリアージテーブルは、スキップした場合の損害に基づいてベースラインを並べ替えているため、創業者は交渉不可の事項を知ることができます。P0 = リリース前に修正、P1 = 第1週に修正、P2 = 四半期内に修正。
| チェック | カテゴリ | スキップした場合の影響 | 修正の手間 | リリースブロッカー? |
|---|---|---|---|---|
| すべてのクエリでのクロステナント分離 | データとテナンシー | ある顧客が別の顧客のデータを読み取る | 中 | P0: リリースをブロック |
| クライアントバンドルからのシークレット排除 | シークレットと設定 | 公開APIキー、アカウント乗っ取り | 低 | P0: リリースをブロック |
| オブジェクトIDエンドポイントでの所有権チェック | データとテナンシー | IDOR: IDを増分するとレコードが漏洩 | 低 | P0: リリースをブロック |
| 手書きではなくライブラリによる認証 | 認証とアクセス | 出荷された認証バグ、壊れたセッション | 中 | P0: リリースをブロック |
| あらゆる場所でのHTTPSとHSTS | ネットワークとトランスポート | 通信経路上でのトークン盗難 | 低 | P0: リリースをブロック |
| npm auditが高/重大でクリーン | 依存関係 | 推移的な依存関係における既知のCVE | 低 | P1: 第1週 |
| 認証エンドポイントでのレート制限 | ネットワークとトランスポート | 資格情報の詰め込み、ブルートフォース | 低 | P1: 第1週 |
| セキュリティヘッダー（CSP, HSTS, nosniff） | ネットワークとトランスポート | XSS、クリックジャッキング、MIME攻撃 | 低 | P1: 第1週 |
| 集中型監査ログ | モニタリング | 侵害を確認または証明できない | 中 | P1: 第1週 |
| テスト済みのバックアップ復元 | モニタリング | 復元できないバックアップは無意味 | 中 | P1: 第1週 |
| アカウントで利用可能なMFA | 認証とアクセス | アカウント乗っ取りが容易になる | 低 | P2: 今四半期 |
| report-onlyを超えた完全なCSPの適用 | ネットワークとトランスポート | 残存するXSSの表面積 | 中 | P2: 今四半期 |
シークレットと設定：キーはクライアントバンドルに漏洩していませんか？
リリース時のシークレット衛生管理とは、資格情報がブラウザに到達しないことを意味します。Next.js の NEXT_PUBLIC_ プレフィックス（および Vite の VITE_）は値をすべての訪問者に出荷するため、間違ったプレフィックスが1つあるだけでキーが漏洩します。.env をgitから除外し、サーバーシークレットをマネージャーに配置し、デプロイ前にビルド出力をgrepしてください。
ここで私たちが最もよく目にする落とし穴は、NEXT_PUBLIC_ が「公開情報」を意味するわけではないということです。これは「私は文字通りこれをすべての訪問者のブラウザに出荷しています」を意味します。Stripeのシークレットやサービスロールキーにそのようなプレフィックスを付けると、DevToolsを開いた任何人にとってバンドル内でライブ状態になります。
# .env.local (the mistake)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H... # BAD: ships to every browser
STRIPE_SECRET_KEY=sk_live_51H... # OK: server-only
# Public (safe to expose) vs server-only
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ... # anon key is meant to be public
SUPABASE_SERVICE_ROLE_KEY=eyJ... # never NEXT_PUBLIC_ this
# Catch a leaked key before you deploy
grep -r "sk_live" .next/ # any hit means a secret is in your client bundleシークレットベースラインの残りは退屈ですが交渉不可です。最初のコミットから .gitignore に .env を含め、サーバーシークレットをリポジトリではなくマネージャーに配置し、git履歴に触れたことのあるキーをすべてローテーションします（コミットを削除しても漏洩は解消されません）。漏洩したデプロイトークンは、Vercelのインシデントのような侵害が始まるまさにその方法なので、すべてのトークンをすでに誰かの監視リストにあるものとして扱ってください。
認証とアクセス：認証を構築すべきか、ライブラリを使用すべきか？
認証を構築すべきか、ライブラリを使用すべきか？ほとんど常にライブラリを使用してください。Auth.js、Clerk、Supabase Auth は、本番環境で再発見することになるであろう数年分のエッジケース（セッション固定、トークン失効、リセットフローの悪用）を吸収しています。独自に実装することは、セキュリティエンジニアがおり、どのプロバイダーも適合しない理由がある場合のみ正当化されますが、それは稀です。
独自に認証を実装することは、月額25ドルを節約するための最も高価な方法です。正直な選択肢の比較は以下の通りです。
| オプション | ベストな状況 | MFA組み込み | デフォルトセッション | 落とし穴 |
|---|---|---|---|---|
| Auth.js (NextAuth) | 無料、セルフホスト、完全な制御を希望する場合 | プロバイダー/アドオン経由 | JWTまたはデータベース | すべてのセキュリティエッジケースを自分で責任を持つ |
| Clerk | MFA、UI、組織機能を箱から出してすぐに使用したい場合 | はい | 管理済み | 有料ティアはアクティブユーザー数に応じてスケール |
| Supabase Auth | すでにSupabaseとPostgres RLSを実行している場合 | はい | JWT | RLSポリシーの品質はあなた次第 |
| 独自実装 | セキュリティエンジニアがおり、適合するプロバイダーがない場合 | 自分で構築 | 自分で構築 | ほとんどの認証バグはここから始まる |
ライブラリを選択したが設定を省略したチームを沈める2つの落とし穴があります。第一に、JWTの失効は本当に難しいため、盗まれたトークンは期限切れまで有効のままです。トークンの寿命を短く保ち、機密性の高いものにはサーバーサイドのセッションを優先してください。第二に、localStorage 内のトークンは任意のXSSペイロードによって盗まれる可能性があるため、セッションは Secure および SameSite を備えた httpOnly クッキーに保存してください。UIでボタンを隠すのではなく、サーバーでRBACを強制してください。
SaaSがAIまたはLLM機能を出荷する場合、モデル入力も信頼できない認証境界として扱ってください。ツールアクセス権を持つジャイルブレイクされたアシスタントは、チャットウィンドウを着たアクセス制御の問題であるため、プロンプトインジェクションの防止に関するガイドをご覧ください。
データとテナンシー：あるテナントが別のテナントのデータを読み取るのをどう防ぐか？
テナント分離とは、すべてのクエリ、キャッシュキー、ストレージパスが現在のテナントにスコープ指定されていることを意味します。tenant_id フィルターの欠落は、ある顧客が別の顧客のデータを読み取れるようにします。これは存在する中で最も危険なリリースバグです。行レベルセキュリティ（RLS）は役立ちますが、それはシートベルトであり力場ではないため、すべてのオブジェクトIDエンドポイントにも所有権チェックを追加してください。
これは競合他社がコードとしてカバーしていないセクションであり、クロステナント漏洩が生産環境に入り込む理由です。修正は、ID単独を決して信頼しないことから始まります。すべての読み取りを呼び出し元のテナントにスコープ指定し、クエリごとに誰も覚えておく必要がないようにデータ層でそれを強制してください。
// BAD: no tenant scope. Any valid id returns any tenant's row.
const order = await db.order.findFirst({ where: { id } });
// GOOD: scoped to the caller's tenant on every read.
const order = await db.order.findFirst({
where: { id, tenantId: session.tenantId },
});関連する失敗は IDOR（不安全な直接オブジェクト参照）であり、OWASP API Security Top 10 では API1: Broken Object Level Authorization に分類されています。テストアカウントがURL内のIDを増分させ、決して見るべきではないレコードを読み取ります。PortSwiggerの Web Security Academy には、攻撃者がこれらを発見する方法の完全なウォークスルーがあります。修正は1つの所有権チェックです。
// GET /api/invoices/1234, a test account increments the id
// and reads another tenant's invoice. Classic BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });
// Fix: verify ownership before you return anything.
if (invoice.tenantId !== session.tenantId) {
return res.status(403).json({ error: "Forbidden" });
}ここでは正直さを保つフレームワークがあります。すべてのIDORはテナント分離の失敗ですが、すべてのテナント分離の失敗がIDORであるわけではありません。Postgresの行レベルセキュリティはデータベースでそれらの多くを検出しますが、それに依存する前に知っておくべきサイレント失敗モードがあります。
-- Postgres RLS: a seatbelt, not a force field.
alter table orders enable row level security;
create policy tenant_isolation on orders
using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Silent-failure trap: forget to SET app.tenant_id on a pooled
-- connection and the policy reads the PREVIOUS request's tenant.接続プールの汚染、非同期コンテキストの漏洩、共有キャッシュのポイズニングはすべて、RLSを静かに打ち負かします。そのため、OWASP Multi-Tenant Security Cheat Sheet は、キャッシュキーとストレージパスにもテナントをプレフィックスとして付けるよう指示しています。ここで全文を読む価値のある2つの参照資料は、OWASP ASVS 5.0 のアクセス制御章と Supabase RLS ドキュメント です。
依存関係とサプライチェーン：node_modulesに何が潜んでいるか？
あなたのアプリは、最も弱い推移的依存関係と同じくらい安全です。CIで npm audit または pnpm audit を実行し、リリース前に高または重大な所見でビルドを失敗させてください。自動更新のために Dependabot または Renovate を追加し、より深いマルウェアおよびライセンスチェックのために Snyk または Socket を追加してください。
罠は、手動で一度だけ監査を実行し、緑色を見て、二度と実行しないことです。CIに配線し、触れていないパッケージに新しいCVEがあってもマージをブロックするようにしてください。
# .github/workflows/ci.yml: block the merge on high/critical
- name: Audit dependencies
run: npm audit --audit-level=high # non-zero exit fails the jobnpm audit ドキュメント は、深刻度レベルと、開発専用所見を無視したい場合の --production フラグについて説明しています。自動スキャンは当然のことですが、依存関係スキャナーが見逃すコードスメルやインジェクション経路を検出するより深い静的解析については、SonarQubeレビューをご覧ください。ロックファイルをコミットし、数年間リリースを出していないパッケージを削除し、Dockerをデプロイする場合はコンテナイメージをスキャンしてください。
ネットワークとトランスポート：SaaSに実際に必要なセキュリティヘッダーはどれか？
SaaSに必要なセキュリティヘッダーはどれか？ HTTPS に加え、HSTS と短いヘッダーセットが、最も悪用しやすいギャップを閉じます。ワイルドカードの代わりに Content-Security-Policy とCORS許可リスト、認証および高コストのエンドポイントへのレート制限を追加してください。悪いペイロードがロジックに決して到達しないように、Zod のようなスキーマですべての入力を検証してください。
これまでに発明されたすべてのヘッダーが必要なわけではありません。必要なのはこの短いリストであり、MDNセキュリティヘッダーリファレンス がそれぞれを詳細に説明しています。
| ヘッダー | 推奨値 | 阻止するもの |
|---|---|---|
| Strict-Transport-Security | max-age=63072000; includeSubDomains; preload | プロトコルダウングレード、SSLストリップ攻撃 |
| Content-Security-Policy | default-src 'self'; start report-only | XSS、注入されたスクリプト、データ流出 |
| X-Content-Type-Options | nosniff | アップロードをスクリプトに変換するMIMEスニッフィング |
| X-Frame-Options / frame-ancestors | DENY (または frame-ancestors 'none') | 隠しiframeによるクリックジャッキング |
| Referrer-Policy | strict-origin-when-cross-origin | 完全なURL（およびその中のトークン）の漏洩 |
| Permissions-Policy | camera=(), microphone=(), geolocation=() | デバイスAPIに触れる不正スクリプト |
ヘッダーをエッジで一度設定し、スクリプトが一晩中ログインルートをブルートフォースできないようにレートリミッターを追加してください。
// next.config.js: security headers on every response
const securityHeaders = [
{ key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
{ key: "X-Content-Type-Options", value: "nosniff" },
{ key: "X-Frame-Options", value: "DENY" },
{ key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Rate-limit auth routes (Upstash example)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });自分のアプリを壊さないように、CSPをreport-onlyで開始し、数日間違反レポートを監視してから、enforceに切り替えてください。CORSは名前付きの許可リストに限定し、資格情報と * を決して組み合わせないでください。
モニタリングと対応：侵害されたことをどう知るのか？
見えないものに対応することはできません。リリース前に、集中型監査ログ、ログイン失敗の急増などの認証異常に対するアラート、テスト済みの復元を伴う自動バックアップ、および1ページのインシデントランブックを整備してください。テストされていないバックアップは希望であり、バックアップではありません。ランブックを書くのはインシデントの最中ではなく、今です。
IBMのデータによると、侵害を特定し封じ込めるまでの平均時間は258日です。ログが誰が何に触れたかを記録していなければ、その数字を縮小することはできません。それらを集中化し、重要な異常（ログイン失敗の急増、不可能な移動ログイン、突然のエクスポート量）に対してアラートを出し、エラーハンドラーが内部をマップするスタックトレースではなく、クリーンなメッセージを返すようにしてください。
現代の侵害検出は静的ルールではなく異常モニタリングに依存しています。それが実際にどのように機能するかについては、AIがデータ侵害を防ぐ方法に関する記事で詳しく説明しています。フレームワークの裏付けとして、NIST SSDF (SP 800-218) は対応およびモニタリングの実践を平易な言葉で概説しています。データベースが消滅した後ではなく、リリース前に復元をテストしてください。
自社のリリースをレビューするときに見つかるもの
私たちのチームが自社またはクライアントのビルドに対してリリース前のセキュリティパスを実行するとき、他の何よりも2つの見落としが現れます。第一：NEXT_PUBLIC_ プレフィックスでブラウザに乗っていくシークレット。通常、クライアントサイドの呼び出しを機能させるために誰かがプレフィックスを付けたサードパーティAPIキーです。第二：少なくとも1つのエンドポイントで tenant_id スコープまたは所有権チェックが欠落していることです。
テナントスコープの見落としは恐ろしいものです。なぜなら、アプリは正常に見えるからです。すべてのページが読み込まれます。バグは、誰かがURL内のIDを変更したときにのみ現れます。あるレビューでは、GET /api/orders/:id がログインしている任意のユーザーに任意の注文を返していました。テストアカウントは番号を増分させることで、別のテナントの注文を読み取っていました。修正は2行でした。返す前に order.tenantId を session.tenantId と比較するだけです。
ここでは偽の検出率を引用しません。正直で再現可能なのは次のとおりです。NEXT_PUBLIC_ の漏洩と欠落したテナントスコープは、ほぼすべての初回パスレビューで見つける2つの事項であり、探す場所さえ知っていればどちらも修正コストが安価です。这正是为什么清单将它们作为P0前置的原因。
もしリリース日前にチームにこのパスを実行してもらいたいのであれば、それが私たちの仕事です。リリース前セキュリティレビューを受ける →
著者について
Mert Batur Gurbuz は Techsy.io の共同創設者です。同社では、B2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを出荷しています。彼はバーミンガム大学で学んでおり、Techsyチームが生産環境で実際に使用しているLLMツールスタックについて執筆しています。LinkedIn でつながってください。
よくある質問
リリース前のSaaSセキュリティチェックリストには何を含めるべきか？
6つのカテゴリ：シークレットと設定（キーをクライアントバンドルから除外）、認証とアクセス（ライブラリを使用、MFAを追加）、データとテナンシー（tenant_id スコープ指定と所有権チェック）、依存関係（CIでの npm audit）、ネットワークとトランスポート（HTTPS、HSTS、CSP、レート制限）、モニタリングと対応（監査ログ、テスト済みのバックアップ、ランブック）。
私のSaaSはリリースするのに十分に安全か？
P0ベースラインが完了したら準備完了です。クライアントバンドルからのシークレット排除、すべてのクエリでのテナント分離、ライブラリによる認証、セキュリティヘッダー付きのHTTPS、クリーンな依存関係スキャン。完璧さは基準ではありません。ベースラインをカバーした出荷・監視済みのアプリは、決してリリースされない「完璧な」アプリに勝ります。
SaaSをリリースする前にペネトレーションテストが必要か？
法的にリリースするために必須ではありません。支払いや個人情報を扱う場合、エンタープライズ購入者を対象とする場合、または監査人あるいは投資家が要求する場合に優先してください。MVP段階では、まずアプリレイヤーのベースラインとOWASP Top 10にその努力を費やしてください。明白なIDORやヘッダーのギャップがすでに閉じられているとき、ペネトレーションテストはより多くのものを発見します。
SaaSをリリースするためにSOC 2が必要か？
いいえ。先週リリースしたスタートアップにSOC 2を期待する顧客はいません。それはエンタープライズ販売の解除キーであり、リリースゲートではありません。また、数ヶ月かかります。アプリレイヤーのベースラインで出荷し、実際のエンタープライズ案件が必要になったときにSOC 2プロセスを開始してください。その前ではありません。
独自の認証を構築すべきか、Auth.js、Clerk、Supabase Authのようなライブラリを使用すべきか？
ほとんど常にライブラリを使用してください。Auth.js、Clerk、Supabase Auth は、自作の認証バグの大部分を引き起こすセッション、トークン、リセットフローのエッジケースを処理しています。独自に実装することは、セキュリティエンジニアがおり、どのプロバイダーも満たさない硬性の要件がある場合にのみ正当化されますが、それは本当に稀です。
シークレットをクライアントバンドルからどう排除するか？
すべての NEXT_PUBLIC_ および VITE_ プレフィックスを監査してください。そのプレフィックスを持つものはすべてブラウザに出荷されるからです。最初のコミットからgitに .env を含めず、サーバーシークレットをマネージャーに保存し、デプロイ前にビルド済みバンドルをgrep（grep -r "sk_live" .next/）して漏洩したキーを検出してください。
マルチテナントSaaSでテナントデータをどう分離するか？
すべてのクエリに tenant_id フィルターを配置し、自動的になるようにORMまたはリポジトリ層でそれを強制してください。行レベルセキュリティを有効にし、その失敗モード（プール汚染、非同期漏洩）を学習してください。IDORを閉じるためにすべてのオブジェクトIDエンドポイントに所有権チェックを追加し、キャッシュキーとストレージパスをテナントごとにスコープ指定してください。
リリース前にSaaSに必要なセキュリティヘッダーは何か？
最低限：Strict-Transport-Security (HSTS)、Content-Security-Policy、X-Content-Type-Options: nosniff、X-Frame-Options または frame-ancestors、Referrer-Policy、Permissions-Policy。CSPをreport-onlyで開始し、違反をレビューしてから適用してください。MDNのセキュリティヘッダードキュメントにはそれぞれの推奨値が記載されており、上記のヘッダーテーブルはそれぞれが阻止するものを要約しています。
npm auditやSnykのような自動スキャンで十分か？
必要ですが十分ではありません。npm audit、Snyk、Socketなどのツールは既知のCVEや悪意のあるパッケージを検出しますが、IDORや欠落したテナントスコープのようなビジネスロジックおよびアクセス制御の欠陥を見つけることはできません。それらには人間、テストアカウント、明示的な所有権チェックが必要です。スキャナーと手動パスの両方を実行してください。
結論：実際に出荷できるSaaSセキュリティチェックリスト
リリースするために完璧である必要はありません。ベースラインが必要です。まずP0項目を閉じます。バンドルからのシークレット排除、すべてのクエリでのテナント分離、すべてのオブジェクトエンドポイントでの所有権チェック、ライブラリによる認証、ヘッダー付きのHTTPS。金曜日のリリース前に1つだけ修正するなら、テナント分離にしてください。なぜなら、それが警告ゼロで顧客のデータを漏洩させるバグだからです。
ここにあるすべては今日実行可能であり、コンプライアンス予算を必要としません。40のチェック項目をこなし、コードセクションを開発者に渡し、出荷してください。本番公開前に別の目を通したいですか？無料相談を受ける ことで、リストを一緒に確認します。