安全システム開発規範 / Secure System Development

実行環境にグローバルアセット禁止令（特定の自社アセットへの攻撃/スキャンを禁止）が存在する場合、グローバル設定が優先され、本スキルはそれを上書きしません。汎用テンプレートが必要な場合は references/internal-policy.example.md を参照してください（公開版には実際の内部アドレスは含まれません）。

使用方法

コードを書く前に「レッドラインリスト」を読み、書き終えたらセルフチェックを行います。設計・レビュー時は「フェーズ1」を読み、特定のモジュールに関わる場合はポインタに従って references/ 下の該当ファイルを開きます。コミット前には「リリース前レビュー」を実行し、リリース後は「実行時と0day」を確認します。

タスクが一部の領域のみに関わる場合（ログインインターフェースのみ、注文テーブルの設計のみなど）、該当する章と対応する reference のみを読み、すべてを暗記する必要はありません。

実行可能セルフチェック（推奨：最初に実行）

python scripts/scan_redlines.py <ターゲットディレクトリ> --format text            # 人が読む用
python scripts/scan_redlines.py <ターゲットディレクトリ> --format sarif --fail-on high   # CI ブロッキング用
python scripts/scan_redlines.py <ターゲットディレクトリ> --code-only              # ドキュメントをスキップし、コードのみスキャン

純粋な Python 標準ライブラリのみで、依存関係のインストールは不要です。SQL インジェクション、innerHTML/eval、CORS ワイルドカードとリフレクション、グローバルなトップページへのフォールバック、ハードコードされたシークレット、MD5 パスワード保存、コマンドインジェクション、証明書検証の無効化、デバッグスイッチ、ログへの機密フィールド出力、未検証のアップロードパスなど、18 カテゴリのルールをカバーします。検出結果は対応する reference を指し示します。

誤検知の処理：該当行の末尾にコメント redline: ignore（行全体を無視）または redline: ignore SQL001（指定ルールのみ無視）を追加します。アラートを消すためにルール全体を無効にしないでください。理由を記録し、レビュー時に説明してください。

2 つのテンプレート：assets/threat-model-template.md（設計時の脅威モデリング用）、assets/review-checklist.md（プロジェクトタイプ別のリリース前チェックリスト用）。

先にプロジェクトタイプを判定する（どのルールを適用するか決定）

シナリオ	典型的な形態	セキュリティルール	完全性要件	収録（SEO）
公開サイト	公式サイト、ランディングページ、ブログ、ドキュメント、EC フロント	フルセット	低（公開コンテンツ）	必須：真の 404、sitemap、canonical、構造化データ
ログイン後プロダクト	SaaS、ツールサイト、コミュニティユーザー向け	フルセット + 完全なアカウント体系	中（機密操作は署名）	公開ページ（マーケティング/ヘルプセンター）のみ送信；非公開ページは noindex
管理画面	admin、運用管理画面、カスタマーサポート/審査システム	フルセット + 独立した入口 + MFA + 監査ログ	高（全書き込み操作に署名 + 監査）	収録禁止：サイト全体 noindex + 強制認証
内部/個人システム	内部プラットフォーム、個人用ツール、スクリプトパネル、家庭内 NAS	認証 + 最小露出 + レート制限 + タイムリーな更新	中（露出面による）	収録禁止；公開ネットワークのデフォルトパスに配置しない、「隠蔽」をセキュリティに頼らない
純粋な API	REST / GraphQL / サービス間呼び出し	認証 + 入力検証 + レート制限 + バージョン管理	業務による（決済/資金系は必ず高）	該当なし（ページを生成しない）

判定問題は一つだけです：この URL は検索エンジンに表示されるべきですか？

されるべき → 公開サイトとして実行し、SEO 章の全ルールを適用します。
されるべきでない → 「収録禁止」を実行：サイト全体に X-Robots-Tag: noindex、robots でクロール禁止、強制認証。SEO 最適化（sitemap、canonical、構造化データ）を管理画面や個人システムに適用しないでください。それは無駄であり、攻撃面を露出させます。
いずれのシナリオでも、「存在しないパスは真の 404 を返す」ことを遵守する必要があります。それは SEO ではなく、HTTP の正しさです。

五つの基本原則

すべての入力は信頼できない：URL、query、body、header、cookie、アップロードファイル、Webhook、メッセージキュー、サードパーティ API の戻り値、さらにはデータベース内の過去の汚れたデータまで。
デフォルトで拒否（fail closed）：認証/検証/解析でエラーが発生した場合は許可ではなく拒否を返します。異常なパスは「検証をスキップ」する分岐に進んではいけません。
最小権限：データベースアカウントは機能ごとに権限を分割（読み取り/書き込み分離、DDL は許可しない）、クラウド IAM/オブジェクトストレージはプレフィックスごとに権限を付与、プロセスは root 以外で実行、コンテナは読み取り専用ファイルシステム。
多層防御：一層で防げない場合、次の層が防御します。フロントエンドの検証はユーザー体験であり、サーバーサイドの検証こそがセキュリティです。WAF は最終手段であり、代替手段ではありません。
爆発半径を制限する：0day はコード規約で排除できません。分離、権限制限、送信ホワイトリスト、迅速なパッチチャネルによって被害を最小限に抑えます。

レッドラインリスト（ハードルール、項目ごとにセルフチェック）

認証とセッション

パスワードは Argon2id/bcrypt(cost≥12)/scrypt でハッシュ化する。MD5/SHA1/可逆暗号化は禁止。
ログイン失敗は「アカウント + IP」の二軸でレート制限し、段階的に遅延を増やし、必要に応じて CAPTCHA/一時ロックアウト。
ログイン/登録/パスワードリセットのレスポンス文言と処理時間は統一し、アカウントの存在有無を漏らさない。
ログイン成功後、セッション ID をローテーションする（セッション固定化防止）。Cookie には HttpOnly + Secure + SameSite を付与。
JWT はサーバー側で固定アルゴリズムホワイトリストを設定し、alg:none とアルゴリズム混乱を拒否。短い有効期限 + refresh トークンによるローテーション + 失効可能。
認証 ≠ 認可：各インターフェースで「現在のユーザーがこのオブジェクトを操作できるか」を明示的に検証する（IDOR/権限昇格防止）。

インジェクションと出力

すべての SQL はパラメータ化クエリ/ORM バインディングを使用し、文字列連結は禁止。テーブル名/ソートフィールドはホワイトリストマッピング。
ユーザー入力をシェル/コマンドに直接連結しない。引数配列を使用する execFile 系関数を使用。
出力はコンテキストに応じてエンコードする。dangerouslySetInnerHTML/v-html/innerHTML は必ず DOMPurify などのサニタイザーを通過させる。
リッチテキスト、Markdown、URL パラメータはすべてホワイトリスト化し、フロントエンドのフィルタリングを信頼しない。
送信リクエスト（SSRF）はホワイトリスト経由で行い、任意のリダイレクトをフォローせず、内部ネットワーク/メタデータアドレス（169.254.169.254、127.0.0.1、10/8、172.16/12、192.168/16、::1、file://、gopher://）をブロックする。
ファイルパスは path.resolve 後にプレフィックスを検証し、.. を拒否。アップロードファイルはランダムな名前、タイプスニッフィング、隔離ストレージ、実行権限なし。

データと並行処理

重要な書き込み操作は冪等とする（一意インデックス / 冪等キー）。注文、支払い、コールバックは必ず冪等。
在庫、残高、回数などのフィールドは条件付き更新 UPDATE ... WHERE 余量 >= ? を使用し、「先に読み込んでから更新」は禁止。
トランザクションは短く、トランザクション内でネットワーク呼び出し、メッセージ送信、テンプレートレンダリングを行わない。
新しいクエリは必ず EXPLAIN を実行。大きな OFFSET ページネーション、SELECT *、N+1 クエリは禁止。
金額は整数のセントまたは DECIMAL を使用し、float/double は禁止。

非同期と安定性

すべての外部呼び出し（HTTP/DB/Redis/MQ）には明示的にタイムアウトを設定し、無限待機を禁止。
リトライは冪等な操作にのみ使用し、指数バックオフ + ジッター + 回数上限。
メッセージ消費は冪等とする（message_id 重複排除テーブル）。失敗時はデッドレターキューに入れてアラート。
重要なステータス変更は、データベースに先に書き込んでからメッセージを送信する（Outbox/トランザクショナルメッセージ）。二重書き込みは禁止。

ビジネスロジックと競合状態（最も見落とされがちなカテゴリ）

価格、金額、割引、権限レベルはすべてサーバーサイドで計算し、クライアントが送信する値は表示のみに使用。
クーポン/引き換えコード/招待コードはユーザーと回数にバインドし、アトミックに使用（条件付き更新または一意制約）。
ステートマシンは明示的に検証：不正な遷移は直接拒否（例：pending が支払いコールバックをバイパスして直接 paid になるなど）。
資金/コールバックインターフェースは署名 + タイムスタンプ + 冪等キーを検証し、リプレイ攻撃と偽造を防止。
購入制限、頻度制御は「ユーザー + デバイス + IP」の組み合わせで判断し、一つの軸のみで迂回できないようにする。
エクスポート、バッチ、検索インターフェースはレート制限 + データ量上限 + 監査。

シークレットと運用

シークレットは環境変数またはシークレット管理サービスのみに配置し、リポジトリ、イメージレイヤー、フロントエンドバンドル、ログ、エラーレポートへの埋め込みを禁止。
CI/CD クレデンシャルは最小権限とし、本番デプロイには承認が必要。サードパーティ依存関係はバージョンロック + スキャン。
機密操作（ログイン、権限変更、エクスポート、削除、返金）は監査ログに記録し、ビジネスコードで改変不可。

API 完全性（パケットキャプチャ/改ざん/リプレイ/レスポンス偽造の防止）

支払い、資金、認可、パスワード変更などの機密リクエストには署名を行う：HMAC(secret, method+path+sortedQuery+sha256(body)+timestamp+nonce)、サーバーサイドで再計算。
nonce は重複排除のために保存（TTL = 時間枠）、時間枠 ±300 秒。期限切れとリプレイを拒否。
機密性の高いレスポンス（支払い結果、認可結果、残高）にはサーバーサイド署名を含め、クライアントで検証。ただし、真実は常にサーバーサイドで再確認する。
クライアントが送信する「検証済み」マーク、価格、ロールは真実源として信頼しない。サーバーサイドで再計算/再確認。
モバイルアプリでは証明書ピンニングを実施。リリースビルドではユーザー証明書を信頼せず、デバッグとパケットキャプチャスイッチを無効にする。
クライアントの難読化/強化/アンチデバッグはコストを上げるだけであり、セキュリティ境界と見なさない。シークレットはクライアントに配布しない。

AI / LLM アプリケーション

モデル出力は信頼できない入力として扱う：eval しない、HTML/SQL/コマンドに直接連結しない、ツールパラメータを直接実行しない。
ツール/関数呼び出しは最小権限 + パラメータスキーマ検証 + 高リスク操作は人間の確認。
RAG で取得されたドキュメントは信頼できないコンテンツとして扱い、システムプロンプトと分離し、間接的なプロンプトインジェクションを防止。
システムプロンプトとユーザー入力を分離。シークレットや内部ルールを誘導によって出力される可能性のある場所に配置しない。
ユーザー/テナントごとにコストと頻度を制限。ログはマスキング（完全なプロンプトから機密データを記録しない）。

モバイル端末 / ミニプログラム

機密データは Keychain（iOS）/ Keystore（Android）に保存し、平文の SharedPreferences は使用しない。
通信は強制 TLS + 証明書ピンニング。InsecureSkipVerify/verify=False は一切禁止。
WebView はファイルアクセスと JS ブリッジの露出面を無効にし、onShouldStartLoadWithRequest でドメインホワイトリストを設定。
ミニプログラムの session_key はサーバーサイドでのみ使用し、フロントエンドに絶対に配布しない。code2session 後に独自のセッションを発行。
root/脱獄検出はリスクシグナルとしてのみ使用し、認証の根拠としては使用しない。

HTTP とルーティング（すべてのシナリオ）

存在しないパスは真の HTTP 404 + 404 ページを返し、302/200 でトップページにリダイレクトしない。
SPA の history fallback は「既知のフロントエンドルート」に対してのみ有効。/api、拡張子付きの静的リソースはすべて 404 を返す。
CORS は正確な Origin ホワイトリストを使用し、Access-Control-Allow-Origin: * と credentials の組み合わせ、任意の Origin のリフレクションを禁止。
本番環境ではセキュリティレスポンスヘッダーを有効にする：HSTS、CSP、X-Content-Type-Options、Referrer-Policy、frame-ancestors。
認証/機密インターフェースのレスポンスには Cache-Control: no-store を付与。
エラーレスポンスはスタックトレース、SQL、フレームワークバージョン、内部パスを返さない。

収録（公開サイトのみ必要。管理画面/内部システムは逆の対応）

公開サイト：sitemap は 200 ページのみリスト、canonical で重複排除、robots で管理画面パスを漏らさない、ステージング環境はサイト全体 noindex。
管理画面/内部/個人システム：サイト全体 X-Robots-Tag: noindex + robots Disallow: /、sitemap を生成せず、かつ認証必須（robots はアクセス制御ではない）。

フェーズ1：設計時

実装前に 5 分で軽量な脅威モデリングを実行します：

シナリオを決定：上記のプロジェクトタイプ表を参照し、公開サイト、管理画面、内部システム、API のいずれかを確認。これに基づいて SEO 章を実行するかどうか、露出面の大きさを決定。
データフローを描画：ユーザー → ゲートウェイ → サービス → データベース/キャッシュ/MQ/サードパーティ。信頼境界を越える各ポイントをマーク。
資産を列挙し、分類：アカウント、クレデンシャル、支払い、個人データ、管理画面。それぞれ「誰が読めるか、誰が書けるか、改ざんされた場合の影響、保持期間」を検討。
各境界で三つの質問：誰が到達できるか？入力は検証されるか？失敗した場合、デフォルトで拒否されるか？
権限モデルを決定：ロール → リソース → アクション。サーバーサイドで強制し、フロントエンドでのボタン非表示は権限制御と見なさない。マルチテナントシステムでは追加の分離ポリシーを定義。
非同期境界を決定：どの操作を同期的に返す必要があるか（ログイン、支払い確認）、どの操作を非同期にできるか（通知、レポート、エクスポート）。

設計ドキュメントには、少なくとも以下を明記する：プロジェクトタイプと収録ポリシー、認証方式、認可モデル、機密データの分類と暗号化、レート制限ポリシー、冪等キー、失敗時のフォールバック方法、ログと監査の範囲。

フェーズ2：実装時

認証とログイン（最優先）

ログインは最もブルートフォース攻撃、クレデンシャルスタッフィング、迂回されやすい入口です。完全なルールは references/auth-and-session.md を参照。中核となる妥協できないポイント：

レート制限は多層：単一 IP、単一アカウント、単一デバイスフィンガープリント。失敗カウントには Redis の期限付きキーを使用し、メモリのみに依存しない。
エラーメッセージは「アカウント名またはパスワードが間違っています」で統一し、処理時間も揃える（存在しないアカウントの場合もダミーハッシュを実行し、タイミング列挙を防止）。
ログイン成功後、セッション識別子を再生成。古いセッションは無効化。
機密操作（パスワード変更、バインディング変更、出金、削除）には二要素認証または直近の認証時刻（re-auth 期間）を要求。
パスワードリセットトークン：高エントロピー、使い捨て、短い有効期限（≤15 分）、ユーザーと用途にバインド。
管理画面は独立した入口、独立したドメインまたは IP ホワイトリストを使用し、ユーザー側とセッションを共有しない。

入力、インジェクション、出力

references/web-vulnerability-prevention.md を参照。原則：入口で統一検証（スキーマ）、出口でコンテキストに応じてエンコーディング。

// 入力：スキーマで検証し、未知のフィールドは拒否。「必要なものだけ取得」ではない。
const LoginBody = z.object({ email: z.string().email(), password: z.string().min(8).max(128) }).strict();

// SQL：パラメータ化、絶対に連結しない
await db.query('SELECT id, password_hash FROM users WHERE email = $1', [email]);
// ソート/テーブル名などパラメータ化できない場所：ホワイトリスト
const orderBy = { created_at: 'created_at', amount: 'amount_cents' }[sort] ?? 'created_at';

XSS：React/Vue のデフォルトエスケープで十分。危険な API は必ずサニタイズ。CSP を第二の防御線として使用。
権限昇格：クエリ条件に owner_id = $currentUser を含め、「取得後にフロントエンドで判断」はしない。
デシリアライゼーション/テンプレートインジェクション：eval しない、ユーザー入力をテンプレート/式/正規表現に直接連結しない。
アップロード：サイズとタイプを制限（マジックバイトによるスニッフィング）、ランダムなファイル名、オブジェクトストレージに保存、画像は再エンコード。

データベースと高並列処理

references/database-concurrency.md を参照。要点：

インデックスは最適化に先立つ：新しいクエリはリリース前に EXPLAIN を実行し、type=ALL、filesort、テンポラリテーブルに注意。
ページネーションはカーソル（キーセット）を使用し、深い OFFSET は使用しない。リストインターフェースには安定したソート + 上限が必要。
ホットスポットの書き込みは「条件付き更新 + 行ロック」を使用。在庫減少の例：

UPDATE sku SET stock = stock - $1, version = version + 1
WHERE id = $2 AND stock >= $1;
-- 影響行数が 0 の場合 → 在庫不足または並行競合。業務に応じてリトライ/失敗。

キャッシュの三種の神器：貫通防止（空値キャッシュ/ブルームフィルター）、なだれ防止（ミューテックスロック/シングルフライト）、雪崩防止（TTL にランダムジッターを追加）。
コネクションプールの上限は、データベースの max_connections / インスタンス数より小さくし、取得タイムアウトを設定。
規模が大きくなったらシャーディングを検討。まずはインデックス、キャッシュ、読み取り/書き込み分離、ホット/コールド分離を行う。

ビジネスロジックと競合状態

references/business-logic-and-race-conditions.md を参照。この種の脆弱性には統一されたスキャナーはなく、設計時に一つ一つ明確にする必要がある：価格と金額はサーバーサイドで計算、クーポンはアトミックに使用、ステートマシンの検証、リプレイ防止、購入制限の次元、エクスポートのレート制限。並行下での「先に読んでから書き込む」はすべて条件付き更新に変更するか、ロック + 冪等性を追加する。

非同期優先アーキテクチャ

references/async-architecture.md を参照。システムはデフォルトで非同期設計とする：

IO はすべてノンブロッキング。Node ではリクエストパスで同期的な fs/crypto と重い CPU 計算（worker_threads を使用）を禁止。
各外部呼び出しにはタイムアウトが必要。コールチェーンには trace id を伝播。
キュー消費 = 少なくとも一度の配信なので、必ず冪等とする。リトライには上限があり、超過時は DLQ に移動してアラート。
サービス間の一貫性には Outbox/CDC を使用し、二重書き込みは行わない。
長時間タスク（エクスポート、バッチ、審査）はキューに入れ、インターフェースは即座にタスク ID を返し、フロントエンドはポーリングまたは SSE でステータスをプッシュ。
グレースフルシャットダウン：新しいリクエストの受け入れ停止 → 処理中のリクエスト完了を待機 → キューコンシューマー停止 → 接続を閉じる。

HTTP、ルーティング、CORS、SEO

references/http-routing-cors-seo.md を参照。最も踏みやすい三つのポイント：

404 は 404 でなければならない。グローバルフォールバックでトップページにしない。SPA はビルド時に既知のルートに対してのみ index.html にフォールバックし、/api/* と拡張子付きのパスは直接 404 を返す。
CORS は正確なホワイトリスト。Origin を設定値と集合比較し、includes、プレフィックス一致、リクエストヘッダーの直接エコーバックを行わない。
ステータスコードのセマンティクスは正確に：401 未認証、403 権限なし、404 存在しない、409 競合、422 検証失敗、429 レート制限。

SEO は公開サイトに対してのみ有効。管理画面と内部システムは上記のシナリオ表に従って「収録禁止」を実行し、sitemap、canonical、構造化データを追加しない。それはクローラーに攻撃面を提供することになる。

シークレット、運用、メール

references/operations-and-secrets.md を参照。要点：シークレットは階層的に保存しローテーション、CI/CD 最小権限、コンテナ非 root、オブジェクトストレージとクラウド IAM は最小化、監査ログは改変不可、メールドメインには SPF/DKIM/DMARC を設定して偽造防止、データ保持期間と削除フロー。

API 完全性と改ざん防止

references/api-integrity-and-tampering.md を参照。パケットキャプチャと改ざんはモバイル端末と公開 API の最大の問題：リクエスト署名（HMAC + timestamp + nonce + body hash）、サーバーサイドでの再計算、機密レスポンスの署名、nonce 重複排除、時間枠、証明書ピンニング。覚えておくこと：クライアントが改変できるものはすべて信頼できない。署名はハードルを上げるだけで、真実はサーバーサイドでの再計算である。

AI / LLM アプリケーションセキュリティ

references/ai-llm-security.md を参照。モデル出力は外部入力と同等に扱う：実行しない、直接連結しない、SQL/コマンドにしない。ツール呼び出しは最小権限 + スキーマ検証 + 高リスク操作は人間の確認。RAG コンテンツは信頼できない。テナントごとにレート制限とコスト制御。

モバイル端末とミニプログラム

references/mobile-and-miniprogram.md を参照。Keychain/Keystore、証明書ピンニング、WebView の強化、ミニプログラムの session_key は配布しない、root 検出はシグナルのみとして使用。

フェーズ3：リリース前レビュー

順番に確認し、いずれかの項目が「不明」の場合は未通過として扱う：

レッドラインリストが 100% チェック済み。さらにプロジェクトタイプに応じて確認：公開サイトは SEO 項目、管理画面/内部システムは noindex と入口分離、機密業務は API 完全性。
python scripts/scan_redlines.py <ディレクトリ> --fail-on high を実行。高リスクは必ずゼロにする。
依存関係スキャン（npm audit / pip-audit / govulncheck / OWASP Dependency-Check）。高リスクは必ず対応。
シークレットチェック：リポジトリ、イメージ、ログ、フロントエンドバンドルにシークレットが存在してはならない。.env はバージョン管理に入れない。CI ログも同様にチェック。
コンテナ/ホスト：非 root、読み取り専用ルートファイルシステム、最小ポート露出、送信ホワイトリスト。
監視とアラート：ログイン失敗率、5xx、キュー滞留、スロークエリ、異常な送信リクエスト。
バックアップと復元の演習。データベースアカウント最小権限。
負荷テスト：クリティカルパス（ログイン、注文、リスト）でレート制限とキャッシュの有効性を確認。
メールドメイン：SPF/DKIM/DMARC を設定。送信インターフェースはレート制限し、フィッシングメールの偽造やスパムソースとして悪用されないようにする。
データライフサイクル：収集の最小化、保持期間、エクスポートと削除フローを明確に。ログはマスキング後に保持。
セキュリティ対応計画：誰が責任者か、どのように隔離するか、どのようにユーザーに通知するか、どのように振り返るか。
コンプライアンスマッピング（必要な場合）：references/compliance-mapping.md を参照し、OWASP/ASVS/等保/PIPL の項目をチェック。

フェーズ4：実行時と 0day 緩和

コード規約は未知の脆弱性を防げない。以下の手段で影響を制限する：

送信はデフォルトで拒否 + ホワイトリスト（SSRF、サプライチェーンコールバックの第一の壁）。
重要なサービスはサンドボックス/コンテナで分離、プロセス権限低下、seccomp/AppArmor を必要に応じて有効化。
依存関係はバージョンロック + 迅速なイメージ再構築。セキュリティ情報を監視し、緊急パッチチャネルを確保。
WAF/ゲートウェイで汎用的な特徴ブロックとレート制限を行うが、それだけに依存しない。
行動監視：異常なログイン地域/デバイスの急変、バッチ読み取り/書き込み、異常な送信トラフィック。
データ分類：機密フィールドは暗号化して保存（AES-GCM/KMS）、ログはマスキング、エクスポートは承認が必要。

references インデックス

ファイル	いつ読むか
`references/auth-and-session.md`	ログイン、登録、パスワード、JWT、2FA、パスワードリセット、CSRF、権限昇格、管理画面
`references/web-vulnerability-prevention.md`	SQL インジェクション、XSS、SSRF、アップロード、パストラバーサル、デシリアライゼーション、レスポンスヘッダー、API 固有のリスク
`references/business-logic-and-race-conditions.md`	価格/金額、クーポン、在庫、ステートマシン、TOCTOU 競合、購入制限、エクスポート乱用
`references/database-concurrency.md`	テーブル作成、インデックス、トランザクション、ロック、冪等性、キャッシュ、読み取り/書き込み分離、シャーディング
`references/async-architecture.md`	タイムアウト、リトライ、キュー消費、Outbox、バックプレッシャー、グレースフルシャットダウン、可観測性
`references/http-routing-cors-seo.md`	404、ステータスコード、CORS、キャッシュ、robots/sitemap、公開サイトと管理画面の収録分岐
`references/operations-and-secrets.md`	シークレット、CI/CD、コンテナ/クラウド、メールドメイン、監査ログ、データライフサイクル、緊急対応
`references/api-integrity-and-tampering.md`	パケットキャプチャ/改ざん、リクエスト/レスポンス署名、リプレイ防止、証明書ピンニング、クライアント強化の境界
`references/ai-llm-security.md`	プロンプトインジェクション、ツール呼び出し権限、RAG ポイズニング、モデル出力処理、コストレート制限
`references/mobile-and-miniprogram.md`	ローカルストレージ、証明書ピンニング、WebView、ミニプログラムログイン状態、root 検出
`references/compliance-mapping.md`	OWASP Top 10 / ASVS / 等保 2.0 / PIPL 対照表、監査やレビュー報告用
`references/internal-policy.example.md`	カスタムアセット禁止令テンプレートが必要な場合（プレースホルダーアドレス、実際のアドレスは含まれません）

デリバリー規約

コードを納品するたびに、返信で 3～6 行で今回のセキュリティ上の判断（検証ポイント、認可ポイント、冪等キー、レート制限、エラー処理）を説明してください。省略しないでください。
最初にプロジェクトタイプを説明します。納品が管理画面または内部システムの場合、「SEO は行わず、サイト全体 noindex」と明示します。公開サイトのみ、収録関連の設定を出力します。
既存のコードがレッドラインに違反している場合は、直接場所を指摘し、修正を提供します。「強化を推奨」とだけ言わないでください。
検証できない部分（実際に攻撃テストを実施していない場合など）は、「未検証」と明記します。セキュリティテストを通過したと主張しないでください。

bucai2417/secure-system-development

secure-system-development とは？

お気に入りのAIに質問する

ドキュメント