DevOps大牛Gene Kim給出了自己對當前DevSecOps程序、以及開發團隊在未來如何改進這些程序的一些看法。

象一下這個場景：產品負責人、開發人員、QA團隊、IT運營和資訊保安人員一起工作，他們不僅互相幫助而且還確保整個組織機構的成功。他們朝著同一個目標邁進，將計劃的工作快速轉換為成果（例如每天部署數十行、數百行甚至是數千行程式碼），同時實現一流的穩定性、可靠性、可用性以及安全性。

在這個世界上，資訊保安人員一直都在致力於減少團隊的摩擦並創造能讓開發人員效率提高且輸出更好成果的工作體系。藉此，小型團隊不僅能夠充分利用資訊保安團隊的集體經驗和知識，還能利用QA和運營的集體經驗和知識，從而在日常工作中不必依賴於其它團隊就能夠安全快速地部署到生產中。

這樣，組織機構就能夠建立一種安全的工作體系，小型團隊能夠快速獨立地進行開發、測試，並快速安全可靠地為消費者部署程式碼和價值。如此，組織機構就能最大化開發人員的生產能力、為組織級學習賦能、實現員工高滿意度並在市場競爭中獲勝。

我們並非是在程序結束時將安全注入到產品中，而是會建立安全控制並整合到日常開發和運營工作中，於是安全就成為每個人每日工作內容的一部分。

對DevOps的一種闡釋是它源自提高開發人員生產力的需求，因為隨著開發人員人數的增長，處理部署工作的運營人員出現人手不夠的情況。

一般技術企業的開發、運維和資訊保安工程師的比率是100:10:1。當資訊保安人員跟其他工程師在數量上的懸殊如此大時，如果沒有將自動化且沒有將資訊保安整合到開發和運營的日常工作中，那麼資訊保安人員只能做合規檢測工作，但它跟安全工程的目標相反；另外，它還會招來人們的恨意。

開始行動

1. 將安全融入到開發迭代演示中

這裡有一種簡單方法能阻止資訊保安人員成為專案行將結束時的攔路虎：在每個開發間隔結束時邀請資訊保安人員參加產品演示活動。它有助於人人都理解跟組織機構目標有關聯的團隊目標、在構建過程中看到它們的實現、並且有機會提供所需輸入以滿足安全和合規目標，同時有足夠的更正時間。

2. 確保安全工作包含於開發和運營的工作追蹤系統中

資訊保安工作應該跟其它工作一樣可見於價值流。我們可在開發和運營人員日常使用的工作追蹤系統中追蹤資訊保安工作，以此跟其它工作區分優先順序。

3. 將資訊保安整合到無可非議的事後剖析過程中

另外，在每次發生安全問題後做一個事後剖析以避免再次出錯。在2012年舉辦的奧斯丁開發運維日(Austin DevOpsDays) 活動的演講中，多年來在Etsy資訊保安公司擔任主管一職的NickGalbreth說明了他們對待安全問題的方式，“我們將所有的安全問題都放到所有工程師在日常工作中都會使用的JIRA工具中，這些問題要麼是P1級別要麼是P2級別，也就是說必須立即解決或者在本週末解決，即使只是個供內部使用的應用程式也不例外。”

4. 將預防性安全控制整合到共享原始碼庫和共享服務中

共享原始碼庫是激發人人發現並複用組織機構集體知識的良好途徑，不僅對於程式碼而言是如此，對於工具鏈、部署流水線、標準以及安全來講也是如此。安全資訊應該包括保護應用程式和環境的任何機制或工具，如為實現具體目標而受安全保護的庫。另外，將安全工具增加到開發和運營人員日常使用的版本控制系統中能讓他們時時刻刻注意到安全需求。

5. 將安全整合到部署流水線中

為了讓資訊保安始終成為開發和運營頭等考慮的事情，我們想繼續快速反饋跟他們程式碼相關的潛在風險。將安全整合到流水線中涉及將盡可能多的安全測試自動化，這樣它們就能跟其它自動測試一起執行。在理想情況下，開發或運營團隊提交的每行程式碼都應該執行這些測試，即使在軟體專案的最早階段也是如此。

6. 保護部署流水線免受惡意程式碼影響

遺憾的是，惡意程式碼可被注入到支援CI/CD的基礎設施中。隱藏惡意程式碼的一個好地方是單元測試，因為沒有人會檢視這些測試而且一旦有人將程式碼提交到庫中，這些測試就會執行。我們能夠（而且必須）通過以下步驟保護部署流水線，如：

• 強化持續構建和整合伺服器，以便自動復現它們。
• 檢視版本控制中引入的所有變化，阻止持續整合伺服器執行不受控的程式碼。
• 測試庫以檢測測試程式碼何時包含可疑的API呼叫。

7. 保護應用程式的安全

開發測試通常關注的是功能的改正。然而，資訊保安關注的通常是測試可能出錯的地方。資訊保安並不是手動執行測試，而是將它們生成自動化單元或功能測試的一部分，這樣就能在部署流水線中持續執行。定義設計模式幫助開發人員寫程式碼以阻止濫用也起著重要作用，比如為服務設定速率限制並在按下提交按鈕後將其灰度化。

8. 保護軟體供應鏈的安全

僅僅保護應用程式、環境、資料和流水線的安全並不夠，我們還必須確保軟體供應鏈的安全，尤其是在有讓人驚訝的資料（見Sonatype釋出的2015年《軟體供應鏈狀態》報告以及Verizon釋出的2014年《資料洩露調查報告》）顯示軟體供應鏈易受攻擊的情況下。雖然使用並依賴商業和開源元件很方便，但同時也極具風險。選擇軟體時，檢測具有已知漏洞的元件或庫並跟開發人員一起仔細選擇具有快速修復追蹤記錄的元件十分重要。

9. 保護環境的安全

我們必須確保我們的環境處於一種經強化且降低風險的狀態。這涉及生成自動化測試以確保所有的恰當設定都已正確應用於配置強化、資料庫安全、金鑰長度等。它還涉及通過測試掃描環境中存在的已知漏洞，並使用安全掃描器予以識別。

10. 將資訊保安整合到生產測量中

通常，內部安全控制在快速檢測安全事件中並不起作用，因為在監控中存在盲點或者沒有人每天在檢測相關的測量情況。為此要將安全測量整合到開發、QA和運營所使用的同樣工具中。這樣流水線上的每個人都能看到應用程式和環境是如何在存在威脅的環境中表現的。在這種威脅環境中，攻擊者不斷嘗試利用漏洞、獲取未經授權的訪問許可權、植入後門並實施欺詐行為（等等）。

[本文節選自《開發運維手冊》(The DevOps Handbook)。]

本文由360程式碼衛士團隊翻譯，360程式碼衛士微信公眾號：“codesafe”