貢獻
ATR 是社群驅動的。你的每一個貢獻都在保護整個生態系。
MIT 授權。零專有工具。零 CLA。從回報一個繞過方法開始,15 分鐘。
把 ATR 接到你的專案
規劃中 / 實作中
開 Integration Request issue
結構化表單,5 分鐘填完。需要 spec walkthrough、design review、語言 sample code、或合規 mapping 就走這條。維護者七天內回覆。
開 issue→已經 ship 了
提 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 寫完,跑 safety gate(0 FP on benign corpus 是硬條件)。
- 規則 merge 進主 branch,自動 npm publish + GitHub release。
- 下一次 measurement 跑分時你的 payload 進入 corpus。 data/measurements/<source>/ 下的歷史檔記錄每一次跑分的 recall / precision / fp-rate,版本綁定不會 drift。
- 公開引用 recall 數字時 ATR 一定附上 measurement file 路徑,你的貢獻在公開審計鏈裡可追溯。
想改 spec 本身
Spec(ATR-SPEC-v1)是所有相容引擎的契約。改動 spec 不像加規則那麼直接 — 流程是:先開 RFC issue 標題以 [RFC] 開頭,描述要改什麼、為什麼;留 7 天公開評論窗口讓所有 implementer 看到並回饋;接下來才接受 PR。Breaking change(SemVer 主版號)需要額外 30 天提前公告。
完整流程在 governance 頁的 Decision-making 區段。
第一次貢獻
如果你想開始但不確定從哪開始,有兩條低門檻入口:
- 「good first issue」標籤的 open issue — 維護者標記過、範圍清楚的入門任務。
- 規則的 false-positive 報告 — 你的工作流程中遇到誤判,15 分鐘填表格,就直接幫到下游所有採用者。維護者最重視這類回饋。
想成為維護者
ATR 目前是 single-maintainer,正在主動招募第二位、第三位。候選條件、決策結構、以及申請方式都在 governance 頁。
看治理頁的「想成為維護者」段→Threat Cloud 結晶流程
傳統規則需要數週撰寫、審查、發布。Threat Cloud 目標數小時。
1.在野外偵測到新的攻擊模式
|
2.LLM 分析攻擊結構和意圖
|
3.自動產生 YAML 規則提案和測試案例
|
4.社群審查 + precision 測試閘門
|
5.合併至 ATR。所有下游引擎自動更新。