【51CTO.com快譯】現如今，盡管各種駭人聽聞的網絡攻擊事件已是各類新聞頭條的“常客”了，但是大多數企業仍會在其IT環境的搭建之初就忽略了、或錯誤地實施了安全管控。

而對于一些初創型企業及其新建的IT系統而言，它們時常會將有限的資金花費在無關的資產、或流程的保護之上。根據Verizon 2018年度數據泄露調查報告顯示，在一般企業的系統中，有40%的漏洞會出現在應用層。而他們花費在保護應用程序上的年度安全預算，卻只有3%～4%。

與此同時，一般企業的IT部門在人員崗位分配上也存在著不均衡的現象，時常會出現100名開發人員僅配備了一位安全技術專家的狀況。而這些孤獨的安全人員，往往不得不疲于提供瀑布式的安全策略與實踐，以趕上整個研發團隊的敏捷開發節奏。因此，當他們根據安全檢查表中的不達標項，叫停某些應用編碼工作、進而導致延遲產生的時候，都將被視為是對公司當前項目推進的阻礙、內部生產效率的破壞、甚至是對整體文化的“毒害”。

在現實情況中，如果您沒有在整個軟件交付的管道中實施安全流程管控的話，那么您必將面臨著各種組件的延遲交付或風險發布，而且這些組件往往會帶有潛在的漏洞。不過，這恰好是DevSecOps能夠發揮作用的地方。它通過各種安全實踐，來最小化軟件交付管道中的各種脆弱性，為組織的IT和業務的目標保駕護航。

在XebiaLabs公司(譯者注：一家獨立的軟件公司，專注于為大型組織開發企業級的持續交付與DevOps軟件)最近組織的一次網絡研討會上，來自Signal Sciences的研究主管--James Wickett，與DevOps思想領袖--Gene Kim，以及XebiaLabs的首席產品官(CPO)--Rob Stroud，討論了如何將安全性接入到整個DevOps生命周期中的三項原則。

您除了可以通過鏈接：https://xebialabs.com/community/webinars/devsecops-missing-link-of-business-velocity/，來收聽該網絡研討會的現場錄音之外，還可以通過如下文字閱讀有關DevSecOps的三項核心原則。

原則1：為最壞的場景做好設計

為了將安全性盡量“左移”(指各項流程管道的初始階段)，獲取開發部門的理解與支持是非常重要的。為了實現該目標，各個企業需要幫助研發人員了解到，在他們的應用程序中可能存在的威脅與漏洞，并需要有針對性的進行各種計劃與設計。Wickett建議采用如下四種方式：

• 艙壁模式(Bulkhead Patterns)-- 以一種分割應用程序之間依賴性的方式，來設計您的程序代碼。這是一種“未雨綢繆”的設計理念。如果您能夠隔離應用程序中的各個組件，那么縱然某一個組件出現了故障，而其他組件仍然可以運行并提供服務。Wickett說，該模式的典型應用案例就是針對微服務的引入。您會很自然地借用艙壁的理念，將大的整塊服務分割成多個小的單功能服務。雖然這是一種絕佳的安全實踐，不過我們也需要在企業環境中事先考慮到微服務的擴展限制問題。
• 惡意用戶場景(Evil User Stories) -- 您可以通過描述用戶如何破壞系統的安全性，來提醒敏捷開發團隊，在他們編寫最終產品代碼時限制惡意用戶的各種可能行為。例如他們可以這樣制定代碼的邏輯：如果有用戶在訪問某個網站時，試圖進行跨站點腳本注入攻擊，那么就直接拒絕其任何操作行為。Wickett說，那些具有高安全性的組織，通常會使用各種既定的語言、模式和測試框架，來描述不同的用戶場景，并以此融入現有的敏捷開發企業文化之中，使之成為可接受的系統的一部分。
• 威脅建模(Threat modeling) -- 在軟件開發的過程中，您可以使用威脅模型來說明應用程序在運行時所涉及到的組件，并識別出這些組件可能面臨的潛在風險，進而選取最好的防護措施。威脅建模對于那些缺乏安全專家人手的環境是至關重要的。同時，通過提供一些具有針對性的風險管控模型，安全人員會更容易實現與研發部門的溝通，并達成共識。
• 風險評估(Risk Assessments) -- 您可以將基于風險的評估方法運用到自己的環境中，以確定哪些給定的措施更適合于自己的用例環境。這將有助于開發人員通過提供參數輸入的方式，將評估集成到應用的設計與實施階段，并貫穿整個項目的生命周期。

原則2：安全測試貫穿整個管道

一般而言，針對軟件交付管道的全面安全加固，就意味著：在應用程序的整個生命周期，對每一個組件和階段，都采取漏洞測試。您可以采用如下的方法測試軟件交付管道的安全性。

• 逆境測試(Adversity Testing) -- 您可以通過各種“實戰性”的攻擊工具，對自己的管道進行注入攻擊，以找出不同的安全漏洞。Wickett推薦下載的工具包括：Metasploit(https://www.metasploit.com/)、Nikto(https://cirt.net/Nikto2)和Arachni(http://www.arachni-scanner.com/)。安全人員通過利用它們來對某個網站進行測試，以找出那些薄弱的環節。這些測試的目的都是為了獲悉您系統環境中的漏洞，以及整體抗攻擊的能力。
• 安全即代碼(Security-as-Code) -- 類似于基礎設施即代碼(infrastructure-as-code, https://xebialabs.com/glossary/infrastructure-as-code/)，安全即代碼是將各種安全模式集成到代碼系統之中，成為一個自動化的流程部分。由于它能夠更多地將開發人員帶入安全相關的流程中，因此安全即代碼是企業塑造DevSecOps文化的重要組成部分。
• 漏洞測試(Vulnerability Testing) -- 通常情況下，我們會用不同的方法對應用程序進行漏洞測試。其中包括：
  • 靜態應用程序安全測試(SAST)，提供了一套檢測應用程序代碼漏洞的工具集。
  • 動態應用程序安全測試(DAST)，是采用外部攻擊，來測試應用程序的運行狀態的一種方法。
  • 交互式應用程序安全測試(IAST)，是在測試階段分析應用程序的行為，以幫助開發者對所發現的漏洞進行優先級排序的一種方法。

原則3：摒棄只重視AppSec培訓的謬誤

在過去十年間，整個行業都過于重視培訓開發人員編出具有安全性的代碼。雖然AppSec培訓非常重要，而且其各種最佳實踐能夠提高企業的整體安全意識，但是它也會帶來一些其他問題。對于一些新手程序員而言，只要是用人工編寫代碼的方式，就可能會帶有漏洞。因此我們不應盲目地認為他們所開發的代碼，足以讓其應用程序固若金湯。同時，接受過AppSec培訓的研發人員，會更具備“全棧”的開發能力，當然更容易被其他公司所“挖”走。

因此，我們不能只專注于開發人員是否能編寫出更為安全的代碼，而應該盡可能地將各種流程自動化，并放置到軟件交付管道的左側(初始階段)，同時在右側(管道的末端)增設各種與安全相關的監測工具。另外，我們應當盡量通過一套部署管理系統，來強制實施各項自動化的進程，以保證代碼在最終發布階段的安全性。

安全性和敏捷性并重

對于一般企業而言，將不同職能部門的團隊組織起來，通過DevOps的協作方式，在規定時間內交付出軟件產品是極具挑戰性的。我們時常會看到一些實施了DevOps的企業，他們的團隊雖然實現了在軟件產品交付上的“提速”，卻無法讓產品達到相應的安全水準。因此，如果您在軟件持續交付的過程中忽略了安全性的保障的話，那么您最后將會失去客戶的信任，也沒有人愿意、或敢去使用您的軟件產品。

原文標題：Delivering Security and Speed: The 3 Core Principles of DevSecOps ，作者：Tim Buntel

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】