在設計階段將安全性納入功能中

不同學科的融合能使流程更高效，這是令人振奮的。在2009年，DevOps一詞被創造出來，以解決開發團隊與運營團隊之間的摩擦。因此，業界開始將兩個團隊結合在一起，使開發團隊負責整個周期，從編寫代碼到生產部署。當然，誰能比開發人員更了解其複雜性呢？

在這次轉變後，我們看到功能快速交付，新功能的上市時間也迅速縮短。DevOps也成為了許多其他實踐的基礎，如MLOps、DataOps、GitOps，無疑還有許多其他實踐隨之出現。

今天我們將談論一種許多人可能熟悉的實踐，稱為DevSecOps（開發安全運營）。那麼，DevSecOps是什麼呢？

安全傳統上被視為事後考慮，團隊首先將功能交付到生產環境，然後在安全審查或事件中匆忙部署安全修復。隨著網絡安全、供應鏈及其他複雜攻擊的激增，業界迅速意識到，與開發和運營一樣，安全也應該成為流程的一部分。它應該儘早嵌入到開發生命周期中，因為稍後處理安全問題可能會非常昂貴（無論是從架構還是運營的角度）。

現在，讓我們討論如何在我們的開發生命週期的各個階段應用它，以便我們運送的代碼不僅高效而且安全。

通常，運送一個功能的過程包括：

1. 開發 – 這是功能 被構建
2. 分發 – 這是工件被創建並準備交付的過程
3. 部署 – 這是功能 被釋放 到生產環境中的過程

讓我們討論在開發階段可以採取的步驟，以增強我們正在構建的功能的安全姿態。

在開發階段，功能經過設計審查、編碼，然後是拉取請求審查。作為設計審查的一部分，功能擁有者討論API合約的樣子、我們使用的數據庫類型、索引、緩存策略、用戶體驗等等（這不是一個詳盡的列表）。在以安全為先的文化中，進行威脅建模也是很重要的。

執行威脅建模

簡單地說，威脅建模 是指“識別漏洞、進行風險評估並實施建議的緩解措施，以確保產品/組織的安全狀態不會受到威脅。”

讓我們通過一個例子來理解這個概念。假設你正在開發一個API，該API可以：

• 列出產品目錄中的產品。
• 搜索產品或產品類型。

GET /api/products?search=laptop

​

威脅模型可能如下所示：

在查看產品端點時，這是我們可以考慮的事情。最好的部分是，您無需成為安全專家即可識別這些漏洞。像Microsoft威脅建模工具和OWASP威脅龍等工具可以幫助識別它們。

像Microsoft威脅建模工具和OWASP威脅龍等工具可以幫助識別它們。

Microsoft威脅建模工具中的威脅模型示例

分析視圖

威脅建模工具的分析視圖顯示了API可能發生的不同攻擊。

與團隊審查威脅模型可以作為一個頭腦風暴會議，以識別並盡可能化解許多安全漏洞。

• 弱加密使用。例如，使用SHA1或MD5被視為弱加密。CA530 是C#在代碼中使用任何弱哈希函數時創建的警告示例。
• SQL注入攻擊。 CA2100 是檢查代碼是否容易受到任何注入攻擊的示例
• 硬編碼 密碼、弱身份驗證和授權機制，以及 基礎設施錯誤配置 也可以通過靜態分析工具檢測到。

在這個領域也有一些現有的工具。SonarQube、CodeQL、Roslyn Analyzer、OWASP Dependency Check和 Snyk在這方面提供了一些優秀的解決方案。

將靜態分析整合到構建流程中也非常重要。它帶來的好處包括：

• 為您的開發人員提供一致的漏洞檢測體驗。
• 提高 服務的安全性，因為每次生產部署都必須經過這些步驟。

從安全角度進行程式碼審查

傳統上，程式碼審查主要集中在識別錯誤並確保最佳實踐，但從安全角度來評估它也非常重要。通過考慮每個拉取請求的安全影響，您可以主動預防未來的威脅，保護應用程式的完整性。 。 

結論

總結來說，隨著網絡安全環境的日益複雜，考慮安全性在早期階段是非常重要的，而不是將其留到最後。作為這一部分，將威脅建模和自動靜態分析納入開發 的常規循環中。在即將發布的文章中，我們將討論在分發過程中可以納入的安全實踐，這包括掃描容器映像、動態應用程序安全測試 (DAST) 和工件簽名，以保護服務免受供應鏈攻擊。