作者 | 婁麒麟、張思楚

接上篇《將安全內建于開發流程中：威脅應對分步指南(Build Security In) - 上》

上篇中，咱們解釋了什么是威脅，列舉了常見的安全威脅，引入了“威脅四象限分類法”，將威脅分為開發人員相關和系統開發相關。針對性的討論了開發人員相關的安全威脅，強調了通過工具與流程自動化以及將安全意識融入日常工作的重要性。本篇咱們將繼續討論如何應對系統開發相關的安全威脅。

三、應對策略：針對性解決

2. 系統開發相關的安全威脅應對策略

軟件系統開發過程中相關的安全威脅多源于系統設計、架構實現或基礎設施層面的不當決策，這類問題一旦產生，影響范圍廣，回滾成本高。應對這類威脅的策略需圍繞 設計前置、評審規范、持續建模與自動化防御四個方面進行。

(1) 風險識別前移至故事卡片級別

① 在 Backlog Grooming 階段加入“安全影響評估”環節：安全冠軍或資深開發協助識別本卡片可能帶來的系統性安全風險。

② 標記具有“外部影響面”的卡片為“需安全建模”，例如：

• 新增或暴露 API 接口
• 調整權限控制邏輯
• 改變日志記錄內容結構
• 修改云資源（如開啟公網訪問、調整安全組規則）
• 引入新庫或第三方服務

(2) 引入輕量級威脅建模流程

① 采用卡片級威脅建模清單（可基于 STRIDE、LINDDUN 等模型簡化），如：

• 是否可能造成越權訪問？
• 是否引入了未受控的外部輸入？
• 是否改變了攻擊面或暴露新入口？

② 風險明確的卡片需填寫對應的 Security Acceptance Criteria (SecAC)，并作為“完成標準”之一納入開發流程。

(3) 標準化的 SecAC① 使用流程

• 建立團隊共享的 SecAC 模板庫，涵蓋常見情境（如日志脫敏、WAF 配置、API 限流、安全頭設置等）以便快速復用。
• 將 SecAC 明確記錄在 Jira 的 Checklist 或 Acceptance Criteria 中，避免僅口頭討論，確保開發與測試一致遵循。
• 通過 PR 審查機制驗證 SecAC 實施情況，提升責任閉環。

釋義: SecAC 安全驗收標準（Security Acceptance Criteria）是指在軟件開發過程中的用戶故事（User Story）、技術任務或功能需求中，明確定義的、可驗證的安全性標準，用于確保交付的系統功能在滿足業務目標的同時，也符合相應的安全要求。 它是“驗收標準”的一個子集，專注于安全方面的需求，用于幫助團隊系統性地防范潛在的安全風險。

(4) 加強架構與平臺安全對齊

• 建立與平臺團隊的 “安全設計對齊機制”：如變更云架構、API 網關策略、微服務邊界等，應通過架構審查會獲取平臺安全建議。
• 使用基礎設施即代碼（IaC）模板規范安全配置：例如默認啟用 WAF、防止 S3 公共讀、限制出入站流量。
• 在部署流水線中自動掃描配置與依賴漏洞（如 Dependabot, Checkov、Snyk、AWS Inspector），降低人為疏漏概率。

(5) 數據與外部接口安全

• 引入數據分類機制，區別處理敏感數據與公開數據，控制日志記錄和數據共享。
• 為對外接口統一配置流量限制、認證機制和異常告警閾值，防止 API 濫用或被攻擊。

(6) 安全持續演進與知識回流

• 每個發布周期定期回顧 “系統變更帶來的潛在安全影響”，整理為知識庫條目，避免重復踩坑。
• 推動團隊參與內部 “系統安全診斷練習” 或 “設計回顧”，形成安全設計文化。

四、利用 Security AC 應對系統安全威脅

在我們的實踐中發現應對系統開發相關安全威脅（System Facing Security Threats），最大的挑戰往往在于：這類威脅隱藏在系統行為、架構設計、配置策略或第三方集成等技術細節中，容易被忽略，且一旦發生，往往影響范圍廣、損害嚴重。傳統的風險控制手段，如開發流程控制、威脅建模、滲透測試或個人經驗很難系統性地識別和防范這些威脅，或者存在反饋不及時、成本高昂等不足。

在敏捷項目管理流行的今天，應對系統安全威脅也可以從敏捷中獲取思路，采用輕量級、快速反饋的機制。安全驗收標準（SecAC） 正是一種結構化的手段，能夠將安全要求明確地嵌入功能需求和交付流程中。我們已經在多個客戶項目中長期應用SecAC作為安全內建的核心手段，得到了較為可喜的成果。尤其是在設計和開發階段，通過 SecAC 明確 “系統應該如何防止 XX 類型的威脅”，團隊可以：

• 將安全風險的識別 “左移”，減少后期返工；
• 促進團隊在評審、測試、發布環節中有一致的安全判斷依據；
• 將抽象的安全關注點具象化為具體、可驗證的交付標準，降低成員的認知負擔；
• 通過標準化和文檔化，提升團隊整體安全意識和知識積累。

SecAC 不僅是規范交付質量的手段，更是團隊在應對系統安全風險時建立 “工程化防線” 的關鍵機制。

1. SecAC 的使用情況與挑戰

我們抽取了20來個團隊2024年一整年的 SecAC 數據并對其進行了調研，調研結果表明，盡管 70% 的團隊已開始使用 SecAC，但大多數團隊僅將其應用于少部分卡片 (20%左右)。應用率低是 SecAC 執行中的一大瓶頸。究其原因，受訪團隊表示挑戰主要在于：容易忘記加入SecAC、驗收標準描述模糊、忽視小任務等問題。

此外，團隊普遍希望獲得更多的培訓，學習SecAC的成功案例，及得到更易用的工具支持。

五、如何進一步提升 SecAC 使用效率

基于一線團隊對應用SecAC的反饋，為了進一步提升 SecAC 的應用效率，我們提出以下幾種參考策略：

1. 簡化與自動化 SecAC 的編寫

當前，SecAC 的使用仍然依賴開發人員在每個任務卡上手動添加安全準則，雖然這有助于強化安全意識，但由于繁瑣的流程與不一致的模板，很多團隊可能忽略或未能有效執行。為了改變這一現狀，我們可以通過以下方法來提升 SecAC 的效率：

• 簡化模板：制定統一且簡潔的 SecAC 模板，減少不必要的細節，明確標注哪些卡片需要添加 SecAC，以及如何快速生成合適的安全準則。
• 智能提示：在任務卡的創建流程中，根據已經總結的模版或者知識庫自動化的添加安全檢查和建議。如果該卡片涉及到任何潛在的安全威脅，系統能夠提示并生成相應的安全需求，從而降低人工判斷的負擔。
• AI輔助生成SecAC：隨著人工智能技術的發展，AI 在提升 SecAC 編寫效率方面具備巨大的潛力。例如，Thoughtworks 推出的 AI 工具 Haiven 可以根據項目的特點和卡片的內容，自動識別出其中的安全風險，并生成相應的 SecAC。這不僅大大提高了開發團隊在日常開發中的安全意識，也減少了人力投入，確保了更多的卡片能夠達成安全要求。

2. 整合團隊反饋與案例

此外，及時獲取團隊的反饋也是提高 SecAC 使用效率的一個重要方面。團隊成員在實踐中不斷遇到不同的挑戰和需求，通過定期收集反饋并根據實際案例進行改進，能夠幫助團隊優化 SecAC 的適用性。可以通過以下方式增強反饋機制：

• 安全案例庫：建立一個共享的安全案例庫，其中包括以往項目中成功應用 SecAC 的實例，以及失敗案例的教訓。這能夠幫助團隊成員更好地理解如何在具體的開發卡片中有效應用 SecAC。
• 定期培訓與回顧：定期為團隊舉辦關于 SecAC 的培訓與回顧會議，分享最佳實踐，討論團隊在實施過程中的困惑和難點，從而不斷完善整個流程。

3. 鼓勵文化轉變：安全作為每個人的責任

除了技術層面的改進，文化層面的轉變同樣至關重要。安全不應僅僅由安全專家負責，而應當是每個開發者和團隊成員的共同責任。通過以下方式，可以推動團隊文化的轉變，進一步提升 SecAC 的有效性：

• 安全冠軍（Security Champion） 的引導：團隊的安全冠軍可以通過定期檢查 SecAC 的應用情況，強調其在項目中的重要性，并對未能執行的團隊成員進行指導與幫助。
• 激勵機制：對那些積極執行 SecAC、主動識別安全風險并提供改進建議的團隊成員，給予獎勵或表彰，激勵團隊文化的變革。

通過文化與技術手段的雙管齊下，SecAC 的應用將會變得更加高效、更加普及，最終使得整個開發過程中的安全性得到了進一步的提升。

六、小結

通過本文的分析，我們可以看到構建安全內建并不是一項單純的技術工作，而是需要通過合理的威脅分類、精細的策略落實和文化引導來推動的。通過四象限分類模型和SecAC等方法，團隊可以更加高效地識別和應對軟件開發中的安全威脅，同時通過引入 AI 技術提高 SecAC 編寫效率，確保交付物的安全能夠在每個開發環節中得以保障，從而構建起一個更安全、更高效的開發環境。