# 低摩擦資安 Rollout Policy

| 項目 | 內容 |
|------|------|
| 日期 | 2026-06-04 |
| 狀態 | IwoooS active policy；仍採 observe-first |
| JSON snapshot | `docs/security/security-rollout-policy.snapshot.json` |
| Schema | `docs/schemas/security_rollout_policy_v1.schema.json` |
| 原則 | 初期先建立框架、可見性與追溯性，不把資安限制一次拉到最高 |

## 0. 核心結論

本資安網初期採 `observe-first`，不是 `block-first`。

目標是讓 Kali、Code Review、GitHub、Gitea、Codex、AwoooP 先共享 evidence、狀態與 approval boundary。初期不應把每個 LOW / MEDIUM finding、repo 差異、文件缺口、owner 待定都變成阻擋條件。

## 0.1 IwoooS 2026-06-04 補充邊界

IwoooS 目前整體維持 64%，框架 / 只讀證據 / 前台可視化維持 92%，runtime landing 維持 40-45%，active runtime gate 維持 0。這些數字只是治理與可視化狀態，不是執行授權。

| 規則 | 說明 |
|------|------|
| S4.9 owner response 是第一優先 | owner role / team、decision、decision reason、affected scope、redacted evidence refs、followup owner 都齊全且通過預檢前，received / accepted 維持 0 |
| AwoooP approval 不是資安批准 | AwoooP 可顯示候選與 approval boundary，但不得把它當 security approval decision record |
| UI 可見不是 runtime 授權 | IwoooS 卡片、Gate、矩陣、候選狀態只代表可視化，不代表 scan、execute、host update、repo / refs / workflow / secret / primary switch |
| Code Review 候選只可人工轉派 | 審查後修正候選必須走人工批准，再轉 Codex patch / PR / guard；不得直接自動改 code 或自動 deploy |
| Kali / 主機維護需獨立窗口 | 192.168.0.112 / 111 / 168 仍先 observe-only；不得直接 `apt upgrade`、restart、hardening、active scan、credentialed scan 或 `/execute` |
| 跨 Session 必須先同步 | 每次改檔前先 `git fetch gitea`、確認 `gitea/main`、比對另一個 Session 的 commit / run / production evidence；禁止 force push |

## 1. 四種模式

| Mode | 用途 | 初期處理 |
|------|------|----------|
| `observe` | read-only inventory、evidence mirror、狀態追蹤 | 允許持續推進，不阻擋 |
| `warn` | LOW / MEDIUM observation、非不可逆差異 | 產生 follow-up，不自動卡流程 |
| `approve_required` | 會碰 token、repo 建立、visibility、refs、secret、deploy、primary switch | 建立 approval candidate，批准後才執行下一步 |
| `block_candidate` | 無 rollback 的破壞性動作、保存 raw secret、force push | 預設不執行，只能走人工 exception |

## 2. 低摩擦矩陣

| 條件 | Mode | 可以做 | 不可以做 |
|------|------|--------|----------|
| Read-only inventory / evidence mirror | `observe` | 收 metadata、寫 redacted snapshot、更新文件、mirror 到 AwoooP | 寫入遠端、刪 repo、sync refs |
| LOW / MEDIUM observation，且不涉及不可逆變更 | `warn` | 標風險、建 follow-up、準備草案 | 擋 deploy、自動 patch、自動 merge |
| 使用 read-only token 或管理匯出 | `approve_required` | 人工批准後單次執行、只保存 `token_present` | 保存 token value、使用寫入 token、建立 repo |
| 建 repo / 改 visibility / sync refs | `approve_required` | 建 approval candidate、準備 migration / rollback plan | 未批准直接執行、直接 push refs、切 primary |
| secret / RBAC / NetworkPolicy / firewall / deploy / primary switch | `approve_required` | 建 approval event、準備 dry-run / rollback | auto execute、保存 secret value、跳過人工 review |
| 無 rollback 的破壞性動作或保存 raw secret | `block_candidate` | 記錄原因、要求人工 exception | force push、delete repo、保存 raw secret、關閉 audit |

## 3. 非阻擋升級分流

這 7 條 lane 是 AwoooP 與平行 Session 的共用低摩擦護欄。它們只決定「先 observe / warn，什麼時候需要 owner review」，不授權 runtime blocker、deploy blocker、repo / refs action、Kali active scan 或自動修復。

| Lane | 初始模式 | 可以做 | 禁止升級 |
|------|----------|--------|----------|
| LOW / MEDIUM observation | `warn` | 標記風險、建立 follow-up、補 evidence_ref、準備草案 | 阻擋 deploy、自動 patch、自動 merge、建立 runtime blocker |
| Owner response missing | `observe` | 顯示 missing lane、next collection candidate、template status、request packet | 把未回覆當拒絕、停止產品流程、自動補 owner response |
| Mirror data incomplete | `warn` | 顯示 partial / quarantine reason、要求補 redacted snapshot、保留 retry gate | 阻擋無關 runtime、當 production incident、吞入未脫敏 payload |
| Source-control drift draft | `warn` | 維持 draft reconcile plan、ADR、read-only diff、owner review lane | sync refs、delete refs、force push、建立 repo、修改 visibility、切 GitHub primary |
| Kali observe finding | `warn` | 顯示 redacted finding summary、evidence_ref、scan scope approval candidate、block reason | 自動啟動 active scan、呼叫 `/execute`、直接變 deploy blocker |
| Workflow / secret name gap | `warn` | 要求 redacted export、顯示 owner response template、更新 readiness wording | 收集 secret value、啟用 GitHub hosted runner、修改 workflow / webhook / repository secret |
| Progress display holding | `observe` | 顯示 micro progress、latest delta、not_authorization、下一個高層 gate | 把 58% 解讀成卡住、把 micro progress 當 runtime approval |

每一條 lane 都要求 `owner_review_required_before_blocking=true`、`runtime_blocking_allowed=false` 與 `not_authorization=true`。AwoooP 可以顯示 `display_non_blocking_escalation_lanes` 與建立 follow-up，但不能把 follow-up 轉成阻擋條件。

## 4. AwoooP 初期行為

AwoooP 初期只應：

1. mirror Runtime State / Channel Event / Audit evidence。
2. 計算 read-only policy 建議。
3. 建立必要的 approval candidate。
4. 顯示阻塞原因，但不直接執行修復。

AwoooP 初期不應：

1. 直接啟動 Kali active scan。
2. 直接呼叫 Codex patch runner。
3. 直接建 GitHub repo 或修改 visibility。
4. 直接同步 refs 或切 GitHub primary。
5. 把所有 observation 都變成 blocking incident。

## 5. 階段性收斂

| 階段 | 目標 | 控制強度 |
|------|------|----------|
| S0 | 文件與契約同步 | observe |
| S1 | read-only evidence 建立 | observe / warn |
| S2 | AwoooP mirror-only | observe / warn |
| S3 | 高風險 approval gate | approve_required |
| S4 | 受控 migration / execution | approve_required + rollback |
| S5 | 規則收斂與自動化 | 只在 evidence 成熟後逐步提高 |

## 6. 永久邊界

即使後續提高資安等級，以下仍不得自動化：

1. 保存 raw secret / token value。
2. 無 rollback 的 repo 刪除 / force push。
3. 未經 owner 批准的 visibility 修改。
4. 未完成 parity 的 GitHub primary switch。
5. 未經人工批准的 production deploy。