DevSecOps-回應式模型

DevSecOps 透過在安全和其他業務部門之間培養共生關係，從本質上打破了企業安全的穀倉，並透過在 DevOps 實踐中添加安全特定技術和工具集來提高產品品質和交付速度。

DevSecOps也是一種文化和工程實踐，使用自動化來打破開發、安全和維運團隊之間的障礙並進行開放式協作，專注於快速、頻繁地將安全基礎設施和軟體交付到生產環境中。 它涵蓋軟體的獲取和發布，並以可預測、透明的方式管理這些流程，且無需人為干預(花精力)。

對甚麼東西回應

模型需要能夠:

• 當事情發生變化時能夠適應：法規、威脅、財務。
• 成為安全和工程團隊之間持續對話的基礎
• 輕鬆快速地進行變更
• 記錄自己的變更流程

回應甚麼?

模型需要測量這些組件的適合度：

• 每個服務或應用程式都會套用和衡量多個標準
• 風險管理必須透過持續驗證來完成，而不是由單次會議來驅動
• 為此，請衡量 CI/CD 流水線中的各項作業
• 遵循 DevSecOps 實踐：
  — 實施Security as Code
  — 利用自動化
  — 儘早加上稽核與合規

模型會產出甚麼?

KPI — 每個服務的合規度(%)以及可稽核性。
甚麼是KPI?KPI 是一個可衡量的數值，用來呈現公司實現關鍵業務目標的效率。 組織使用多個層級的 KPI 來評估其是否成功實現目標。

• 適合度衡量標準需要為每個價值流的標準提供 KPI
• 產出和價值需要與稽核流程的能力直接相關，即 ITSM 和變更管理整合（設計資料流）
• 將技術和流程對映到核心安全維運
• 自動將發現結果記錄到問題管理中，以減少安全團隊和開發團隊之間的瓶頸

KPI範例

風險與品質需要被量測

• 量測”整合和產出”作為輸入以實現"持續驗證"
• "管理風險"的能力和"該措施的產出"是兩個獨立的 KPI
• "整合和產出"之間的差距用於建立積壓的作業

新與舊的運作模型

上圖我們可以看到新舊安全模型之間的比較。採用工程原理有助於從規定標準的傳統安全模型轉變為與價值流保持一致並與 CI/CD 流水線整合，其效果將扭轉安全拖慢開發的事實。結果將是一個模型，用於在原則等級上持續測量/設定我們的安全適應性。

哪我們如何量測模型和追蹤什麼以及它如何運作呢？我們可以以BCP plan為例。

變更管理重新設計

新的營運模式需要整合的變更管理和Ticket tracking

• 持續安全狀態的檢查
• SAST可以驗證持續整合實踐
• 使用產出來更新Ticket

我們需要重新設計變更管理:

1. 流水線審核階段追蹤已使用代碼的狀態和變更
2. 當一致性達到 100% 時，取消紙上審核階段
3. 變更管理會根據 KPI 進行調整

流水線階段

KPI需要定義與視覺化:

• KPI 按價值流、流水線或應用程式驅動
• 這些數值代表了標準的採用
• 每個 SDLC 階段的閾值(Threshold)和門控(Gate)能力
• 產出不是整合而是應該驅動待辦事項和審核狀態

美國聯邦總務暑的DevSecOps成熟度模型，其目標是:更快更好的軟體。

產出

建立模型的步驟

1. 離開會議的形式：要求定義和記錄"標準和價值"的測量。 這也可以採用流水線即代碼( piple-as-code)範例的形式
2. 開發中提醒，生產中保護。SDLC 的每個階段都定義了不同的容差(tolerances)來支援左移。 開發和生產環境並不相同。
3. 提供用於整合和採用量測技術的工件
4. 不篩選：一旦量測開始，資料一開始一定很難看。 目標是增量以追蹤每個時間區間所需的改進增量。
5. 定義並建立可追蹤的異常處理流程。 大多數事件的一致性。，對少數事件的回應。 這可以防止強制讓未追蹤的異常現形。
6. 標記並對映每個應用程式的價值，以視覺化每個治理工程標準的 KPI。 每個 BU 也可以聚合以實現更高層級的可視化。 重要的 KPI 是一致性增量。 而不是起始價值。
7. 不斷更新我們的標準和期望值。 更新Pipeline-as-code以支援範例的推進。 沒有人可以達到 100%。 推進標準，全部下移再推進。

Gartner對DevSecOps的視角

OWASP對DevSecOps的視角