網站健康與安全報告

網站健康與安全報告 是做什麼的？

這是一個代理技能，可以為網站產出有評級的每日（或每週、每月）健康與安全報告，並使用平易近人的語言，專為忙碌的業主設計。本方法由 ElectroHire 設計並推廣至任何技術堆疊，因此原創公司的專案並不屬於本方法的一部分。

報告每期都會回答以下五個問題，並附有證據：

1. 使用者能否連上網站？流量實際情況如何？
2. 搜尋引擎和 AI 爬蟲能否找到並引用網站內容（SEO/AEO）？
3. 程式碼安全嗎：有漏洞的依賴項、程式碼掃描結果、外洩的機密資訊？
4. 周邊防護是否穩固：TLS、安全標頭、電子郵件驗證、網站與 API 的 DDoS 防護？
5. 哪 3 到 5 項行動方案的影響最大，且每項都有指定的負責人？

每一期報告的總體與三個子項目（流量與可靠性、SEO/AEO、安全性與程式碼健康）都會獲得 A 到 F 的評級，且每個降級原因都會用一句話說明。絕不憑空捏造數字：如果執行過程無法取得某個來源，則會報告為「無法取得」並說明原因。

規則零：未完成堆疊資訊收集前，絕不執行此技能

不要預設使用 Cloudflare、GitHub 或其他任何供應商。在產出第一份報告之前，請與使用者一起完成 references/stack-intake.md 中的堆疊資訊收集，並將其儲存為報告設定檔（範本：templates/config.example.json；templates/config.example.yaml 是對應的人類可讀版本，而 JSON 檔案是工具讀取的正式設定檔）。將儲存的檔案命名為 config.local.json（已加入 git ignore），並僅依位置記錄憑證（例如「金鑰保管庫條目 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、暫置環境、應用程式、工作區）的區分。這個區別決定了中斷事件的判定；請參閱下方的突發規則。
• 誰會收到報告、排程為何、透過哪種發送路線、以及誰負責各類推薦事項。

如果有任何資訊收集欄位不清楚，請提出詢問。基於假設堆疊產出的報告比沒有報告更糟，因為其資訊缺口看起來像真正的發現。

方法（六個資料收集流程）

每個版本都必須執行所有流程。無法執行的流程會在報告中標示為「無法取得」，並附上原因。絕不默默地繞過缺少的流程。

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. 網站安全性掃描（公開，無需帳戶）：Mozilla Observatory 評級（observatory.mozilla.org）、SSL Labs TLS 評級與憑證到期日（ssllabs.com/ssltest）、六項安全標頭（強制性的 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 次要主機、暫置主機）或主要來自單一客戶端位址，則這是一個針對該主機的掃描器或探測事件，而非網站中斷，無論區域範圍內的總數看起來有多大。
• 根據分段結果進行評級和撰寫。scripts/site_health.py 提供了 classify_error_burst() 函式以機械化進行此判斷（它需要四個數字：錯誤總數、來自單一最高位址的錯誤數、主要主機上的錯誤數、以及單一最繁忙主機上的錯誤數），測試套件中包含了回歸測試案例。如果錯誤在各主機之間按其流量比例分布，則歸類為「分散式」：這是一種原始伺服器或區域故障模式，根據數量進行評級，不是掃描器事件，也不會自動視為中斷。分段完成後，使用剩餘數據（當天的錯誤減去突發事件的錯誤）來評級流量，請參閱 references/grading.md。

評級（在所有白牌部署中均相同）

完整評分標準：references/grading.md。簡而言之：

• A：沒有開放的中等或高嚴重性警示（中等/低優先級積壓是正常的，本身不會降低評級）、沒有 5xx 問題、SEO/AEO 90 分以上。
• B：僅有輕微問題（分數 80-89，或高於乾淨基準的輕微錯誤噪音，用一句話說明）。
• C：有任何高嚴重性警示開放、分數 70-79，或明顯的錯誤問題。
• D：有任何嚴重警示開放、分數 50-69，或反覆出現的可靠性問題。
• F：有影響生產環境且存在公開利用程式的嚴重警示、確認網站遭到入侵、分數低於 50，或網站無法訪問。

安全子評級降級原因包括：Observatory D+ 或更差、SSL Labs 低於 B、缺少強制性 CSP、沒有 DMARC 記錄（或 p=none）、程式碼或秘密掃描無法運作，以及任何隱私/AI 檢查失敗。總體評級取最低的子評級。每個降級原因都會用一句話說明。scripts/site_health.py 從發現檔案計算評級，因此使用相同證據的兩次執行結果不可能不一致。

多重部署

一個操作者可以從一台機器上運行多個部署。每個部署都位於自己的資料夾中，其中包含其 config.local.json、發送記錄、證據資料夾和版本；絕不要使用另一個部署的設定檔或記錄來撰寫版本，也絕不要跨客戶共享儲存空間（每個設定檔都指定了收件人和憑證位置——共享儲存空間會造成跨客戶暴露）。冪等金鑰是按部署劃分的，因為發送記錄是按部署劃分的，而且在多重部署設定中，金鑰本身會包含部署的資料夾名稱（report-<deployment>-<date>；單一部署使用 report-<date>），因此在錯誤的資料夾中讀取的金鑰不可能看起來已發送或未發送；下面命令中的所有路徑都在部署的資料夾內部。一個部署的記錄絕不能以任何形式向另一個部署的業主或收件人透露，包括口頭或「用於比較」：應拒絕該請求，在請求部署的記錄中記錄此事件（不提及另一個部署的名稱），並且僅提供請求部署自身記錄所支持的內容。披露需要另一位業主書面記錄的同意，且該同意是針對該次披露的。

排程

操作者使用其代理的排程器或 cron，按照設定檔的節奏和時區來排程執行；排程作業的內容是此技能的調用加上部署的設定檔路徑，並且不會發送已簽核設定檔未授權的任何內容。排程是設定檔下的一項持續性授權行為，並非每個版本都需要新的核准。

撰寫、驗證、確認，然後發送

完整規範：references/verification.md 和 references/report-writing.md。不可協商的項目包括：

1. 僅從儲存的記錄撰寫（每個流程首先將其原始輸出寫入一個註明日期的證據資料夾）。
2. 執行發送前驗證關卡：重新讀取每個重點數據與其來源記錄進行比對。無法追溯到來源的數據必須在發送前修正或移除，絕不能在發送後才處理。
3. 執行獨立的驗證環節（未參與撰寫版本的代理或人員重新推導評級，並檢查呈現的電子郵件與文字部分是否一致）。
4. 僅發送一次，每個版本都帶有冪等金鑰，並從發送記錄（發送記錄中來自提供者的已接受 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 通過時即被驗證：它會一起驗證設定檔、發現項目和報告，包括發現項目不能與設定的堆疊矛盾（掃描記錄為「無」不能產出聲稱掃描已開啟的發現項目；未設定邊緣層不能產出受到保護的邊緣狀態），以及報告的寄件人和收件人必須與設定檔中的一致（是複製過來的，不是重新輸入的）。check-run 強制執行的兩個格式規則：From/To/Cc 標頭位於報告頂部（在第一個空白行結束，且必須在前 15 行內開始），使用範本中的單行格式（標籤以 · 或 | 分隔），每個標籤一行，順序不限，可以使用項目符號或區塊樣式（地址在下一行）；安全章節中的「Scanners of record:」行必須為每種類型指定已設定的掃描器（可接受顯示名稱），這必須與 findings.scanners_used 相符。僅執行 validate-report 只檢查報告結構和評級一致性；它是撰寫輔助工具，不是版本驗證工具。沒有任何驗證工具能驗證敘述性數據；這是發送前關卡的任務，需比對證據記錄。

範本：templates/report-template.md（白牌：品牌名稱、顏色、收件人和業主名稱均來自設定檔）、templates/report-email.html、templates/correction-template.md 和 templates/evidence-ledger.example.md（AEE 證據分類帳：報告中的每個聲明都可以追溯到一條記錄，以及其偽造者）。

以相同方式建置暫置網站

此技能與一個在生產環境中驗證有效的分支暫置方法搭配使用：staging 分支部署到暫置子網域，生產環境通過審查後的合併進行升級，守護檔案（robots.txt、回應標頭）在暫置與生產環境之間刻意不同，並在升級前於暫置樹中進行驗證，且每個視覺變更都在暫置環境中進行螢幕截圖驗證，並在升級後再次驗證。完整的工作流程，包括其防止的故障模式，位於 references/staging.md（詳細說明在儲存庫的 docs/staging-workflow.md 中）。

Adapters

…

[基於長度限制截斷]