SecTor 2025 | Scaling the AppSec Program Without Scaling Security Headcount
三句話摘要
Accenture 團隊如何為 Fortune 50 企業打造 AI 驅動的全應用程式安全體系，在不增加人力的前提下將第三方滲透測試發現率降低 95%。 應用程式安全的規模化突破點不在於增加安全人力，而在於把安全知識轉化為開發者日常工作流程中的確定性自動化，讓每個 Backlog 條目、每次掃描結果、每個 URL 都有一致且可追溯的處置動作。 資產盲點是所有安全計畫的起點：CMDB 只為管理授權存在，無法反映實際開發中的 API 數量、語言版本、部署頻率。AppNav 整合 DNS、程式碼倉庫、Pipeline、雲端資產等多源資料，才能真正知道「需要保護什麼」。
重點整理
重點- 1
資產盲點是所有安全計畫的起點：CMDB 只為管理授權存在，無法反映實際開發中的 API 數量、語言版本、部署頻率。AppNav 整合 DNS、程式碼倉庫、Pipeline、雲端資產等多源資料，才能真正知道「需要保護什麼」。
- 2
安全需求必須進入開發者的工作流程，而非存在 PDF 裡：ArcBot 將所有需求文件、Backlog、電子郵件餵入 AI，自動生成安全需求並直接注入 Backlog，讓開發者在做 Standup 時就能看見並做 Thumbs Up／Down 決策，建立可追溯的責任鏈。
- 3
修補方案分三層，不能盲目信任 LLM 生成代碼：確定性修補（直接替換不安全函式）→ RAG 驗證修補（從人工驗證過的修補庫選策略）→ 外部 AI 建議；機器人自動開 Security Branch、驗證編譯，再由開發者 merge，保留人類決策點。
- 4
滲透測試工業化的關鍵是「縮窄測試範圍、全面重複執行」：從第三方報告提取根本原因，建立極度聚焦的單一控制點測試，搭配 AppNav 自動提供目標清單，消除偵察時間，讓六人團隊得以對全部 1,700 個應用持續覆蓋。
實用技巧與重點
乾貨- 客戶規模：Fortune 50、1,700 個應用、滾動 90 天內 4,000–7,000 名活躍開發者
- ArcBot：一年處理 700 個應用、產生 70,000 筆安全審查、90% 需求被實作 → 可被利用漏洞減少 12 倍
- AppSecBot：一年提出 21,000 個修補方案；使用者互動 5–10 題即可判定真假陽性
- 自動滲透測試：每 2.5 個月掃描 4–4.5 百萬個 不同 URL 參數；假陽性（不可利用發現）低於 5%
- 第三方滲透測試發現數下降 95%，被迫從黑箱改為灰箱測試才能繼續找到問題
- 執行人數：約 6 人小團隊維運整個測試體系
- 工具：SQL 注入用 SQLMap；JWT 測試用 JWT Tool（寬鬆授權）；DAST 採用商業掃描器（廠商中立）；所有工具運行於雲端超大規模容器
- 生產環境政策：零 Critical 漏洞；High 漏洞容忍期最多 1–2 週
- RAG 修補庫：每個修補方案均附多種策略（例如白名單過濾 vs. Prepared Statement），說明各自對記憶體或資料庫的效能影響
- 安全分三層：In the pipeline（本次演講）/ Off the pipeline（供應鏈）/ Around the pipeline（存取控制）
結論
結論“應用程式安全的規模化突破點不在於增加安全人力，而在於把安全知識轉化為開發者日常工作流程中的確定性自動化，讓每個 Backlog 條目、每次掃描結果、每個 URL 都有一致且可追溯的處置動作。”
完整解析
詳細應用程式安全長期面臨一個結構性困境：安全團隊、開發者、測試人員、維運人員各有不同目標與語言，安全知識難以跨界傳遞。這家 Accenture 團隊花了五年為一家 Fortune 50 全球服務企業解決這個問題，核心約束是「不能大幅增加安全人力，但必須保護所有 1,700 個應用的每一個角落」。
第一步是解決「不知道自己有什麼」的問題。傳統 CMDB 為授權管理而生，無法追蹤開發中動態新增的 API、程式語言版本或部署頻率。他們建立了 AppNav，整合 DNS 記錄、程式碼倉庫、CI/CD Pipeline、雲端資產枚舉、法規合規標籤與 PII 分類，再透過 PowerBI 等視覺化工具讓決策者能直接消費這份情報。這份資產清單後來成為自動化滲透測試的目標來源，省去了偵察階段。
在開發早期，他們用 ArcBot 取代傳統的威脅建模文件。ArcBot 吸收開發團隊產生的所有文件（需求書、Backlog、電子郵件、影片等），結合公司的安全策略庫，自動生成安全需求並直接注入開發 Backlog。開發者只需在既有工作流程中對需求做 Thumbs Up 或 Down，系統自動記錄決策者姓名與理由，形成可追溯的責任矩陣。一年內 70,000 筆審查中有 90% 被實作，帶來可被利用漏洞的 12 倍減少；拒絕率偏高的通常是對效能影響大的需求，或因為已有其他防禦層而不必要。
開發過程中由 AppSecBot 接手。這是一個整合於 Microsoft Copilot 的聊天機器人，連接到所有靜態掃描器輸出，以 5–10 個問題引導開發者自己判斷真假陽性，並從三層修補庫中提供建議：確定性替換（如 Random → SecureRandom）、RAG 驗證修補方案（人工測試過、附效能影響說明的策略庫）、外部 AI 建議。機器人可自動開 Security Branch、驗證編譯通過後開 PR，保留最終 merge 決策給開發者。一年共提出 21,000 個修補方案；量化數據顯示，長期使用 AppSecBot 的團隊，引入漏洞的趨勢線持續下降，評估真假陽性的準確率也提升了。
最後一層是工業化的自動滲透測試。他們將歷次第三方滲透報告的根本原因提煉成極窄範圍的單一控制點測試（如「身份驗證流量是否指向正確的雲端 IdP？」），使用開源工具（SQLMap、JWT Tool 等）在雲端容器中對 AppNav 提供的全量目標清單執行。由於測試極度聚焦，假陽性率低於 5%，六人團隊每兩個半月可覆蓋 450 萬個不同 URL 參數，橫跨全部 1,700 個應用。執行一年後，第三方滲透測試發現數下降 95%，第三方公司不得不從黑箱改成灰箱測試才能繼續找到問題。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
