資安和合規團隊的人非常辛苦，除了對公司和客户資料的安全性要負責之外，他們還要遵守適當的法規及標準，還需要讓驗證合規性的稽核人員滿意。
但，重要的是他們幾乎無法控制他們所負責保護的投資組合中存在的風險及漏洞。
如今，在雲端基礎設施正在通過Terraform、Kubernetes或Helm Charts等技術以編程方式定義（通過Infrastructure as Code (IaC）），並且在這個過程中經常引入一些錯誤配置。在SDLC(Software Development Life Cycle)的這一個關鍵點上，如果不去解決問題，不僅再一次累積了安全技術債務，而且如果由於錯誤的設定而出現漏洞，整個企業及其客戶資料可能會留機會給威脅攻擊者去獲取。
資安團隊識別風險，開發團隊修復風險
在大多情況下漏洞是由開發人員引入的，而開發人員則是透過實施代碼更改來消除漏洞。當資安團隊發現需要修復的漏洞時，他們首先需要說服開發人員:
(a) 這的確是一個漏洞
(b) 確實是需要修復
(c) 確實需要現在盡快修復。
然而，他們可能需要協助如何用最好的方式去修復它們，因為開發人員並不是資安的專家。所以這存在著大量的工作，是來自於許多潛在的漏洞。難怪被累積的工作量成長的速度快於問題修復的速度—而且在大多企業中，資安團隊甚至未評估所有版本。更何況在這個過程中資安與開發團隊產生的衝突太多。
很許多人將DevSecOps作為此問題的解決方案：將資安專家或資安專業知識嵌入開發團隊，以便提早及更頻繁的發現和修復問題。這的確是個好的方法: DevOps取得了令人振奮的成功，因此將相同的方法應用於安全性是有意義的。
如果我們指定一項變革作為MVP，使得DevOps能否在雲端團隊中發揮作用，那麼我認為基礎架構即代碼(Infrastructure as Code, IaC) 就是最佳的選擇。
在傳統的操作主要是手動的或者是半自動的，需要很長的準備時間和大量的一次性的工作。
虛擬化顯然有助於改善這一點，但資源調配通常需要幾天或幾週的時間，而且顯然無法包含在自動流程中。
IaC完全改變了原有的思維，它使DevOps團隊能夠準確的在代碼中描述他們要什麼。根據需求自動提供(或取消提供)基礎設施，他們可以利用它的可靠性、可預測性、可伸縮性、彈性和治理的新的準則幫Terraform和Kubernetes等開發工具打開一個新的大門。
Security as Code 使開發團隊能否主動解決資安問題
安全團隊正面臨許多相同類型的問題。安全評估通常需要數天或數週的時間，而威脅模擬、評估、分類和優先級排序等安全流程需要大量手動以及臨時工作。
將這種“as Code”方法擴展到安全性可能有助於實現許多的好處。
借助Security as Code，DevSecOps 團隊可以在代碼中準確描述他們需要實踐的安全和合規目標。
假設可以使用類似於 IaC 所用代碼工具的安全性，團隊可以利用這些工具在整個開發過程中強制遵守編碼目標，確保持續合規並在部署應用程序之前消除所有有意義的重大安全風險。編碼的目標甚至可以跟隨應用程式進入運作環境，以便在運作型態中也必須強制執行這些安全規則。
Security as Code可自動實踐安全策略並確定修復工作的優先順序
安全團隊所面臨的挑戰是構建或尋找可以有效地將手動步驟轉換為自動化步驟的工具。其中最困難的可能是發現的分類和優先級排序，因為它們需要對系統架構有深入的了解，以確定哪些發現是可利用的，哪些發現會曝露給不受信任的用戶，哪些可以訪問敏感資料等等。
但這不正是 IaC 所提供的嗎？了解系統拓樸、資源和關係，從中我們可以推斷出在 Internet 上向不受信任的用戶公開的內容；我們可以確定哪些資源可以訪問敏感資料儲存；我們可以計算進入架構的潛在攻擊路徑。
Security as Code解決開發和運行狀態的風險
有了這些訊息，工具可以自動確定結果的優先順序，並將注意力集中在那些可被利用且必須修復的問題上。他們可以在Pipeline編排中自動化設定通過/失敗條件，例如，只有當Images包含暴露敏感資料的高風險被發現時才中斷構建。他們不再需要用懷疑發現來打擾開發團隊；當他們發出警報時，根據定義，這些問題是可被利用的並且必須修復。這種類型的工具可以有效地整合到自動化 DevSecOps 工作流程中，而不必擔心會影響開發效率。
隨著代碼的安全性越來越受到關注，期待看到許多新的方法和改進。特別適合像 GitOps 這樣的方法，它已經利用了大量基於編碼基礎設施和部署訊息的自動化。
Security as Code可以增強這些自動化工作流程，以確保安全風險在暴露給用戶之前被阻斷。
本文轉載自創泓科技。