安全發現（security finding）描述可被利用的弱點，可能造成資料外洩、權限提升、任意命令執行或服務中斷。
處理這類問題時，需要說清楚攻擊者能控制哪些輸入、輸入經過哪些程式路徑、影響最後落在哪裡，以及現有防護為何沒有攔住它。
掃描工具提出的警告是一項待審查假設。開發者需要確認程式路徑可達、攻擊條件合理、受影響資料確實存在，並排除測試程式、已停用功能，以及外層防護已攔住的情況。
這些證據會影響嚴重度、修補優先順序與後續追蹤方式。
Codex Security 可以協助建立威脅模型、搜尋可疑路徑、驗證 finding、整理影響範圍與產生修補建議。
人工審查仍要負責接受或駁回 finding、確認產品安全規則、核准程式修改，並判斷剩餘風險是否可接受。
在 Codex 桌面版進入 Security > Scans，選擇 + Scan，再指定 codex-hands-on 儲存庫或資料夾與 Codebase，即可建立掃描。
也可以在已開啟專案的對話中輸入以下要求。
Use $codex-security:security-scan to scan this repository for security vulnerabilities.
第一次處理這個儲存庫時，先執行標準掃描。檢查結果與涵蓋範圍後，再依需要使用較深入的掃描。
一次掃描會經過威脅建模、探索、驗證、影響分析與報告整理。
審查時，先核對掃描目標、程式版本、納入範圍與延後檢查的區域，再查看每項 finding 的來源、危險操作、攻擊者輸入、可達性、信心與嚴重度。
缺少關鍵證據的項目可以駁回或保留待查，證據足夠的項目再接受進入修補。
掃描資料夾中的 report.md 適合閱讀整體結果，findings.json 保存結構化 finding，coverage.json 說明已檢查、排除與延後的範圍，scan-manifest.json 記錄掃描身分與設定。
保存這些原始產物，後續才能回答「哪個版本被掃過」及「哪些區域尚未確認」。
今天使用 codex-hands-on 進行掃描後，得到的 SEC-017 作為練習。
這個命令列工具會讀取議題 JSON，依 priorityScore 排列議題，再輸出議題標題與 bug、feature、documentation、security 四種標籤統計。
掃描發現文字輸出直接印出外部檔案中的 title。攻擊者若能提供議題資料，就能在標題中放入 ANSI 逸出序列（ANSI Escape Sequence），干擾終端機畫面或 CI Log。
id: SEC-017
title: Issue title permits terminal escape-sequence injection
severity: medium
confidence: high
status: validated
source: JSON 輸入中的 issue.title
sink: 文字格式化結果寫入標準輸出
location: 由掃描結果指出實際的文字格式化與 CLI 輸出位置
security_invariant: 外部議題文字不能控制終端機顯示行為
reproducer: title 含有 \u001b[2J 時，文字模式把控制序列寫入終端機
expected: 文字模式移除或安全轉義控制字元，正常標題與 JSON 輸出契約維持原狀
這項 finding 的影響取決於輸出位置。
在開發者終端機中，控制序列可能清除畫面、改變顏色或讓惡意文字看起來像工具訊息。
在保存原始控制字元的 CI Log 中，也可能干擾後續閱讀與事件調查。
範例先將它列為中風險，並限制這輪只處理 SEC-017，避免多項安全修改混在同一份 Diff。
把 finding 交給 Codex 後，第一輪先採唯讀分析。
要求它從 JSON 解析追到議題排名、報表組合、文字格式化與標準輸出，說明哪些欄位能由外部資料控制，以及現有程式是否處理控制字元。
引用檔案和行號能讓開發者直接核對結論，也能及早發現掃描報告和目前版本不一致。
請審查 SEC-017，先不要修改檔案。
1. 驗證 finding 是否適用目前版本，列出來源、資料流、危險操作與攻擊條件。
2. 找出 JSON 解析、文字格式化、標準輸出與既有整合測試，附上檔案及行號。
3. 說明終端機與 CI Log 的影響、可達性、嚴重度理由與仍缺少的證據。
4. 提出最小修補計畫、回歸測試與驗證命令。
安全規則：外部議題標題不能控制終端機顯示。
正常文字輸出、priorityScore 排名、四種標籤統計與 --format json 契約都要維持。
等我確認計畫後再修改。
合適的計畫應把修補放在文字輸出的信任邊界，讓終端機收到安全內容，同時保留程式內的原始議題資料。
若 JSON 模式是供其他工具使用的既有資料契約，不能在共用資料層直接改寫標題，否則安全修補會連帶改變機器可讀輸出。
Codex 需要先確認文字與 JSON 兩條輸出路徑的實際分工，再決定最小修改位置。
計畫確認後，只處理已接受的 finding。
以今天範例為例，可以在文字格式化邊界加入小型清理函式，移除或轉義會改變終端機狀態的控制字元，再把安全字串交給既有輸出流程。
修改範圍應集中在文字格式化實作與對應測試，避免順便調整議題排名、標籤統計、參數解析或 JSON 格式化函式。
安全回歸測試要先證明舊程式會失敗，再證明修補後通過。
此處至少保留三個案例：
\u001b[2J 的標題不會把 Escape 字元寫入標準輸出。--format json 時，輸出仍可由 JSON.parse 解析，既有欄位與四種標籤統計維持原契約。依已確認的計畫修補 SEC-017，只修改必要的文字格式化實作與測試。
先加入可重現終端機控制字元注入的回歸測試，記錄修補前的失敗結果。
再套用最小修改並執行該測試、相關整合測試、完整測試與 lint。
不要變更 priorityScore 排名、四種標籤統計、JSON 欄位或命令列參數。
完成後顯示 Diff、每個驗證命令的實際結果，以及未驗證項目。
若測試環境無法觀察真實終端機行為，紀錄中要標示證明缺口（proof gap），並直接檢查標準輸出的位元組或字串內容。
測試通過只表示目前案例受保護，仍需查看錯誤輸出、摘要文字與其他會顯示外部欄位的路徑是否存在相同問題。
修補驗證需要同時覆蓋原始重現方式、正常議題資料與鄰近繞過路徑。
開發者應檢查 Escape 字元、其他 C0 控制字元、換行與 Unicode 文字的處理，並確認錯誤輸出與其他摘要路徑是否會再次印出未處理的標題。
接著依 AGENTS.md 執行專案指定的 Build、Test、Lint 與型別檢查。
Codex Security 的驗證結果不會自動代表 finding 已關閉。
負責人要閱讀 Diff 與測試輸出，確認修補已進入預計發布的版本，必要時安排重新掃描。
若只完成程式修改，狀態可以標為「已修補，待發布驗證」。若其他文字輸出路徑尚未檢查，則保留剩餘風險和負責人。
判定誤報也需要留下理由。紀錄應說明無法到達的程式路徑、可靠的外層控制或錯誤的資料流假設，並附上可重查的證據。
單純寫下「看起來安全」不足以支持關閉決定。
修補紀錄要讓未參與工作階段的人看懂 finding、修改與證據。
內容包含原始 finding ID、受影響版本、風險與攻擊條件、根因、修改檔案、修補方式、驗證命令、結果、剩餘風險與審查狀態。
敏感的利用細節、權杖與客戶資料應留在限制存取的系統。
## 安全修補紀錄：SEC-017
### Finding 與風險
- 狀態：Validated / Accepted
- 影響：惡意議題標題可干擾終端機畫面或 CI Log
- 根因：文字輸出直接寫入外部 title，未處理終端機控制字元
### 修補與驗證
- 修補：在文字格式化邊界移除或安全轉義控制字元
- 回歸測試：正常標題、含 Escape 字元的標題、既有 JSON 輸出
- 命令與結果：填入實際命令、通過數量、失敗與未執行原因
### 剩餘風險與審查
- 證明缺口：填入未覆蓋的路徑或環境限制
- 發布狀態：待發布 / 已發布 / 已重新掃描
- 人工審查：負責人、日期、決定與追蹤連結
紀錄中的結果必須來自實際輸出，不預先填寫「全部通過」。
若 Codex 只能產生修補檔，也要先審查提議 Diff，再把同一份修補套用到工作區並執行驗證，避免審查內容和最後落地內容出現差異。
需要跨團隊處理或無法立即修補的 finding，可以輸出為 JSON、CSV 或靜態分析結果交換格式（Static Analysis Results Interchange Format, SARIF），也可使用 $codex-security:track-findings 建立 GitHub Issue、Jira 工作項目或私有 GitHub Security Advisory。
可在 Jira 建立受限的 CODEX 專案工作項目，再連回 codex-hands-on 的修補 PR。
追蹤前先確認 finding 已驗證，並搜尋是否已有重複項目。
外部寫入前要顯示確切目的地、可見範圍與完整內容，等待人工批准後再建立。
高風險漏洞若含有可利用細節，應使用私有安全通報或受限專案，避免公開 Issue 洩漏攻擊方法。
建立後回讀項目，保存 URL、外部識別碼、負責人、期限與狀態。
掃描、修補與追蹤各自留下不同證據。
掃描報告保存發現與涵蓋範圍，Git Diff 和測試輸出證明修改內容，追蹤系統保存責任、期限與發布狀態。
三者連在一起，團隊才能從原始 finding 追到修補決策，也能在重新掃描或事件調查時還原處理過程。
iThome鐵人賽
看影片追技術