Cisco 於 11 月 9 日公開一套把漏洞發現轉成編碼指引的工作流程，利用 Foundry 記錄尚未涵蓋的弱點類型，再產生 CodeGuard 預防規則與後續偵測規則。CodeGuard 是 Cisco 原始開發、捐贈給 CoSAI 的開源框架，以 Markdown 指引支援不同 AI 編碼助手，讓同一組織的安全經驗可被重複使用。
作者示範兩類案例：信任可由外部設定的轉送標頭、進而錯誤判斷本機連線，以及從呼叫者提供的路徑擷取識別碼卻未充分驗證。產生流程會同時寫出供編輯器載入的規則與供 Foundry 檢查既有程式的 YAML。規則可透過專案儲存庫、格式轉換工具或集中管理的 MCP 服務分送，涵蓋規劃、產生及審查階段。
不過文章明確保留限制：合成規則需要人工審查，作者曾發現模型引用了與案例無關的漏洞編號，核對後才修正；並非所有偵測缺口都能自動轉成規則。這次展示證明的是規則能產生及交付到助手環境，尚未以控制實驗證明助手因此減少產生有漏洞程式的機率。作者將效果驗證列為後續工作，不能把示範當作完整安全保證。
發生了什麼事
Cisco 技術文章展示 Foundry 與 CodeGuard 串接流程，從漏洞缺口產生兩類規則，再讓編碼助手及偵測工具共同使用，以保留專案的安全經驗。
為什麼重要
漏洞若只留在報告中，新的程式可能重複相同弱點。把經驗變成可讀取指引具有實務價值，但規則品質與實際預防效果仍是兩項不同的驗證工作。
影響哪些人
使用 AI 編碼助手的研發、安全與平台團隊，可參考其規則分送設計；採用前應由人員核對指引、引用及適用情境，並自行測試是否有效。
已確認與未確認
已展示規則生成與載入，作者也公開一次錯誤引用的修正。文章未證明漏洞產生率已下降，因此不把工具描述為已驗證能阻止同類問題再次出現。
