75 lines
5.7 KiB
Markdown
75 lines
5.7 KiB
Markdown
# 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 視為完成。
|