electrohire/site-health-security-report

サイト健全性＆セキュリティレポート

Webサイトの健全性とセキュリティに関する、AからFまでのグレード付きレポートを毎日（または毎週、毎月）生成するエージェントスキルです。多忙なオーナー向けに平易な言葉で報告します。ElectroHireが設計し、あらゆるスタックに対応するよう一般化された手法であり、元の企業のプロジェクトは手法の一部ではありません。

レポートは毎号、以下の5つの質問にエビデンスとともに答えます。

1. 人々はサイトにアクセスできたか、実際のトラフィックはどのようなものだったか？
2. 検索エンジンとAIクローラーはサイトを発見・引用できるか（SEO/AEO）？
3. コードは安全か：脆弱な依存関係、コードスキャン結果、漏洩したシークレット？
4. 境界は保たれているか：TLS、セキュリティヘッダー、メール認証、サイトおよびAPIのDDoS保護？
5. 最も影響の大きいアクションは3～5件は何か、それぞれに責任者は誰か？

毎号、全体および3つのサブグレード（トラフィック＆信頼性、SEO/AEO、セキュリティ＆コード健全性）ごとにAからFで採点され、グレードが下がるたびにその原因が1行で示されます。数値は決して捏造されません：実行できないソースは「利用不可」と理由とともに報告されます。

ルールゼロ：スタックインテークなしにこのスキルを実行しない

Cloudflare、GitHub、その他のベンダーを推測しないでください。最初のレポートの前に、references/stack-intake.mdのスタックインテークをユーザーと一緒に完了し、レポート設定として保存します（テンプレート：templates/config.example.json；templates/config.example.yamlは人間が読めるミラーであり、JSONファイルがツールが読み取る設定の記録です）。保存するファイル名はconfig.local.json（gitで無視）とし、認証情報は場所のみ（「ボールトエントリX」）で記録し、値では決して記録しません。インテークには以下が記録されます。

• エッジ/CDN/DDoS層：Cloudflare、AWS CloudFront（+ AWS WAFおよびShield）、Azure Front Door（+ Azure WAF）、Fastly、Akamai、Sucuri、またはなし。
• コードホスト：GitHub、GitLab、Bitbucket、Azure DevOps、Gitea/Codeberg、またはその他。
• ホスティング/オリジン：クラウドプロバイダ、リージョンモデル、ステージング設定。
• プライマリホスト名とサイドホスト（API、ステージング、アプリ、ワークスペース）の区別。この区別により障害の判断が決まります。下記のバーストルールを参照。
• 誰が、どのようなスケジュールで、どの送信経路でレポートを受信するか、および各推奨事項クラスの責任者は誰か。

インテークフィールドが不明な場合は、質問してください。推測されたスタックに基づいて構築されたレポートは、レポートがないよりも悪質です。そのギャップがあたかも発見事項のように見えるからです。

手法（6つの収集レッグ）

毎号、すべてのレッグを実行します。実行できないレッグは、理由とともに「利用不可」としてレポートに記載されます。決して、欠落したレッグを黙って回避しないでください。

1. トラフィック＆エッジ分析。 リクエスト数、ユニークビジター数、帯域幅、キャッシュ比率、ステータスコード構成（2xx/3xx/4xx/5xx）、トップパス、トップ国、エラー異常、スキャナー/プローブパターン。エッジプロバイダごとに、references/adapters-edge.mdを参照。
2. SEO / AEO。 AI対応チェック（例：check.aeojs.org）とSEOチェック（Seobility、フォールバックとしてPageSpeed Insights、さらにフォールバックとしてreferences/report-writing.mdの15項目オンサイト監査）。すべてのスコアは、今回の実行のスキャン識別子とタイムスタンプを伴います。
3. コードホストセキュリティ。 重大度別のオープンな依存関係アラート、重大度別のコードスキャンアラート、シークレットスキャンアラート、および前回の期間のコミットとCI/デプロイアクティビティ。サイトがアプリケーションプラットフォーム（WordPressコアとプラグイン、CMS）上で動作している場合、そのインストール済みコンポーネントの既知の脆弱性が、名前付きのプラットフォームソースからここでもカウントされます（発見事項 security.platform）：そのようなスタックでは、プラットフォームが悪用可能なコードの存在場所です。コードホストごとに、ホストにネイティブスキャンがない場合の対処を含め、references/adapters-codehost.mdおよびreferences/scanning-fallbacks.mdを参照。
4. 継続的な重大項目。 オーナーがクローズまで追跡するようフラグ付けた、名前と日付が付いた項目（本番環境のCVE、期限切れが近い証明書、移行）。クローズが確認された場合のみ削除されます。
5. Webサイトセキュリティスキャン（パブリック、アカウント不要）。 Mozilla Observatoryグレード（observatory.mozilla.org）、SSL Labs TLSグレードと証明書の有効期限（ssllabs.com/ssltest）、6つのセキュリティヘッダー（実施中のContent-Security-Policyはカウント、レポート専用はカウントされない）、HTTPからHTTPSへのリダイレクト、メール認証（SPF、DMARCポリシー、MX — 任意のDNSルックアップツールでドメインのDNS TXT/MXレコードから読み取ります）。これらのチェックはプライマリホストを評価します。サイドホストのヘッダーとTLSは説明文で報告され、グレードには含まれません。サイトとAPIのDDoS体制はreferences/ddos.mdでカバーされています。
6. プライバシー＆AIコンプライアンススポットチェック（公的にチェック可能なもののみ）。 プライバシーポリシーが正しい法人を管理者として明記しているか、該当する場合は音声/AIチャットデータをカバーしているか、決済代行業者を明記しているか。AIアシスタントは最初のやり取りで自身がAIであることを開示しているか。Cookie同意が表示されているか。データリクエストの経路が公開されているか。それぞれを合格、不合格、またはテスト不能として、ページのテキストのみから報告します。チェック対象の機能が存在しない場合（サイトにAIアシスタントがない場合など）、その理由でテスト不能となり、決して合格とはならず、不合格としてもカウントされません。

各レッグはその発見事項をその号の発見事項ファイルに書き込みます。正確なフィールド名、型、単位はreferences/findings-schema.mdで指定されています。発見事項ファイルは採点のサブセットであり、レポートの説明文の数値（合計、トップパス、スキャン識別子）は、同じレッグの日付付きエビデンスレコードから取得され、エビデンス元帳に一覧表示されます。

バーストルール（本番環境で学んだ教訓）

5xxエラーの急増は、自動的に障害とは見なされません。障害を判断する前に、バーストをホスト名とクライアントアドレスでセグメント化します。

• エラーが非プライマリホスト（APIサイドホスト、ステージングホスト）に集中しているか、主に1つのクライアントアドレスから発生している場合、それはそのホストに対するスキャナーまたはプローブイベントであり、ゾーン全体の合計がどれだけ大きくても、サイトの障害ではありません。
• セグメント化の結果をグレード化し、記述します。scripts/site_health.pyには、この判断を機械的に行うclassify_error_burst()が含まれています（必要なのは4つの数値：総エラー数、トップ単一アドレスからのエラー数、プライマリホストのエラー数、最もビジーな単一ホストのエラー数）。テストスイートは回帰ケースを保持しています。トラフィックに比例してホスト間で分散しているバーストは「分散型」として分類されます：オリジンまたはリージョンの障害パターンであり、スキャナーイベントではなく、自動的に障害ではありません。セグメント化後、残りの数値（その日のエラーからバーストを差し引いたもの）に基づいてトラフィックをグレード化します（references/grading.md参照）。

採点（すべてのホワイトラベル展開で同一）

完全なルーブリック：references/grading.md。概要：

• A：重大または高レベルのアラートが未解決でない（中/低レベルのバックログは正常であり、それ自体でグレードが下がることはない）、5xxの問題がない、SEO/AEOが90以上。
• B：軽微な問題のみ（スコア80-89、またはクリーンバンドを超える軽微なエラーノイズ、1行で明記）。
• C：高重大度アラートが未解決、スコア70-79、または顕著なエラー問題。
• D：重大アラートが未解決、スコア50-69、または繰り返される信頼性の問題。
• F：本番環境に影響を与えるパブリックエクスプロイトを伴う重大アラート、サイトの侵害が確認された、スコア50未満、またはサイトがダウンしている。

セキュリティサブグレードの低下原因には、Observatory D+以下、SSL Labs B未満、実施中のCSPの欠如、DMARCレコードなし（またはp=none）、コードまたはシークレットスキャンが機能していない、プライバシー/AIチェックの不合格などがあります。全体グレードは最も低いサブグレードです。低下のたびにその原因が1行で示されます。scripts/site_health.pyは発見事項ファイルからグレードを計算するため、同じエビデンスに対する2回の実行で結果が異なることはありません。

複数デプロイメント

1人のオペレーターが1台のマシンで複数のデプロイメントを実行する可能性があります。各デプロイメントは、独自のconfig.local.json、送信ログ、エビデンスフォルダ、エディションを保持する独自のフォルダに存在します。別のデプロイメントの設定やレコードをソースとして開いた状態でエディションを作成してはならず、顧客間で1つのストアを共有してはなりません（各設定は受信者と認証情報の場所を指定します — 共有ストアは顧客間の情報漏洩です）。べき等キーはデプロイメントごとに異なります（送信ログが異なるため）。複数デプロイメント設定では、キー自体にデプロイメントのフォルダ名が含まれます（report-<deployment>-<date>；単一デプロイメントではreport-<date>を使用）。間違ったフォルダで読み取られたキーは、送信済みか未送信かを判断できません。以下のコマンドのすべてのパスは、デプロイメントのフォルダ内にあります。あるデプロイメントのレコードは、別のデプロイメントのオーナーや受信者に、いかなる形式でも開示してはなりません。口頭や「比較のため」も含みます。リクエストを拒否し、リクエスト元のデプロイメントのレコードにその旨を記録します（別のデプロイメントを特定せずに）。リクエスト元のデプロイメントのレコードがサポートする内容のみを提供します。開示には、開示先のオーナーの記録された同意が必要であり、その開示のために与えられたものでなければなりません。

スケジューリング

オペレーターは、エージェントのスケジューラーまたはcronを使用して、設定の周期とタイムゾーンで実行をスケジュールします。スケジュールされたジョブの本体は、このスキルの呼び出しとデプロイメントの設定パスであり、署名済み設定が許可しないものは送信しません。スケジューリングは設定に基づく継続的な行為であり、号ごとに新たな承認を必要としません。

書き、検証し、妥当性確認し、そして送信する

完全な規律：references/verification.mdおよびreferences/report-writing.md。譲れない条件：

1. 保存されたレコードのみから作成します（各レッグは最初に、日付付きのエビデンスフォルダに生の出力を書き込みます）。
2. 送信前検証ゲートを実行します：すべての見出し数値を、その元となったレコードと照らし合わせて再読み取りします。追跡できない数値は、送信前に修正または削除されます（送信後ではありません）。
3. 独立した妥当性確認パスを実行します（エディションを作成しなかったエージェントまたは人物が、グレードを再導出し、レンダリングされたメールをテキスト部分と照合します）。
4. エディションごとにべき等キーを使用して正確に1回送信し、送信レコード（送信ログ内のプロバイダの受理ID）から送信を確認します。ルートが使用しない送信済みアイテムフォルダからは確認しません。
5. 修正も送信です：同じゲート、同じ妥当性確認、設定からコピーされた同じ受信者（再入力しない）。
6. Fグレード、確認された障害（確認されたサイドホスト障害も含む）、サイトの侵害が確認された場合、または製品で活発に悪用されている重大な脆弱性（プラットフォームコンポーネントも含む）は、スケジュールを待ちません：オーナーには設定のルートを通じて同じ日に通知され（エディションではなくインシデント通知）、次のエディションでは通常の方法で報告されます。

承認：オーナーは最初のエディションと、受信者、送信ルート、またはスケジュールへの変更が有効になる前に承認します。署名済み設定は、その下でのスケジュールされたエディションに対する継続的な承認です。承認はオーナーに紐付きます：オーナーの変更により承認は無効になり、新しいオーナーが承認するまでは何も送信されません（references/verification.mdの「オーナーの変更」を参照）。スタック自体の変更は、独自の規律を伴う修正です（オーナーの承認、部分的な再インテーク、バージョン管理された設定履歴）：references/stack-intake.mdの「署名済み設定の修正」を参照。グレードを変更する修正は、送信前にオーナーの承認が必要です。設定と送信ログのコピーを作業マシンからオフラインに保存し、紛失した場合は、再送信前にreferences/verification.mdの復旧手順に従ってください。ツール自体は以下のように実行されます。

python3 scripts/site_health.py validate-config config.local.json
python3 scripts/site_health.py grade findings.json
python3 scripts/site_health.py burst burst.json
python3 scripts/site_health.py check-run config.local.json findings.json report.md
python3 scripts/site_health.py headers https://example.com

エディション（または--kind correctionを付けた修正）は、check-runが成功した場合に検証されます。これは、設定、発見事項、レポートを一緒に検証します。発見事項が設定されたスタックと矛盾しないこと（スキャンが「なし」と記録されている場合、スキャンがオンであるとする発見事項は生成できない。エッジが設定されていない場合、保護されたエッジの姿勢を生成できない）、およびレポートの送信者と受信者が設定のものであり、コピーされ、再入力されていないことを含みます。チェックが強制する2つのフォーマットルール：From/To/Ccヘッダーがレポートの先頭にあること（最初の空行で終わり、最初の15行以内で開始する必要がある）、テンプレートの1行形式（ラベルは·または|で区切られる）であり、各行に1つのラベルを任意の順序で、箇条書き、またはブロックスタイルでアドレスを次の行に記述すること。また、セキュリティセクションの「使用スキャナー：」行は、各種類に対して設定されたスキャナーを指定します（表示名は許容されます）。これはfindings.scanners_usedと一致する必要があります。validate-reportのみでは、レポートの構造とグレードの一致のみをチェックします。これは作成補助であり、エディションの検証ではありません。ナラティブの数値を検証するバリデーターはありません。それはエビデンスレコードに対する送信前ゲートの仕事です。

テンプレート：templates/report-template.md（ホワイトラベル：ブランド名、色、受信者、オーナー名はすべて設定から取得）、templates/report-email.html、templates/correction-template.md、およびtemplates/evidence-ledger.example.md（AEEエビデンス元帳：レポート内のすべての主張は、その改ざん防止策とともにレコードにトレースされます）。

同じ方法でステージングWebサイトを運用する

このスキルは、本番環境で実証済みのブランチステージングアプローチと連携します。stagingブランチがステージングサブドメインにデプロイされ、本番環境はレビュー済みマージによってプロモートされます。ガードファイル（robots.txt、レスポンスヘッダー）はステージングと本番で意図的に異なり、プロモーション前にステージングツリーで検証されます。すべてのビジュアル変更は、ステージングでスクリーンショット検証され、プロモーション後にも再度検証されます。防止する障害モードを含む完全なワークフローは、references/staging.md（リポジトリのdocs/staging-workflow.mdに詳細なウォークスルーがあります）にあります。

アダプター

…

[翻訳のために切り詰め]