探索關鍵驗證點

已完成

從開發到生產的每個步驟都應整合持續安全驗證,以確保應用程式在其整個生命週期中保持安全。 這種方法改變了安全團隊與開發互動的方式,從手動批准每個版本轉變為對整個 CI/CD 流程的持續監控和審計。

改變安全對話的方式

傳統方法: 安全性小組會手動檢閱並核准每個版本,然後才能繼續生產。 這會產生瓶頸、延遲發行,而且無法隨著新式部署頻率進行調整。

安全的 DevOps 方法: 安全團隊同意 CI/CD 程序本身,而不是個別版本。 他們定義安全要求、實施自動化驗證並持續監控流程。 安全性變得整合,而不再是一個單獨的關卡。

這種轉變的好處:

  • 當發行符合安全準則時,會自動進行。
  • 安全團隊專注於改進流程,而不是審查個別變更。
  • 安全性驗證可擴展,以支援每天多個部署。
  • 稽核追蹤會自動記錄安全性驗證。
  • 安全性問題會立即偵測到,而不是在檢閱時偵測到。

管線中的重要驗證點

下圖醒目提示 CI/CD 管線中的關鍵驗證點,用於從頭開始建置應用程式:

流程圖顯示跨 IDE、提取要求、持續整合、開發環境和測試階段的安全驗證點。

逐步實施: 您可以根據平台和應用程式的生命週期階段逐步實施安全驗證工具。 如果您的產品已成熟,且您先前未針對網站或應用程式執行安全性驗證,則此分階段方法尤其重要。 一次引入所有安全檢查可能會因結果而讓團隊不知所措。

優先排序策略: 在現有應用程式中實作安全性驗證時:

  1. 從最關鍵的安全檢查(秘密檢測、已知漏洞)開始。
  2. 首先處理高風險領域的調查結果。
  3. 逐步將覆蓋範圍擴大到額外的安全檢查。
  4. 在新增更多檢查之前,調整工具以減少誤報。
  5. 透過展示安全自動化的價值來建立開發人員信任。

IDE 和提取要求驗證

安全性驗證會在開發人員將其程式碼提交至共用存放庫之前開始。 這種「左移」方法可以在最容易且成本最低的情況下儘早發現問題。

IDE 層級安全性檢查

IDE中的靜態程式碼分析: 整合到 IDE 中的靜態程式碼分析工具提供第一道防線,以確保不會將安全性弱點引入 CI/CD 程式。

即時回饋: 開發人員在編寫程式碼時會立即收到有關安全問題的回饋:

  • 安全性弱點會直接在程式碼編輯器中醒目提示。
  • 當開發人員輸入時,安全編碼做法的建議會即時顯示。
  • 只需單擊一下即可快速修復常見安全問題。
  • 說明可協助開發人員瞭解某些模式有問題的原因。

IDE 安全工具範例:

  • Visual Studio Code 安全性延伸模組: Snyk、SonarLint 和 GitHub Copilot 等擴充功能在編碼時提供安全指導。
  • IntelliJ IDEA 安全插件: 注重安全的插件實時分析代碼。
  • Visual Studio 安全性分析器: 內建分析器可在開發期間偵測安全性問題。

IDE 級檢查的好處:

  • 問題是在編寫程式碼時發現的,而不是幾天或幾週後。
  • 開發人員透過即時回饋來學習安全編碼實踐。
  • 在提交程式碼之前修復了安全性問題,從而減少了管道故障。
  • 反饋循環以秒為單位,而不是小時或天。

存放庫提交控制

防止易受攻擊的程式碼進入程式碼庫: 將程式碼提交到中央儲存庫的程式應該具有防止引入安全性弱點的控制項。

Git 分支策略: 在 Azure DevOps、GitHub 或類似平臺搭配分支原則中使用 Git 原始檔控制,可提供強制執行安全性驗證的閘道認可體驗:

分支保護強制執行:在共用分支 (例如 main 或 develop) 上啟用分支原則,需要提取要求才能開始合併程序。 直接提交到受保護的分支會被阻止,確保所有程式碼變更都通過驗證過程。

拉取請求要求: 拉取請求應強制執行數個與安全性相關的要求:

程式碼審查要求:

  • 至少一個其他開發人員必須審查程式碼變更。
  • 這種手動審查對於識別自動化工具可能遺漏的安全問題至關重要。
  • 檢閱者應特別尋找安全性問題,包括:
    • 正確的輸入驗證。
    • 適當的身份驗證和授權檢查。
    • 安全處理敏感資料。
    • 正確使用安全庫和框架。
    • 缺乏硬編碼的秘密或憑證。

工作項目連結:

  • 提交應該連結至工作項目(案例、工作、錯誤) 以進行稽核。
  • 此連結會記錄進行程式碼變更的原因。
  • 稽核追蹤可協助安全小組在事件調查期間瞭解變更的內容。
  • 從需求到部署的過程,連結工作專案可實現可追蹤性。

持續整合 (CI) 建置需求:

  • CI 建置程序必須先成功,才能合併提取要求。
  • CI 組建包含自動化安全性檢查 (下一節所述)。
  • 未通過的安全檢查會阻止合併,防止易受攻擊的程式碼進入主分支。
  • 建置結果會顯示在提取要求中,為檢閱者提供安全性內容。

狀態檢查:

  • 外部安全性工具可以報告有關提取要求的狀態檢查。
  • 合併之前必須通過所有必要的狀態檢查。
  • 安全性小組可以新增必要的檢查,而不需要修改管線定義。

分支策略配置示例:

在 Azure DevOps 或 GitHub 中,分支原則可能需要:

  • 至少 1 名審核者同意(關鍵分支需 2 名)。
  • 連結的工作項目可用於所有變更。
  • 建置驗證成功。
  • 所有評論已於合併前解決。
  • 最新的分支(在合併之前必須包含最新的變更)。
  • 通過由安全性工具進行的必要狀態檢查。

提取請求驗證的好處:

  • 在程式碼進入共用程式碼庫之前,會進行安全性檢查。
  • 多個觀點審查程式碼中的安全性問題。
  • 稽核記錄會記錄批核具有潛在風險的變更的人員。
  • 開發人員會在其正常工作流程中收到安全性意見反應。
  • 團隊透過程式碼審查建立安全意識文化。

提取請求中的自動安全檢查:

提取請求可以觸發自動化安全分析:

  • 靜態分析: 掃描程式碼是否有安全漏洞。
  • 相依性檢查: 系統會檢查新的或更新的相依性是否有已知弱點。
  • 袐密偵測:掃描會偵測意外提交的認證。
  • 程式碼品質檢查: 分析可識別可能導致安全問題的程式碼品質問題。

結果直接顯示在提取請求介面中,允許檢閱者和作者在合併之前解決問題。