一條在台北寫的規則,擋下西雅圖首報的攻擊。
ATR 是公共財。任何人提一條規則,經公開 PR 與安全閘審查,就成為全球防禦者共用標準的一部分。MIT 授權,零專有工具,零 CLA。從回報一個繞過方法開始,15 分鐘。
開 Integration Request issue
任何引擎都可以實作這個標準——這條路徑就是給正在實作的人。結構化表單,5 分鐘填完;需要 spec walkthrough、design review、語言 sample code,或合規 mapping 就走這條。維護者七天內回覆。
開 issue→提 PR 加進 ADOPTERS.md
你的整合公開可驗證了就走這條。Schema 對、有 evidence link 就 merge — 維護者不預先審核採用者,這跟 Sigma 一樣。
ADOPTERS.md →提交新規則(5 分鐘,無需 fork)
~5 min發現新的攻擊模式?填一個 issue,bot 自動轉成 draft proposal PR。不需 clone repo、不需寫 YAML。
開一個 Issue→提交紅隊 Probe(加入基準測試)
~10 min有 attack payload + 良性對照樣本?bot 轉成 proposal,合進去之後自動納入下一輪 measurement 跑分。recall 數字看得到你的貢獻。
送一個 Probe→- Bot 把你的 issue 轉成 proposals/ 下的 YAML 草案,開一條 draft PR,你在 PR 的 author 欄位被掛名。
- maintainer 或社群把 detection regex 寫完,跑安全閘——真陽性與假陽性樣本、schema 合規、不與現有規則衝突,在良性語料上 0 FP 是硬條件。閘是真的會擋,不是擺設。
- 規則 merge 進主 branch,自動 npm publish + GitHub release——從這一刻起,它屬於每一個讀 ATR 的引擎,跨廠商、跨國界。
- 下一次 measurement 跑分時你的 payload 進入 corpus。 data/measurements/<source>/ 下的歷史檔記錄每一次跑分的 recall / precision / fp-rate,版本綁定不會 drift。
- 公開引用 recall 數字時 ATR 一定附上 measurement file 路徑,你的貢獻在公開審計鏈裡可追溯。
Spec(ATR-SPEC-v1,目前 v3.5.0 Working Draft)是所有相容引擎的契約。改動 spec 不像加規則那麼直接 — 流程是:先開 RFC issue 標題以 [RFC] 開頭,描述要改什麼、為什麼;留 14 天公開評論窗口(複雜提案延長至 30 天)讓所有 implementer 看到並回饋;接下來才接受 PR。Breaking change(SemVer 主版號)需要額外 30 天提前公告。
完整流程在 governance 頁的 Decision-making 區段。
如果你想開始但不確定從哪開始,有兩條低門檻入口:
- 「good first issue」標籤的 open issue — 維護者標記過、範圍清楚的入門任務。
- 規則的 false-positive 報告 — 你的工作流程中遇到誤判,15 分鐘填表格,就直接幫到下游所有採用者。維護者最重視這類回饋。
ATR 目前是 single-maintainer,正在主動招募第二位、第三位。候選條件、決策結構、以及申請方式都在 governance 頁。
看治理頁的「想成為維護者」段→Threat Cloud 是 ATR 維護者運營的選用參考服務,並非標準的一部分。標準本體是規格加上 MIT 授權的規則,透過 npm / PyPI / 純 YAML 完全可離線使用;Threat Cloud 只提供 hosted 便利(規則同步、威脅提交),不用它也能達到同樣結果。
Threat Cloud 自動化管線(選用便利層)
規則的權威產生路徑是上面「送出後會發生什麼」描述的社群/維護者流程(issue → bot 草案 PR → 維護者寫 regex → safety gate → merge → npm publish)。下面是 Threat Cloud 維護者運營的選用自動化版本,目標把同樣流程壓到數小時 — 用不用它,標準與規則都不變。