信頼と手法

攻撃対象領域を任せられる設計

セキュリティツールは自らに高い基準を課すべきです。VICEが公開スキャン、認証済み監査、修正をどう分離するか、そして決してしないことをここに示します。

01Public light scan02DNS verification03Deep audit unlocked

侵入的チェックの前に所有権を

匿名の訪問者は受動的な公開チェックのみ。深い監査はDNS TXTレコードで所有が証明されてから解放されます。

TXT · _vice-verify.acme.devRLSAUTHSTORAGE

証拠は添付されたまま

検出項目は生の証拠を修正コンテキストの隣に保持し、レポートのすべての主張を検証できます。

$ GET acme.dev/.env200 OK# .env · productionDATABASE_URL=••••••••••••STRIPE_SECRET_KEY=sk_live_51H…SUPABASE_SERVICE_ROLE=••••••RESEND_API_KEY=••••••••

設計段階から分離

Webba IDがアイデンティティを管理し、行レベルセキュリティが各ワークスペースを所有者に限定します。RLS監査が私たちの仕事:自分たちのRLSは模範でなければなりません。

acme.devAUDITSFINDINGSMODULESSCHEDULES

明示的な修正フロー

AI修正プロンプト、解決済みステータス、履歴リセットはあなたが起こす意図的なアクションであり、データを静かに変更するものではありません。

-- ai fix · missing-rls-policy
- grant select on public.users to anon;
+ alter table public.users
+ enable row level security;
+ create policy "own rows" on public.users
+ for select using (auth.uid() = id);

フル監査がカバーする範囲

外部からのブラックボックスチェック、リポジトリからのホワイトボックスチェック。両方が1つのスコアに。

セキュリティヘッダーTLSとHSTSCookieフラグCORSポリシーCSP分析露出した.envと設定ファイルJS内の漏洩シークレット開いたディレクトリリスティングrobotsとsecurity.txtSupabase RLSポリシーストレージバケットの露出認証フローの弱点脆弱な依存関係CIワークフローのセキュリティgit履歴の漏洩

リソース