awoooi/docs/security/SECURITY-APPROVAL-QUEUE.md

Security Supply Chain Approval Queue

項目	內容
日期	2026-05-17
狀態	草案
Schema	docs/schemas/security_approval_queue_v1.schema.json
Snapshot	docs/security/security-approval-queue.snapshot.json
預設模式	approval_only
原則	AwoooP 可以顯示與排隊，但不得執行

0. 核心結論

本 queue 把目前 Security Supply Chain 已整理出的高風險或敏感邊界，集中成 AwoooP 可 mirror 的 approval queue。

它不是授權清單。所有 queue item 都只能顯示、排序、建立 approval candidate，不能直接執行。

S3.0 開始，人工批准範圍由 security_approval_gate_v1 承接。S3.1 開始，實際人工決策結果由 security_approval_decision_record_v1 保存。S3.2 開始，AwoooP 可用 security_approval_review_packet_v1 把 queue/gate 轉成可審查封包。S3.3 開始，決策後狀態由 security_approval_state_transition_v1 定義。S3.4 開始，後續 runtime gate 的準備資料由 security_followup_runtime_gate_v1 定義。Queue 負責排序候選；Gate 負責限制批准範圍；Review Packet 負責讓人好審；Decision Record 負責稽核紀錄；State Transition 負責定義 next state；Follow-up Runtime Gate 負責列出未來 runtime 前置條件。

目前狀態：

指標	數量
queue items	8
pending approval	7
block candidate	1
execution authorized	false
runtime changes authorized	false
raw secret storage authorized	false

1. Review 順序建議

順序	Queue item	為什麼先看
1	kali-finding-runtime-ingestion-approval-20260513	先接 redacted finding evidence，風險低、價值高
2	kali-safe-web-crawl-approval-20260513	TLS/header/basic crawl 屬低噪音，但仍需批准 scope
3	gitea-private-internal-server-side-inventory-2026-05-12	先依 S4.9 收到並驗收 S4.7 owner coverage attestation response，再審 Gitea 全量版本轉 GitHub 的只讀 inventory gate
4	source-control-target-repo-approval-bundle-20260513	先依 S4.10 request packet / template status ledger / audit event templates / redaction examples / collection checks / intake preflight checks 驗收逐 repo owner / visibility / canonical response，並依 S4.12 request packet / template status ledger / audit event templates / redaction examples / collection checks / intake preflight checks 驗收 workflow / secret 名稱 owner response
5	source-control-ref-truth-review-bundle-20260513	先依 S4.11 request packet / template status ledger / audit event templates / redaction examples / collection checks / intake preflight checks 驗收 refs truth owner response，再看 deprecated / release tag review
6	kali-credentialed-scan-approval-20260513	需要憑證，風險較高
7	kali-full-upgrade-reboot-approval-20260513	需要維護窗口、snapshot、rollback 與 post-check
8	kali-execute-endpoint-approval-20260513	CRITICAL，預設 block candidate，不應接入 runtime

2. AwoooP 可以做

1. 顯示 queue item、risk、state、required reviewers。
2. 顯示 evidence refs 與 blocked reason。
3. 建立 approval candidate。
4. 保存人工決策結果與 audit evidence。
5. 依 review order 提醒下一個低摩擦 gate。
6. 將批准範圍對齊 security_approval_gate_v1，用 security_approval_review_packet_v1 顯示審查封包，再把決策結果寫入 security_approval_decision_record_v1，最後依 security_approval_state_transition_v1 顯示 next state，並依 security_followup_runtime_gate_v1 顯示前置條件，但不觸發執行。

3. AwoooP 不可以做

1. 不直接啟動 Kali scan。
2. 不直接呼叫 Kali /execute。
3. 不建立 GitHub repo。
4. 不修改 repo visibility。
5. 不 sync refs。
6. 不切 GitHub primary。
7. 不保存 raw secret、token、cookie、private key 或 exploit payload。
8. 不把 LOW / MEDIUM observation 變成 blocking gate。

4. 初期策略

最適合先批准的不是高強度掃描，而是 kali-finding-runtime-ingestion-approval-20260513。

原因是它只允許接收已脫敏 security_finding_v1 摘要，能讓 Kali findings 進入 AwoooP 可見性與 audit，卻不會改變 firewall、RBAC、NetworkPolicy、deploy 或 Git 主控面。

kali-execute-endpoint-approval-20260513 則應維持 block candidate。除非未來建立 allowlist、disable gate、完整 audit 與人工 exception，否則不應讓 AwoooP runtime 直接碰這條路徑。

2026-05-17 S4.8 追加：Gitea queue item 不新增第 9 筆，而是把既有 gitea-private-internal-server-side-inventory-2026-05-12 升級為「S4.7 owner coverage attestation 先行」。AwoooP 應先要求 owner 對 5 個 coverage items 作 scope decision；未完成前不得把 inventory 標記 complete，也不得啟動 read-only token / redacted admin export runtime gate。

2026-05-17 S4.9 追加，2026-05-18 補 request packet、template status ledger、audit event templates、redaction examples、display sections 與 collection checks：Gitea queue item 仍維持同一筆，新增 owner response request packet、template status ledger、audit event templates、redaction examples、display sections、collection checks 與收件包作為 S4.7 的填寫提示與驗收格式。AwoooP 可顯示 1 個 request packet、5 個 template statuses、3 個 audit event templates、5 個 redaction examples、8 個 display sections、6 個 collection checks、5 個 response templates、6 個 intake preflight checks、5 個 outcome lanes、8 個 acceptance checks 與 10 個 rejection rules；未收到並驗收 response 前，不得把 owner attestation 視為完成。