原文：http://securosis.com/blog/enterprise-devsecops-new-series轉(zhuǎn)自：https://www.4hou.com/ 嘶吼ROARTALK
本文譯自Securosis網(wǎng)站Adrian Lane的系列博客文章，內(nèi)容包括：?
- 安全人員如何與開(kāi)發(fā)協(xié)同工作
DevOps 是一個(gè)操作框架，通過(guò)自動(dòng)化來(lái)促進(jìn)軟件的一致性和標(biāo)準(zhǔn)化。通過(guò)打破不同開(kāi)發(fā)團(tuán)隊(duì)之間的障礙，同時(shí)通過(guò)優(yōu)先考慮使軟件開(kāi)發(fā)更快更容易的事情，該框架幫助解決了圍繞集成、測(cè)試、打包和部署的許多噩夢(mèng)般的開(kāi)發(fā)問(wèn)題。DevSecOps是將安全團(tuán)隊(duì)和安全工具直接集成到軟件開(kāi)發(fā)生命周期中，利用 DevOps 的自動(dòng)化和效率，確保每個(gè)構(gòu)建周期都進(jìn)行應(yīng)用程序安全測(cè)試。這促進(jìn)了安全性、一致性，并確保安全性與其他質(zhì)量指標(biāo)或特性同樣重要。自動(dòng)化的安全性測(cè)試，就像自動(dòng)化的應(yīng)用程序構(gòu)建和部署一樣，必須與基礎(chǔ)設(shè)施的其余部分一起組裝。但這就是問(wèn)題所在。軟件開(kāi)發(fā)人員傳統(tǒng)上并不支持安全性。這并不是因?yàn)樗麄儾魂P(guān)心安全問(wèn)題，而是因?yàn)樗麄儽还膭?lì)去關(guān)注新特性和功能的交付。DevOps 正在改變自動(dòng)化構(gòu)建過(guò)程的優(yōu)先級(jí)，使它們更快、更簡(jiǎn)單并且更一致。但是，這并不意味著他們會(huì)特意加入安全或安全工具。這是因?yàn)榘踩ぞ卟蝗菀着c開(kāi)發(fā)工具和流程很好地集成，我們經(jīng)常會(huì)發(fā)現(xiàn)大量隊(duì)列堆積，并且以開(kāi)發(fā)為中心的過(guò)濾器難以幫助優(yōu)先安全工作。更糟糕的是，安全平臺(tái)——以及推薦它們的安全專業(yè)人員——很難使用，甚至無(wú)法提供 API 支持來(lái)提供集成。另一方面在于安全團(tuán)隊(duì)，他們害怕自動(dòng)化的軟件過(guò)程，經(jīng)常會(huì)問(wèn)“我們?nèi)绾慰刂崎_(kāi)發(fā)”這樣的問(wèn)題。這一問(wèn)題的本質(zhì)既忽略了 DevSecOps 的精神，也忽略了開(kāi)發(fā)組織為使每個(gè)軟件版本更快、更高效和更一致所做的努力。對(duì)于安全團(tuán)隊(duì)來(lái)說(shuō)，應(yīng)對(duì)軟件開(kāi)發(fā)中發(fā)生的變化，并擴(kuò)展他們相對(duì)較小的組織的唯一方法，就是變得和開(kāi)發(fā)團(tuán)隊(duì)一樣敏捷，并且擁抱自動(dòng)化。我們通常討論我們做研究背后的動(dòng)機(jī)，以幫助讀者理解我們的目標(biāo)和希望傳達(dá)的內(nèi)容。當(dāng)我們更新一份研究報(bào)告時(shí)，情況就更加復(fù)雜了，因?yàn)樗兄谖覀兙劢棺罱袠I(yè)的變化，這些變化導(dǎo)致舊的論文在描述最近的趨勢(shì)方面存在不準(zhǔn)確或不足的問(wèn)題。由于 DevOps 和 DevSecOps 選項(xiàng)在近四年已經(jīng)相當(dāng)成熟，所以，關(guān)于這一方面我們有很多要談的。這項(xiàng)工作將是對(duì)我們2015年關(guān)于將安全構(gòu)建到 DevOps 中的研究工作的重大改寫(xiě)，包括圍繞安全團(tuán)隊(duì)詢問(wèn)的關(guān)于 DevSecOps 的常見(jiàn)問(wèn)題的重大增補(bǔ)，以及對(duì)集成工具和方法的徹底更新。這篇研究論文的大部分內(nèi)容將反映的是2017年以來(lái)財(cái)富2000強(qiáng)公司的200多個(gè)安全團(tuán)隊(duì)的400多次談話。因此，我們將包括眾多從這些對(duì)話中衍生出來(lái)的討論要點(diǎn)。由于 DevOps 已經(jīng)存在了很多年，我們將不過(guò)多討論什么是 DevSecOps 或者它是如何對(duì)我們有益的，更多的是關(guān)于如何組合一個(gè) DevSecOps 程序的務(wù)實(shí)的內(nèi)容。1.3 不同的焦點(diǎn)，不同的價(jià)值有大量新的調(diào)查和研究論文可用，其中一些是非常好的。還有更多的會(huì)議和在線資源涌現(xiàn)出來(lái)，資源多到我都數(shù)不過(guò)來(lái)了。例如，Veracode 最近發(fā)布了他們的軟件安全狀態(tài)(SoSS)報(bào)告的最新版本，這份報(bào)告是一個(gè)大部頭讀物，帶有大量的數(shù)據(jù)和觀察。關(guān)鍵的要點(diǎn)是 DevSecOps 團(tuán)隊(duì)使用的靈活性和自動(dòng)化提供了明顯的安全優(yōu)勢(shì)，包括更快的修補(bǔ)周期，更短的缺陷持續(xù)時(shí)間，更快的技術(shù)債務(wù)減少，以及更容易的掃描意味著更快的問(wèn)題識(shí)別。最近發(fā)布的2019年軟件供應(yīng)鏈狀態(tài)報(bào)告顯示，團(tuán)隊(duì)表示，模范項(xiàng)目團(tuán)隊(duì)利用 DevOps 原則大大降低了代碼部署失敗率，補(bǔ)救漏洞的時(shí)間只有平均水平的一半。我們還有像DevOps全天的活動(dòng)，數(shù)以百計(jì)的 DevOps 從業(yè)者在這里分享關(guān)于文化轉(zhuǎn)型、持續(xù)集成 / 持續(xù)部署(CI/CD)技術(shù)、SRE以及 DevSecOps 的故事。所有這些都很棒，并且提供了一系列定性和定量的數(shù)據(jù)來(lái)說(shuō)明為什么 DevOps 可行，以及從業(yè)人員是如何演變他們的程序的。這不是這篇文章的主題。這些資源并沒(méi)有解決我每周都被問(wèn)到的問(wèn)題。注意，本文是關(guān)于如何整合一個(gè)全面的 DevSecOps 項(xiàng)目。因?yàn)槲覀兛偸潜粏?wèn)到“我如何把一個(gè) DevSecOps 項(xiàng)目組合在一起? ” 以及“安全性與 DevOps 有什么關(guān)系? ” 。他們不是在尋找正當(dāng)理由，也不是在尋找關(guān)于細(xì)微差別的故事來(lái)解決具體的障礙。他們需要一個(gè)與同行組織保持一致的安全程序，并擁護(hù)“安全最佳實(shí)踐”。這些受眾絕大多數(shù)是安全和 IT 從業(yè)者，很大程度上被開(kāi)發(fā)團(tuán)隊(duì)所遺忘，他們至少接受了敏捷概念，如果不是完全接受 DevOps 的話。面臨的挑戰(zhàn)是理解開(kāi)發(fā)試圖完成什么，以某種方式與這些團(tuán)隊(duì)集成，并弄清楚如何利用自動(dòng)化安全測(cè)試，使其至少像開(kāi)發(fā)團(tuán)隊(duì)一樣敏捷。這就引出了另一個(gè)有爭(zhēng)議的話題，以及為什么這項(xiàng)研究與眾不同: DevSecOps 這個(gè)名字。我們的論點(diǎn)是，鑒于在這個(gè)問(wèn)題上缺乏成熟與理解，調(diào)用安全性(“ DevSecOps”中的“ Sec”)是必要的。換句話說(shuō)，完全支持DevOps這一運(yùn)動(dòng)的實(shí)踐者會(huì)告訴你，沒(méi)有理由在 DevOps 中加入 Sec，因?yàn)榘踩皇瞧渲幸粋€(gè)因素。DevOps 的理想是打破單個(gè)團(tuán)隊(duì)之間的隔閡(例如: 架構(gòu)、開(kāi)發(fā)、 IT、安全和 QA) ，以更好地促進(jìn)團(tuán)隊(duì)合作，更好地激勵(lì)每個(gè)團(tuán)隊(duì)成員朝著相同的目標(biāo)前進(jìn)。如果安全性只是融合在構(gòu)建和交付軟件的總體工作中的一組技能，那么我們就沒(méi)有理由稱之為安全保證。從哲學(xué)層面講，這些支持者是對(duì)的。但實(shí)際上，我們還沒(méi)有到那個(gè)地步。也許開(kāi)發(fā)人員能夠接受這個(gè)想法 ---- 他們其實(shí)并不擅長(zhǎng)促成團(tuán)隊(duì)集成。當(dāng)然，安全是可以自由參與的，但這取決于他們了解在哪里可以集成，并通常要求將他們可能不具備的技能帶到聚會(huì)上。這是被動(dòng)攻擊型的團(tuán)隊(duì)建設(shè)！自動(dòng)化的安全性測(cè)試，就像自動(dòng)化的應(yīng)用程序構(gòu)建和部署一樣，需要時(shí)間和技能來(lái)構(gòu)建。在我們與客戶典型的安全會(huì)議中，開(kāi)發(fā)人員并不怎么參與。因此分歧仍然存在，安全團(tuán)隊(duì)和通常有幾十到幾百個(gè)分散的開(kāi)發(fā)團(tuán)隊(duì)之間幾乎沒(méi)有交流。當(dāng)開(kāi)發(fā)人員在場(chǎng)時(shí)，他們聲明安全團(tuán)隊(duì)可以創(chuàng)建腳本，將安全測(cè)試集成到構(gòu)建服務(wù)器中; 他們可以編寫(xiě)安全策略; 安全可以將安全分析工具與故障檢測(cè)以及幾行 python 代碼的度量結(jié)合在一起。畢竟，許多 IT 從業(yè)者正在學(xué)習(xí)為組態(tài)管理編寫(xiě)腳本，并構(gòu)建模板來(lái)定義基礎(chǔ)設(shè)施部署，那么為什么不提供安全性呢？這完全忽略了一個(gè)事實(shí)，即很少有安全從業(yè)人員能夠在這個(gè)級(jí)別編寫(xiě)代碼。更糟糕的是，與我們交談的大多數(shù)公司的開(kāi)發(fā)人員與安全從業(yè)人員的比例約為100:1，而且根本沒(méi)有辦法在所有開(kāi)發(fā)項(xiàng)目中擴(kuò)展安全資源。許多安全專家還處在理解DevOps的早期階段，以及開(kāi)發(fā)人員在過(guò)去十年中為了變得更加敏捷而采用的各種方法。安全確實(shí)落后于形勢(shì)，而且似乎現(xiàn)有的大部分研究(上文提到的)并不是為了解決安全的引入和整合問(wèn)題。最后，我們選擇使用 DevSecOps 名稱還有一個(gè)非常重要的原因: 代碼安全方面的安全工作與基礎(chǔ)設(shè)施和支持組件的安全工作非常不同。用于驗(yàn)證應(yīng)用程序代碼的安全性檢查是安全的(即: DevSec) ，但與使用的工具和過(guò)程不同，它們用于驗(yàn)證支持基礎(chǔ)架構(gòu)(即: SecOps)是安全的。這是兩個(gè)不同的規(guī)程，具有不同的工具和方法，應(yīng)該作為單獨(dú)的工作進(jìn)行討論。我們檢查了過(guò)去三年所有的電話記錄，并記錄了我們被問(wèn)到的問(wèn)題。下面的列表是最常見(jiàn)的問(wèn)題，按問(wèn)題被問(wèn)到的頻率排序如下。- 我們希望將安全性測(cè)試集成到開(kāi)發(fā)管道中，并將從靜態(tài)分析開(kāi)始。我們?cè)撛趺醋觯?/span>
- 我們?nèi)绾胃鶕?jù)自動(dòng)化、 CI/CD 和 DevOps 構(gòu)建應(yīng)用程序安全策略？
- 如何開(kāi)始構(gòu)建一個(gè)應(yīng)用程序策略? 我應(yīng)該遵循什么應(yīng)用程序安全標(biāo)準(zhǔn)？
- 開(kāi)發(fā)部門每天都在向生產(chǎn)環(huán)境發(fā)布代碼。我們?nèi)绾慰刂崎_(kāi)發(fā)？我們真的能夠改變開(kāi)發(fā)人員的行為嗎？
- 引入 DevSecOps 的最佳方式是什么？我該從哪里開(kāi)始呢？最基本的部分是什么？
- 現(xiàn)狀有些是瀑布式的，有些是敏捷的，有些是 DevOps 的時(shí)候，我們?nèi)绾巫尣煌膯挝徊捎猛粋€(gè)流程(不同的團(tuán)隊(duì)做事情的方式不同) ？
- 我們(安全)應(yīng)該如何與開(kāi)發(fā)人員一起工作？
- 我們理解左移，但是這些工具有效嗎？你建議從哪些工具開(kāi)始呢？
這些問(wèn)題都有一些共同的線索：它們都來(lái)自至少有一些團(tuán)隊(duì)DevOps實(shí)踐已經(jīng)開(kāi)展的公司，安全部門對(duì) DevOps 的意圖有一些了解，但是安全都是從零開(kāi)始的。即使已經(jīng)在開(kāi)發(fā)管道中內(nèi)置了安全測(cè)試的團(tuán)隊(duì)也在為每個(gè)工具提供的價(jià)值、開(kāi)發(fā)人員對(duì)于誤報(bào)的抵觸、如何與開(kāi)發(fā)人員合作或者如何在多個(gè)開(kāi)發(fā)團(tuán)隊(duì)之間進(jìn)行擴(kuò)展以保持一致性而苦苦掙扎。我們發(fā)現(xiàn)，在調(diào)用和約定期間，安全人員與開(kāi)發(fā)人員接受 DevOps 的原因并不完全一致，并且錯(cuò)過(guò)了工作的重點(diǎn)，這就是為什么它們通常不同步的原因。以下是我們提出的安全性問(wèn)題清單，安全團(tuán)隊(duì)?wèi)?yīng)該問(wèn)這些問(wèn)題，但是沒(méi)有解決。- 我們?cè)谖幕虾筒僮魃先绾芜m應(yīng) DevSecOps？
- 我們?cè)撊绾问归_(kāi)發(fā)和開(kāi)發(fā)實(shí)踐具有可見(jiàn)性？
- 我們?nèi)绾沃雷兓怯行У? 我們應(yīng)該收集和監(jiān)控哪些指標(biāo)？
- 我們?cè)撊绾沃С珠_(kāi)發(fā)部門？
在本文中，我們將討論這兩個(gè)問(wèn)題列表。接下來(lái)，我們將簡(jiǎn)要介紹 DevOps 原則和安全在 DevOps 中的作用。考慮到 DevOps 對(duì)于大多數(shù)讀者來(lái)說(shuō)是全新的概念，所以在第一節(jié)章我們分享了一個(gè)關(guān)于基本原則的討論，以及 DevOps 是如何幫助解決軟件交付中常見(jiàn)的許多問(wèn)題的。你可以從中找到想要了解的更詳細(xì)的背景資料。出于本章的目的，我們將討論一些與安全團(tuán)隊(duì)集成和使用 DevOps 原則進(jìn)行安全測(cè)試直接相關(guān)的原則。這些概念為解決我們?cè)诘谝徊糠种刑岢龅膯?wèn)題奠定了基礎(chǔ)，在我們討論 DevOps 環(huán)境中的安全工具和方法時(shí)，讀者需要理解這些概念。
構(gòu)建安全性，聽(tīng)起來(lái)是一個(gè)可怕的事實(shí)，但是在代碼開(kāi)發(fā)過(guò)程中廣泛使用應(yīng)用程序安全性技術(shù)，相對(duì)來(lái)說(shuō)還是較新的事情。當(dāng)然，對(duì)這個(gè)領(lǐng)域的研究已經(jīng)有幾十年的歷史了，但是應(yīng)用程序安全性更多地是通過(guò)網(wǎng)絡(luò)或應(yīng)用程序防火墻加固的，而不是嵌入到代碼本身。安全產(chǎn)品供應(yīng)商發(fā)現(xiàn)，在應(yīng)用程序之外理解應(yīng)用程序請(qǐng)求做安全檢測(cè)并阻止攻擊是非常困難的。在可能的情況下，修復(fù)易受攻擊的代碼并關(guān)閉攻擊載體要有效得多。附加工具正在變得越來(lái)越好用——有些工作是在應(yīng)用程序上下文中進(jìn)行的——但是如果可能的話，最好能在代碼中解決這些問(wèn)題。構(gòu)建安全性的一個(gè)核心概念是“左移” ，或者是我們?cè)谲浖_(kāi)發(fā)生命周期(SDLC)中更早地集成安全測(cè)試的想法——這些階段按照從左到右的順序通?？梢苑譃樵O(shè)計(jì)、開(kāi)發(fā)、測(cè)試、預(yù)生產(chǎn)和生產(chǎn)。從本質(zhì)上講，我們將更多的資源從最右端的生產(chǎn)進(jìn)行左移，將更多的資源投入到設(shè)計(jì)、測(cè)試和開(kāi)發(fā)階段。這些思想誕生于精益生產(chǎn)，Kaizen 和 Deming 的原則，已被證明是有效的，但通常應(yīng)用于制造行業(yè)。DevOps 已經(jīng)在軟件開(kāi)發(fā)領(lǐng)域得到了推廣和應(yīng)用，證明我們可以通過(guò)在研發(fā)過(guò)程的早期將缺陷安全檢測(cè)左移來(lái)實(shí)現(xiàn)以較低的成本提高安全性。對(duì)于我們談到的大多數(shù)公司來(lái)說(shuō)，自動(dòng)化是成功的關(guān)鍵之一，以至于工程團(tuán)隊(duì)常常將 DevOps 和自動(dòng)化等同起來(lái)?，F(xiàn)實(shí)問(wèn)題是隨著 DevOps 而來(lái)的文化和組織上的變化同樣重要，只是自動(dòng)化有時(shí)候最能量化收益。自動(dòng)化為相關(guān)各方帶來(lái)了速度、一致性和效率。和敏捷開(kāi)發(fā)一樣，DevOps 的目標(biāo)是做得更少、更好、更快。軟件發(fā)布更有規(guī)律，代碼變更更少。更少的工作意味著更好的專注，每次發(fā)布的目的更明確，就能導(dǎo)致更少的錯(cuò)誤。這也意味著在發(fā)生錯(cuò)誤時(shí)更容易回滾。自動(dòng)化幫助人們以較少的實(shí)際操作完成了工作，但是由于自動(dòng)化軟件每次都做完全相同的事情，所以，一致性是最為明顯的一個(gè)好處。首先應(yīng)用自動(dòng)化的地方是應(yīng)用程序構(gòu)建服務(wù)器，自動(dòng)化的好處在這里最為明顯。構(gòu)建服務(wù)器(例如: Bamboo，Jenkins,) ，通常稱為持續(xù)集成(CI)服務(wù)器，在代碼更改時(shí)自動(dòng)構(gòu)建一個(gè)應(yīng)用程序——甚至可能是整個(gè)應(yīng)用程序堆棧。一旦構(gòu)建了應(yīng)用程序，這些平臺(tái)還可能啟動(dòng) QA 和安全測(cè)試，將失敗的構(gòu)建反饋給開(kāi)發(fā)團(tuán)隊(duì)。自動(dòng)化有利于軟件生產(chǎn)的其他方面，包括報(bào)告、度量、質(zhì)量保證和發(fā)布管理，但是安全測(cè)試所帶來(lái)的好處則是我們?cè)谶@項(xiàng)研究中所關(guān)注的。從一開(kāi)始來(lái)看，調(diào)用安全測(cè)試工具代替手動(dòng)運(yùn)行測(cè)試所帶來(lái)的好處并不是很多。這種觀點(diǎn)忽略了自動(dòng)化安全測(cè)試的基本好處。自動(dòng)化是我們?nèi)绾未_保軟件的每次更新都包括安全測(cè)試，以確保一致性。自動(dòng)化可以幫助我們避免重復(fù)的或者完全透明的人工任務(wù)中常見(jiàn)的錯(cuò)誤和遺漏。但最重要的是，由于開(kāi)發(fā)人員通常比安全團(tuán)隊(duì)多100倍，自動(dòng)化是擴(kuò)大安全覆蓋范圍的關(guān)鍵因素，而無(wú)需擴(kuò)大安全人員的規(guī)模。2.1.3 論一個(gè)團(tuán)隊(duì)的重要性一個(gè)關(guān)鍵的 DevOps 原則是打破孤島，在開(kāi)發(fā)人員和支持 QA、 IT、安全和其他團(tuán)隊(duì)之間有更好的合作。我們經(jīng)常聽(tīng)到這樣的想法，這聽(tīng)起來(lái)很老套，但事實(shí)上在軟件開(kāi)發(fā)中很少有人能真正做出改變來(lái)實(shí)現(xiàn)這個(gè)想法。大多數(shù)以 DevOps 為中心的公司正在改變開(kāi)發(fā)團(tuán)隊(duì)的組成，以及包括來(lái)自所有學(xué)科的科代表; 這意味著每個(gè)團(tuán)隊(duì)都有一個(gè)了解一點(diǎn)安全或者是代表安全利益的人，即使是在一個(gè)小團(tuán)隊(duì)中。對(duì)于那些做到這一點(diǎn)的人來(lái)說(shuō)，他們不僅意識(shí)到了更好的溝通所帶來(lái)的好處，還意識(shí)到了目標(biāo)和激勵(lì)的真正一致性。孤立的開(kāi)發(fā)模式可以激勵(lì)開(kāi)發(fā)人員編寫(xiě)出新的特性。孤立的質(zhì)量保證是為了獲得各種測(cè)試的代碼覆蓋率。當(dāng)團(tuán)隊(duì)中的每個(gè)人都對(duì)新軟件的成功發(fā)布負(fù)責(zé)時(shí)，優(yōu)先級(jí)和行為的改變就會(huì)發(fā)生變化。對(duì)于我們采訪過(guò)的許多公司來(lái)說(shuō)，這個(gè)問(wèn)題依然存在。我們接觸過(guò)的大多數(shù)公司規(guī)模都很大，有數(shù)百個(gè)開(kāi)發(fā)團(tuán)隊(duì)分布在不同的國(guó)家，其中一些是第三方(即外部)咨詢公司。所有這些團(tuán)隊(duì)都很難保持一致性，更加難以獲得普遍參與。管理結(jié)構(gòu)的建立使開(kāi)發(fā)經(jīng)理管理開(kāi)發(fā)人員，而不是 IT 運(yùn)維人員。用于特性跟蹤、故障排除和資源分配的管理工具是面向孤島結(jié)構(gòu)的。許多領(lǐng)先的安全工具被設(shè)置為用于分析和向安全專業(yè)人員報(bào)告缺陷，而不是向解決問(wèn)題的開(kāi)發(fā)人員或 IT 人員報(bào)告。進(jìn)度仍然是通過(guò)功能輸出和代碼覆蓋率來(lái)衡量的，并且相應(yīng)地發(fā)放獎(jiǎng)金。這里的要點(diǎn)是，如果不對(duì)支持安全的系統(tǒng)和結(jié)構(gòu)進(jìn)行一些改變，這種文化變革和由此產(chǎn)生的巨大利益是無(wú)法實(shí)現(xiàn)的。這是一個(gè)非常艱難的調(diào)整，各種各樣的管理者都希望實(shí)施策略，就好像他們擁有完全的監(jiān)督權(quán)一樣，可是他們忽略了一點(diǎn)，那就是他們也需要與他們的同行一起采用‘一個(gè)團(tuán)隊(duì)'的方法來(lái)有效地進(jìn)行改革。2.1.4 安全從業(yè)人員及應(yīng)用程序安全為什么安全人員要與 DevSecOps，甚至是一般的應(yīng)用程序安全做斗爭(zhēng)，因?yàn)樗麄儧](méi)有軟件開(kāi)發(fā)的背景。大多數(shù)安全從業(yè)人員來(lái)自網(wǎng)絡(luò)安全背景，我們談到的許多 CISO 更加注重風(fēng)險(xiǎn)和合規(guī)性，因此普遍缺乏對(duì)軟件開(kāi)發(fā)的理解。缺乏開(kāi)發(fā)工具和過(guò)程的知識(shí)，以及開(kāi)發(fā)人員試圖克服的常見(jiàn)挑戰(zhàn)，就意味著安全團(tuán)隊(duì)很少理解為什么自動(dòng)化構(gòu)建服務(wù)器、中央代碼庫(kù)、容器、敏捷和 DevOps 能在很短的時(shí)間內(nèi)被廣泛采用。在這里，我們將討論開(kāi)發(fā)實(shí)踐中的一些變化驅(qū)動(dòng)因素，以及安全團(tuán)隊(duì)在嘗試處理應(yīng)用程序安全性時(shí)需要理解的關(guān)鍵領(lǐng)域。- 對(duì)過(guò)程的認(rèn)識(shí)?
我們?cè)谶@里不是要教各位開(kāi)發(fā)過(guò)程中的細(xì)微差別，而是要指出過(guò)程變化的原因: 速度。瀑布法、螺旋法、原型演進(jìn)法、極限編程、敏捷開(kāi)發(fā)以及Scrum敏捷開(kāi)發(fā)都是在過(guò)去20年中形成的過(guò)程變體。每一個(gè)都有相同的目標(biāo): 減少?gòu)?fù)雜性(即: 簡(jiǎn)化需求)和加速軟件交付。當(dāng)你明白在過(guò)去的20年里我們?cè)趯?shí)現(xiàn)如何構(gòu)建軟件的大多數(shù)改變都是為了實(shí)現(xiàn)這兩個(gè)目標(biāo)時(shí)，你就會(huì)開(kāi)始明白這個(gè)過(guò)程本身并不重要; 更快、更好的交付軟件才是最重要的目標(biāo)。每日例會(huì)、兩周一次的軟件交付(例如: Sprints)、看板(Kanban)、敏捷、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)和自動(dòng)化構(gòu)建服務(wù)器都是提升技術(shù)水平的工具。因此，對(duì)于安全專業(yè)人員來(lái)說(shuō)，理解安全測(cè)試和策略應(yīng)該包含這些相同的理念是至關(guān)重要的。最后，DevOps 是獨(dú)立于過(guò)程的; 你可以接受 DevOps，并且仍然保留一個(gè)瀑布式的過(guò)程，不過(guò) DevOps 更適合敏捷開(kāi)發(fā)。軟件開(kāi)發(fā)利用許多工具來(lái)管理代碼和過(guò)程。其中，對(duì)安全性最重要的兩個(gè)是代碼存儲(chǔ)庫(kù)和代碼構(gòu)建工具。像 Git 這樣的存儲(chǔ)庫(kù)實(shí)質(zhì)上是管理應(yīng)用程序代碼，為開(kāi)發(fā)人員提供一個(gè)共享位置來(lái)存儲(chǔ)代碼、跟蹤版本以及變更代碼。其他的，如 Docker Registry，則專門用于容器。這些工具對(duì)于開(kāi)發(fā)人員管理他們正在構(gòu)建的代碼至關(guān)重要，但對(duì)于安全性也很重要，因?yàn)樗峁┝艘粋€(gè)可以檢查代碼的地方。構(gòu)建像 Jenkins 和 Bamboo 這樣的服務(wù)器來(lái)自動(dòng)化代碼的構(gòu)建、測(cè)試和交付。但是，它們通常用于完整的應(yīng)用程序堆棧測(cè)試，而不是在組件或模塊級(jí)別。開(kāi)發(fā)人員和質(zhì)量保證團(tuán)隊(duì)使用構(gòu)建服務(wù)器來(lái)啟動(dòng)功能、回歸和單元測(cè)試; 安全團(tuán)隊(duì)還應(yīng)該利用這些構(gòu)建服務(wù)器來(lái)集成安全測(cè)試(。例如: SAST，DAST，成分分析，安全單元測(cè)試) ，因此它適用于相同的構(gòu)建過(guò)程，并使用所有相同的管理和通信工具。對(duì)于安全團(tuán)隊(duì)來(lái)說(shuō)，了解開(kāi)發(fā)團(tuán)隊(duì)使用哪些工具、誰(shuí)控制這些資源以及安排安全測(cè)試的集成非常重要。應(yīng)用程序就是軟件。這是相當(dāng)容易理解的，但是在許多環(huán)境中——特別是公共云環(huán)境中——你的服務(wù)器、網(wǎng)絡(luò)、消息、 IAM 和其他基礎(chǔ)設(shè)施的每一個(gè)都可能被定義為配置腳本、模板或應(yīng)用程序代碼。IT 團(tuán)隊(duì)現(xiàn)在使用由幾百行腳本組成的模板定義整個(gè)數(shù)據(jù)中心。安全從業(yè)人員的想法是雙重的: 安全策略也可以在腳本或代碼中定義，并且你可以檢查代碼的存儲(chǔ)庫(kù)，以確保模板、腳本和代碼在運(yùn)行之前是安全的。這是對(duì)于如何進(jìn)行安全審計(jì)需要做出的根本改變。- 對(duì)開(kāi)源代碼的認(rèn)識(shí)
開(kāi)放源碼軟件在應(yīng)用程序開(kāi)發(fā)中扮演著重要的角色，在開(kāi)發(fā)社區(qū)中得到了廣泛的接受，幾乎不可能找到一個(gè)不利用它的新的應(yīng)用程序開(kāi)發(fā)項(xiàng)目。這意味著很大一部分代碼可能沒(méi)有按照你認(rèn)為的方式進(jìn)行測(cè)試，或者開(kāi)發(fā)人員可能故意使用老的、易受攻擊的版本。為什么？因?yàn)榕f版本與他們的代碼可以很好的一起工作。如果他們更改某個(gè)庫(kù)，可能會(huì)破壞應(yīng)用程序并需要更多的編碼工作。我們鼓勵(lì)開(kāi)發(fā)人員讓代碼正常工作，我們也見(jiàn)證了他們?yōu)榱朔€(wěn)定而努力避免引入新的(例如: 補(bǔ)丁)開(kāi)源版本。因此，我們希望你能夠明白兩點(diǎn): 你需要在開(kāi)源代碼投入生產(chǎn)之前對(duì)其進(jìn)行測(cè)試，并且你需要確保開(kāi)發(fā)人員不會(huì)偷偷地將受信任的開(kāi)源庫(kù)版本替換為較老的、可能易受攻擊的版本。大多數(shù)安全團(tuán)隊(duì)在將安全性引入應(yīng)用程序開(kāi)發(fā)時(shí)采取的第一步是運(yùn)行靜態(tài)分析掃描。這種做法好的一面是大多數(shù)安全從業(yè)人員都知道什么是 SAST 以及它是做什么的。糟糕的是，大多數(shù)時(shí)候安全性始于老式的 SAST 工具，這些工具很慢，產(chǎn)生的輸出只能被安全人員理解，并且會(huì)產(chǎn)生誤報(bào)警報(bào)，而且他們沒(méi)有與構(gòu)建過(guò)程的其余部分完全集成所需的關(guān)鍵 API。總而言之，他們的努力是對(duì)開(kāi)發(fā)人員的敵意，大多數(shù)開(kāi)發(fā)團(tuán)隊(duì)的反應(yīng)是忽略掃描或從構(gòu)建過(guò)程中移除工具。這里有兩個(gè)關(guān)鍵方面: 你希望選擇操作上適合開(kāi)發(fā)模型的工具(更快、更簡(jiǎn)單、更好) ，并使用實(shí)際上能真正有效的工具。讓開(kāi)發(fā)人員自己決定，他們總是選擇最容易集成的工具，而不是最有效的安全掃描工具。但重要的是，安全團(tuán)隊(duì)是安全工具選擇過(guò)程的一部分，以確保安全掃描提供足夠的分析。大多數(shù)應(yīng)用程序安全團(tuán)隊(duì)正在追趕潮流。開(kāi)發(fā)模式(通常)已經(jīng)變?yōu)槊艚蓍_(kāi)發(fā)模式，如果你的一些開(kāi)發(fā)組織支持 DevOps，那么 IT 和 QA 也可能是敏捷模式的。這意味著安全人員是異常的非敏捷; 你所做的或要求的任何事情都會(huì)增加時(shí)間和復(fù)雜性，這與軟件工程的目標(biāo)正好相反。這個(gè)主題是如此重要，以至于我已經(jīng)準(zhǔn)備在本文的下一節(jié)重點(diǎn)闡述“伸縮安全性” ，討論如何解決安全性和開(kāi)發(fā)之間的文化摩擦。許多應(yīng)用程序安全團(tuán)隊(duì)通過(guò)觀察軟件開(kāi)發(fā)生命周期(SDLC)來(lái)處理應(yīng)用程序安全性，目的是在生命周期的每個(gè)階段應(yīng)用某種形式的安全性分析。安全 SDLC (S-SDLC)通常包括設(shè)計(jì)期間的威脅建模、開(kāi)發(fā)期間的成分分析、構(gòu)建階段的靜態(tài)分析以及任意數(shù)量的預(yù)生產(chǎn)測(cè)試。這是一個(gè)設(shè)置獨(dú)立于的過(guò)程的應(yīng)用程序安全性程序的好方法。正如許多大型組織開(kāi)始理解的那樣，你的每個(gè)開(kāi)發(fā)團(tuán)隊(duì)都使用一個(gè)略有不同的過(guò)程，而且你的公司完全有可能使用現(xiàn)有的每一個(gè)已知的開(kāi)發(fā)過(guò)程。這是一個(gè)非常頭疼的問(wèn)題，但是 S-SDLC 成為了你的標(biāo)準(zhǔn): 使用 S-SDLC 作為策略模板，然后將安全控制映射到不同過(guò)程中的適當(dāng)位置。正如我們?cè)谇拔闹刑岬降?，大多?shù)開(kāi)發(fā)團(tuán)隊(duì)在數(shù)量上遠(yuǎn)遠(yuǎn)超過(guò)了安全團(tuán)隊(duì)。例如，本周我與三家中型公司進(jìn)行了交談; 開(kāi)發(fā)人員從800人到2000人不等，而安全團(tuán)隊(duì)的規(guī)模從12人到25人不等。在安全人員中，他們通常有兩個(gè)或三個(gè)人具有應(yīng)用程序安全背景。雖然他們可能像獨(dú)角獸一樣罕見(jiàn)，但這并不意味著他們有神奇的力量覆蓋所有的開(kāi)發(fā)操作，所以他們需要學(xué)習(xí)如何在整個(gè)企業(yè)中擴(kuò)展他們的經(jīng)驗(yàn)。此外，他們需要以一種與開(kāi)發(fā)理念相融合的方式進(jìn)行智慧操作，讓軟件開(kāi)發(fā)團(tuán)隊(duì)執(zhí)行他們?cè)O(shè)計(jì)的安全控制。- 實(shí)現(xiàn)自動(dòng)化安全分析
我們已經(jīng)在某種程度上討論過(guò)了自動(dòng)化，所以我在這里就長(zhǎng)話短說(shuō)。自動(dòng)化是幫助安全分析更快、更頻繁地執(zhí)行，而且不需要安全團(tuán)隊(duì)的直接操作。執(zhí)行自動(dòng)化分析(開(kāi)箱即用或自定義檢查)的安全工具對(duì)于跨多個(gè)開(kāi)發(fā)團(tuán)隊(duì)的擴(kuò)展至關(guān)重要。沒(méi)錯(cuò)，這意味著對(duì)于你公司中的任何一個(gè)構(gòu)建管道，你都必須將工具集成到這個(gè)管道中，所以這需要時(shí)間。這意味著不僅掃描是自動(dòng)化的，而且結(jié)果的分發(fā)是與其他工具和過(guò)程集成的。這就是團(tuán)隊(duì)的擴(kuò)展，也是我們列表中接下來(lái)兩個(gè)項(xiàng)目的工具。開(kāi)發(fā)團(tuán)隊(duì)和安全團(tuán)隊(duì)之間通常有摩擦。安全團(tuán)隊(duì)通常為開(kāi)發(fā)經(jīng)理提供帶有數(shù)千個(gè)缺陷的安全掃描結(jié)果。開(kāi)發(fā)經(jīng)理將其解釋為“伙計(jì)，你的代碼糟透了，你在開(kāi)發(fā)過(guò)程中犯了什么錯(cuò)誤，現(xiàn)在就修復(fù)漏洞! ” 減少兩個(gè)團(tuán)隊(duì)之間摩擦的方法之一是從靜態(tài)或動(dòng)態(tài)掃描中獲取輸出，討論問(wèn)題的范圍，高危缺陷的含義，并就中期修復(fù)的合理性達(dá)成一致。一旦每個(gè)人都同意什么是高危缺陷，以及在什么時(shí)間段內(nèi)修復(fù)漏洞是合理的，你就可以指示安全工具在發(fā)現(xiàn)關(guān)鍵錯(cuò)誤時(shí)使工程構(gòu)建失敗。雖然這個(gè)過(guò)程需要一些時(shí)間來(lái)實(shí)現(xiàn)，也需要承受一些痛苦來(lái)完成，但這種做法改變了安全性和開(kāi)發(fā)之間關(guān)系的性質(zhì)。讓工程構(gòu)建失敗不再是安全說(shuō)“代碼是有缺陷的”，而是讓這種做法成為一個(gè)公正的工具，報(bào)告開(kāi)發(fā)中的缺陷。安全不再是阻礙進(jìn)步的壞家伙，而是開(kāi)發(fā)現(xiàn)在必須滿足的一個(gè)新的質(zhì)量標(biāo)準(zhǔn)以及一個(gè)關(guān)注代碼質(zhì)量的標(biāo)準(zhǔn)，因?yàn)檫@涉及到安全缺陷。這樣的做法還改變了兩個(gè)團(tuán)隊(duì)之間的關(guān)系的本質(zhì)，因?yàn)殚_(kāi)發(fā)人員經(jīng)常需要幫助來(lái)理解缺陷的本質(zhì)，尋找解決某類缺陷的方法而不是單個(gè)缺陷的解決方法，開(kāi)發(fā)人員需要安全團(tuán)隊(duì)的幫助。如果構(gòu)建失敗，那么兩個(gè)團(tuán)隊(duì)之間的關(guān)系將發(fā)生翻天覆地的變化。要實(shí)現(xiàn)這一點(diǎn)需要一些時(shí)間，并且任何產(chǎn)生誤報(bào)的安全工具都會(huì)放大改變的難度，但是這一步對(duì)于 DevOps 團(tuán)隊(duì)來(lái)說(shuō)是至關(guān)重要的。度量對(duì)于理解當(dāng)前應(yīng)用程序安全問(wèn)題的范圍至關(guān)重要，而安全工具是你收集大多數(shù)度量標(biāo)準(zhǔn)的方式。即使你沒(méi)有讓工程構(gòu)建失敗，即使結(jié)果沒(méi)有與任何外部安全共享，集成安全測(cè)試到構(gòu)建服務(wù)器和代碼存儲(chǔ)庫(kù)是獲得可見(jiàn)性和度量的關(guān)鍵。這些指標(biāo)將幫助你決定將預(yù)算花在哪里，是否需要額外的工具、開(kāi)發(fā)人員教育或運(yùn)行時(shí)保護(hù)。這些度量標(biāo)準(zhǔn)將是你實(shí)現(xiàn)工具、教育和運(yùn)行時(shí)保護(hù)的有效性的指南。沒(méi)有度量標(biāo)準(zhǔn)，你就只是在猜測(cè)。我發(fā)現(xiàn)衡量安全性最有效的方法之一是委托自愿的開(kāi)發(fā)人員——那些對(duì)安全性有積極興趣的開(kāi)發(fā)人員——讓這個(gè)人成為他們開(kāi)發(fā)團(tuán)隊(duì)的“安全冠軍”。大多數(shù)開(kāi)發(fā)人員其實(shí)對(duì)安全很感興趣，他們知道安全教育使他們對(duì)公司更有價(jià)值，這通常意味著加薪。出于安全考慮，這意味著你在安全團(tuán)隊(duì)中有了一名聯(lián)絡(luò)員，你可以向他們提問(wèn)，如果他們有問(wèn)題，他們也會(huì)主動(dòng)來(lái)找你。通常情況下，安全團(tuán)隊(duì)通過(guò)教育來(lái)培養(yǎng)這些關(guān)系，擁有一個(gè)“卓越中心”，在這個(gè)虛擬組織中開(kāi)發(fā)人員和安全專家可以提出一些問(wèn)題(例如：Slack 頻道)，將開(kāi)發(fā)人員派去參加安全會(huì)議，或者僅僅是像贊助午餐這樣的討論安全主題的活動(dòng)。不管你怎么做，這都是一個(gè)很好的方法來(lái)擴(kuò)展安全性而不需要擴(kuò)展安全人數(shù)，我們建議你留出一些預(yù)算和資源，因?yàn)樗鼛?lái)的好處遠(yuǎn)遠(yuǎn)大于它的成本。如果你想讓開(kāi)發(fā)人員了解安全和應(yīng)用程序面臨的威脅，那么你就需要對(duì)他們進(jìn)行教育培訓(xùn)。對(duì)工程團(tuán)隊(duì)的領(lǐng)導(dǎo)和工程團(tuán)隊(duì)的副總裁來(lái)說(shuō)，因?yàn)槿藛T的費(fèi)用問(wèn)題，所以他們通常受到嚴(yán)格的教育預(yù)算限制。為了填補(bǔ)這一空白，安全團(tuán)隊(duì)承擔(dān)培訓(xùn)特定開(kāi)發(fā)人員的費(fèi)用，教授這些開(kāi)發(fā)人員缺乏的安全技能，這種情況并不少見(jiàn)。有時(shí)是購(gòu)買與安全有關(guān)的 CBT 來(lái)實(shí)現(xiàn)，有時(shí)是購(gòu)買安全工具供應(yīng)商提供的專業(yè)服務(wù)，有時(shí)是 SANS 或其他機(jī)構(gòu)提供的特定類別。了解如何修復(fù)應(yīng)用程序的安全問(wèn)題、安全參考體系結(jié)構(gòu)、如何執(zhí)行威脅建模以及如何使用安全工具都是很常見(jiàn)的培訓(xùn)主題。這個(gè)系列文章比大多數(shù)其他文章都要長(zhǎng)一點(diǎn)。在過(guò)去的幾年里，我們進(jìn)行了大量的研究。盡管我們?cè)噲D簡(jiǎn)明扼要的說(shuō)出重點(diǎn)，但是為了回答第一部分的問(wèn)題，我們需要涵蓋大量的材料。接下來(lái)，我將討論如何組合一個(gè)安全的 SDLC，以及如何在開(kāi)發(fā)過(guò)程中集成安全測(cè)試。在本章中，我們將向你展示如何在你的 DevOps 自動(dòng)化框架中集成安全性。我們將要解決的問(wèn)題是“我們希望將安全測(cè)試集成到開(kāi)發(fā)管道中，并將從靜態(tài)分析開(kāi)始。我們?cè)撛趺醋? ”、“我們理解“左移” ，但這些工具有效嗎? ”以及“ 你建議我們從哪些工具開(kāi)始，以及如何集成這些工具? 。由于 DevOps 鼓勵(lì)在開(kāi)發(fā)和部署的所有階段進(jìn)行測(cè)試，我們將討論構(gòu)建的管道會(huì)是什么樣，以及適合不同階段的工具。安全測(cè)試通常與質(zhì)量保證團(tuán)隊(duì)可能已經(jīng)部署的功能測(cè)試和回歸測(cè)試并列。除了這些典型的在構(gòu)建之后的測(cè)試點(diǎn)之外， 你還可以在構(gòu)建之前在開(kāi)發(fā)人員的桌面上進(jìn)行測(cè)試，在構(gòu)建之前和之后的代碼庫(kù)中進(jìn)行測(cè)試，以及在預(yù)部署階段進(jìn)行測(cè)試。
在我們接到的幾個(gè)電話中，有幾個(gè)高級(jí)安全主管不知道構(gòu)建過(guò)程的組成。這并不是一種譴責(zé)，因?yàn)樵S多安全人員并沒(méi)有參與軟件生產(chǎn)和交付，所以我們想粗略的闡述一下開(kāi)發(fā)人員使用的過(guò)程和術(shù)語(yǔ)。如果你對(duì)此已經(jīng)很熟悉，那么請(qǐng)?zhí)健皹?gòu)建安全工具鏈”。大多數(shù)讀到本章的人都會(huì)熟悉“夜間構(gòu)建”，在這種模式中前一天檢查的所有代碼都是在夜間編譯的。當(dāng)你習(xí)慣性的查看日志，看看構(gòu)建是否失敗以及為什么失敗的時(shí)候就像你也同樣熟悉早晨要喝咖啡的習(xí)慣。大多數(shù)開(kāi)發(fā)團(tuán)隊(duì)已經(jīng)這樣做了十年或更長(zhǎng)時(shí)間。自動(dòng)化構(gòu)建是公司通向支持代碼開(kāi)發(fā)的流程的完全自動(dòng)化道路上許多步驟中的第一步。在過(guò)去的幾年里，我們已經(jīng)把我們的“腳踩在地板上”，利用越來(lái)越多的自動(dòng)化來(lái)加快軟件交付的步伐。通往 DevOps 的路徑通常分為兩個(gè)階段: 首先是持續(xù)集成，它管理代碼的構(gòu)建和測(cè)試；然后是持續(xù)部署，它將整個(gè)應(yīng)用程序堆棧組裝成一個(gè)可執(zhí)行的環(huán)境。與此同時(shí)，這個(gè)過(guò)程的所有階段都在不斷地改進(jìn)，使其更容易、更快、更可靠。要達(dá)到這個(gè)目標(biāo)需要大量的工作，使用的腳本和模板通常需要幾個(gè)月的時(shí)間來(lái)構(gòu)建基礎(chǔ)，而將它們變得成熟最終成為可靠的軟件交付基礎(chǔ)設(shè)施則需要幾年的時(shí)間。持續(xù)集成(CI)的本質(zhì)是幫助開(kāi)發(fā)人員定期檢查小迭代代碼的進(jìn)展。對(duì)于大多數(shù)團(tuán)隊(duì)來(lái)說(shuō)，這需要對(duì)一個(gè)共享的源代碼儲(chǔ)存庫(kù)或服務(wù)器進(jìn)行多次更新，每天還要進(jìn)行一次或多次構(gòu)建。在這里的關(guān)鍵是，通過(guò)更小、更簡(jiǎn)單的附加功能，我們就可以更容易、更快地發(fā)現(xiàn)代碼缺陷。這些本質(zhì)上是敏捷概念，在驅(qū)動(dòng)代碼的過(guò)程中實(shí)現(xiàn)，而不是在驅(qū)動(dòng)人的過(guò)程中實(shí)現(xiàn)(比如 Scrums 和 Sprints)。持續(xù)集成的定義在過(guò)去的十年里已經(jīng)發(fā)生了變化，但是在 DevOps 的環(huán)境下，持續(xù)集成意味著代碼不僅是使用支持的庫(kù)構(gòu)建和集成，而且是通過(guò)自動(dòng)分發(fā)進(jìn)行測(cè)試的。此外，DevOps CI 意味著代碼變更并不應(yīng)用于分支，而是直接應(yīng)用于代碼的主體，減少了可能困擾開(kāi)發(fā)團(tuán)隊(duì)的復(fù)雜性和集成噩夢(mèng)。這聽(tīng)起來(lái)很簡(jiǎn)單，但實(shí)際上需要大量的基礎(chǔ)設(shè)施支持工作。構(gòu)建必須完全腳本化，并且構(gòu)建過(guò)程在代碼變更時(shí)發(fā)生。每次構(gòu)建成功后，應(yīng)用程序堆棧都會(huì)被打包并傳遞給測(cè)試用戶。測(cè)試代碼在單元測(cè)試、功能測(cè)試、回歸測(cè)試和安全測(cè)試之前構(gòu)建，并成為存儲(chǔ)庫(kù)和自動(dòng)化過(guò)程的一部分。每當(dāng)新的測(cè)試可用時(shí)，測(cè)試工作就會(huì)自動(dòng)開(kāi)始，但這也意味著每個(gè)新的構(gòu)建都會(huì)應(yīng)用新的測(cè)試。這還意味著，在測(cè)試工作可以啟動(dòng)之前，必須自動(dòng)設(shè)置、配置測(cè)試系統(tǒng)，并為其輸入必要的數(shù)據(jù)。自動(dòng)化腳本必須為流程的每個(gè)部分提供監(jiān)控能力，并在事件發(fā)生時(shí)將成功或失敗的信息反饋給開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)。要?jiǎng)?chuàng)建腳本和工具來(lái)實(shí)現(xiàn)這一切，需要運(yùn)維、測(cè)試和開(kāi)發(fā)團(tuán)隊(duì)緊密合作。下圖顯示了容器的自動(dòng)構(gòu)建管道，包括安全測(cè)試點(diǎn)。再次強(qiáng)調(diào)，這種層次的編排不是一蹴而就的，而是一個(gè)需要數(shù)月建立基礎(chǔ)、數(shù)年才能成熟的漸進(jìn)過(guò)程。但這正是持續(xù)改進(jìn)的本質(zhì)所在。持續(xù)部署看起來(lái)非常類似于 CI，但是側(cè)重于向終端用戶發(fā)布軟件，而不是構(gòu)建軟件。它包含了一些類似于包裝、測(cè)試和監(jiān)控的任務(wù)，但有一些額外的不同。在成功完成構(gòu)建周期之后，結(jié)果將提供給持續(xù)部署(Continuous Deployment，CD)流程。CD 在自動(dòng)化和彈性方面又向前邁出了一大步，同時(shí)自動(dòng)化了應(yīng)用程序堆棧的發(fā)布管理、設(shè)置和最終配置，然后啟動(dòng)新的應(yīng)用程序代碼。當(dāng)我們談?wù)?CD 的時(shí)候，人們有兩種方式來(lái)接受這個(gè)概念。有些團(tuán)隊(duì)只是將新版本的應(yīng)用程序啟動(dòng)到現(xiàn)有的生產(chǎn)環(huán)境中。CD 過(guò)程讓?xiě)?yīng)用層實(shí)現(xiàn)了自動(dòng)化，但不能讓服務(wù)器、數(shù)據(jù)或網(wǎng)絡(luò)層實(shí)現(xiàn)自動(dòng)化。我們發(fā)現(xiàn)這在本地應(yīng)用程序和私有云部署中很常見(jiàn)，一些公有云部署也仍然使用這種模型。與我們交談過(guò)的安全團(tuán)隊(duì)中有很大一部分是真正害怕持續(xù)部署的。他們說(shuō)“你怎么可能允許代碼在沒(méi)有檢查和監(jiān)督的情況下運(yùn)行! ” ，他們忽略了一點(diǎn)，即代碼在所有安全測(cè)試通過(guò)之前不會(huì)啟動(dòng)。一些 CI 管道包含一些測(cè)試的手動(dòng)檢查點(diǎn)。根據(jù)我們的經(jīng)驗(yàn)，CD 意味著更可靠和更安全的版本。CD 解決了困擾代碼部署的幾十個(gè)問(wèn)題，特別是在容易出錯(cuò)的手工變更以及生產(chǎn)和開(kāi)發(fā)之間支持庫(kù)的修訂方面。一旦進(jìn)行了充分的測(cè)試，就沒(méi)有理由不信任 CD。并不是所有的公司每天都會(huì)在發(fā)布產(chǎn)品的過(guò)程中發(fā)布代碼；事實(shí)上，只有不到10% 的公司會(huì)持續(xù)發(fā)布產(chǎn)品代碼，但是一些著名的公司，如 Netflix，Google 和 Etsy，一旦測(cè)試完成，就會(huì)自動(dòng)發(fā)布產(chǎn)品代碼。但是大多數(shù)公司(例如: 那些不在內(nèi)容或零售垂直領(lǐng)域的公司)沒(méi)有一個(gè)好的業(yè)務(wù)需要每天發(fā)布多次更新，所以他們不需要發(fā)布代碼。大多數(shù)公司都有一個(gè)較慢的發(fā)布周期，通常每一到三個(gè) sprint 就會(huì)有一個(gè)“上線”的節(jié)奏。我們稱這些為“托管發(fā)布”，因?yàn)閳?zhí)行和計(jì)時(shí)是手動(dòng)操作的，不過(guò)大多數(shù)操作是自動(dòng)的。此外，這些公司還采用了另一種非常強(qiáng)大的技術(shù)：自動(dòng)化基礎(chǔ)設(shè)施部署。在這一階段， 你可以循環(huán)整個(gè)基礎(chǔ)結(jié)構(gòu)堆棧與應(yīng)用程序。這些類型的部署依賴于軟件運(yùn)行環(huán)境的自動(dòng)化；這可以很簡(jiǎn)單的實(shí)現(xiàn)，比如支持一個(gè) Kubernetes 集群，或者利用 Openshift 在 Google GCP 中運(yùn)行 Terraform 模板，或者通過(guò) Cloudformation 模板啟動(dòng)一個(gè)完整的 AWS 環(huán)境?；A(chǔ)設(shè)施和應(yīng)用程序都是代碼，因此兩者都是同時(shí)啟動(dòng)的。這在公有云部署中正變得越來(lái)越普遍。這種發(fā)布方法提供了顯著的優(yōu)勢(shì)，并為所謂的“藍(lán)-綠”或“紅-黑”部署提供了基礎(chǔ)。新舊代碼并排運(yùn)行，近似于鏡像，各自在自己的一組服務(wù)器上運(yùn)行。舊的代碼(即: 藍(lán)色)繼續(xù)服務(wù)于用戶請(qǐng)求，而新的代碼(即: 綠色)只由選定的用戶或測(cè)試工具執(zhí)行。部署是負(fù)載均衡級(jí)別上的一個(gè)簡(jiǎn)單的重定向，內(nèi)部用戶和活動(dòng)客戶可以慢慢地重定向到綠色服務(wù)器，本質(zhì)上是將這些用戶作為新系統(tǒng)的測(cè)試人員。如果新代碼通過(guò)了所有需要的測(cè)試，負(fù)載均衡器將所有流量發(fā)送到綠色服務(wù)器，藍(lán)色服務(wù)器就會(huì)下線，然后綠色服務(wù)器成為了新的藍(lán)色服務(wù)器。如果發(fā)現(xiàn)錯(cuò)誤，負(fù)載均衡器會(huì)被指向原來(lái)的“藍(lán)色”代碼，直到有新的修補(bǔ)程序可用。這基本上是生產(chǎn)中的預(yù)發(fā)布測(cè)試，即使發(fā)現(xiàn)了缺陷或安全問(wèn)題，也可以立即進(jìn)行回滾。集成開(kāi)發(fā)環(huán)境(Integrated Development environment，IDE)是大多數(shù)開(kāi)發(fā)人員的標(biāo)準(zhǔn)。Visual Studio，Eclipse，IntelliJ 等等，一些是針對(duì)特定的語(yǔ)言或環(huán)境定制的。這些桌面工具不僅有助于構(gòu)建代碼，而且它們集成了語(yǔ)法檢查器、運(yùn)行時(shí)、終端、包和許多其他功能，使構(gòu)建代碼更加容易。商業(yè)安全性供應(yīng)商為流行工具提供插件，通常提供一種靜態(tài)分析形式。有時(shí)這些工具是交互式的，在編寫(xiě)代碼時(shí)提供建議，而其他工具在提交代碼之前根據(jù)需要檢查當(dāng)前修改的文件。甚至有一兩個(gè)工具實(shí)際上并不是作為 IDE 的插件，而是作為一個(gè)獨(dú)立的工具工作，并在代碼提交到倉(cāng)庫(kù)之前運(yùn)行。由于代碼掃描通常只是開(kāi)發(fā)人員正在處理的模塊或容器，因此代碼掃描的速度非?？?。在這個(gè)階段正確地進(jìn)行安全掃描可以降低構(gòu)建服務(wù)器在代碼提交后發(fā)現(xiàn)安全問(wèn)題并失敗的可能性。我們與使用這些工具的開(kāi)發(fā)團(tuán)隊(duì)合作，他們發(fā)現(xiàn)這些工具是有效的，并且能夠按照承諾交付。與我們交談的許多開(kāi)發(fā)人員并不喜歡這些安全插件，因?yàn)樗麄冇X(jué)得這些插件噪音大、讓人分心。我們建議盡可能使用這些桌面掃描器，但要認(rèn)識(shí)到使用時(shí)的文化障礙，并提醒安全團(tuán)隊(duì)可能需要幫助改變文化，并允許隨著時(shí)間的推移逐漸采用。源代碼管理、配置管理數(shù)據(jù)庫(kù)、容器注冊(cè)中心和類似于這些類型的工具存儲(chǔ)代碼，并幫助管理任務(wù)，如版本控制，IAM 和審批流程。從安全的角度來(lái)看，一些成分分析供應(yīng)商已經(jīng)集成了他們的產(chǎn)品，以檢查開(kāi)源版本控制是否正確，以及使用的平臺(tái)是否包含已知的 CVE。為已知的好版本和其他版本控制特性創(chuàng)建數(shù)字指紋的附加設(shè)施正變得越來(lái)越普遍。構(gòu)建服務(wù)器構(gòu)建應(yīng)用程序。通常由內(nèi)部開(kāi)發(fā)的多個(gè)源代碼和開(kāi)放源代碼組成，在構(gòu)建應(yīng)用程序時(shí)使用許多“工件”是很常見(jiàn)的。幸運(yùn)的是，像 Jenkins 和 Bamboo 這樣的構(gòu)建服務(wù)器在建立之前和之后都有處理這些工件所需的鉤子。這通常是測(cè)試集成到構(gòu)建管道中的方式。利用此功能將是安全測(cè)試集成的核心。在這個(gè)階段通常集成了成分分析、SAST 和自定義測(cè)試。對(duì)于“代碼完成”或系統(tǒng)測(cè)試，將應(yīng)用程序的所有部分和支持的應(yīng)用程序堆棧組裝在一起，設(shè)置一個(gè)預(yù)生產(chǎn)“準(zhǔn)備區(qū)域”來(lái)模擬生產(chǎn)環(huán)境，并促進(jìn)完整的測(cè)試。我們發(fā)現(xiàn)了幾個(gè)最近的趨勢(shì)，預(yù)生產(chǎn)測(cè)試就是其中之一。由于公有云資源允許快速?gòu)椥院碗S需應(yīng)變的資源采購(gòu)，公司正在開(kāi)發(fā)測(cè)試環(huán)境，運(yùn)行 QA 和安全測(cè)試，然后再次關(guān)閉它們以降低成本。這用于執(zhí)行以前在生產(chǎn)中執(zhí)行的DAST測(cè)試。在大多數(shù)情況下，在大多數(shù)情況下，這是利用藍(lán)綠部署模型在與現(xiàn)有的生產(chǎn)環(huán)境并行的新環(huán)境上運(yùn)行許多不同類型測(cè)試的方法。靜態(tài)應(yīng)用程序安全測(cè)試(SAST)檢查所有代碼或運(yùn)行時(shí)二進(jìn)制文件，以支持對(duì)常見(jiàn)漏洞的徹底搜索。這些工具在發(fā)現(xiàn)缺陷方面非常有效，即使是已經(jīng)經(jīng)過(guò)人工審計(jì)后的代碼也是如此。你的選擇標(biāo)準(zhǔn)可能歸結(jié)為掃描的速度，易于集成，結(jié)果的可讀性和較少的誤報(bào)。這些平臺(tái)中的大多數(shù)已經(jīng)在提供對(duì)開(kāi)發(fā)人員有用的分析結(jié)果方面做得很不錯(cuò)了，而不僅僅是安全極客。許多產(chǎn)品正在升級(jí)，通過(guò) API 或構(gòu)建腳本提供完整的功能。如果可以選擇，可以選擇帶有 API 的工具集成到 DevOps 流程中，這些工具不需要“代碼完成”。我們已經(jīng)看到這些測(cè)試的使用略有減少，因?yàn)樗鼈兺ǔＰ枰獛讉€(gè)小時(shí)或幾天才能運(yùn)行——在 DevOps 環(huán)境中可以防止它們作為認(rèn)證或部署的通道而內(nèi)聯(lián)運(yùn)行。正如我們?cè)谏厦娴摹捌渌辈糠炙岬降?，大多?shù)團(tuán)隊(duì)正在調(diào)整以支持帶外(或者我們稱之為“并行化”)的靜態(tài)分析測(cè)試。如果可能的話，我們強(qiáng)烈建議盡可能內(nèi)聯(lián)SAST測(cè)試，并且關(guān)注新增的代碼部分以減少運(yùn)行時(shí)間。動(dòng)態(tài)應(yīng)用程序安全測(cè)試(Dynamic Application Security Testing，DAST)不是掃描代碼或二進(jìn)制程序(如 SAST) ，而是動(dòng)態(tài)地“爬行”應(yīng)用程序的接口，測(cè)試它對(duì)各種輸入的反應(yīng)。這些掃描器不能看到幕后發(fā)生了什么，但是它們提供了對(duì)代碼行為的有價(jià)值的洞察力，并且可以清除其他測(cè)試在動(dòng)態(tài)代碼路徑中可能看不到的錯(cuò)誤。好消息是它們的誤報(bào)率很低。這些測(cè)試通常是針對(duì)完全構(gòu)建的應(yīng)用程序運(yùn)行的，并且具有破壞性，因此這些工具為了能夠在測(cè)試環(huán)境中更積極地運(yùn)行，通常需要提供一些設(shè)置。就像 SAST 可能需要一些時(shí)間來(lái)完全掃描代碼，，因此在測(cè)試中，一個(gè)版本通常只針對(duì)新代碼運(yùn)行，而整個(gè)應(yīng)用程序掃描是“并行”運(yùn)行的。成分分析工具檢查開(kāi)放源碼庫(kù)的版本，以評(píng)估開(kāi)放源碼的風(fēng)險(xiǎn)，包括安全漏洞和潛在的許可問(wèn)題。像 Heartbleed、配置錯(cuò)誤的數(shù)據(jù)庫(kù)和 Struts 漏洞可能根本不是應(yīng)用程序測(cè)試的一部分，但它們都是關(guān)鍵的應(yīng)用程序棧漏洞。有些人將漏洞測(cè)試等同于 DAST，但是還有其他方法來(lái)識(shí)別漏洞。事實(shí)上，漏洞掃描有幾種類型; 一些看起來(lái)像平臺(tái)配置、補(bǔ)丁級(jí)別或應(yīng)用程序組合等設(shè)置來(lái)檢測(cè)已知的漏洞。確保擴(kuò)大掃描范圍，以包括應(yīng)用程序、應(yīng)用程序堆棧和支持它的開(kāi)源平臺(tái)。一些組織發(fā)現(xiàn)完全實(shí)現(xiàn)自動(dòng)化部署有點(diǎn)嚇人，因此他們希望在新代碼上線之前有人來(lái)審計(jì)變更——我們理解這一點(diǎn)。但也有很好的安全理由進(jìn)行審計(jì)。在一個(gè)像 DevOps 這樣以自動(dòng)化為中心的環(huán)境中，使用或認(rèn)可人工代碼審計(jì)或安全檢查可能看起來(lái)是與之相對(duì)立的，但是人工代碼審計(jì)仍然是非?？扇〉?。某些類型的漏洞不是掃描工具可以識(shí)別的。人工代碼審計(jì)經(jīng)常捕捉到測(cè)試遺漏的明顯內(nèi)容，而開(kāi)發(fā)人員在第一次(唯一一次)通過(guò)時(shí)可能會(huì)遺漏。開(kāi)發(fā)人員編寫(xiě)安全單元測(cè)試的能力各不相同。無(wú)論是由于開(kāi)發(fā)人員的錯(cuò)誤還是審計(jì)人員的技能，編寫(xiě)測(cè)試用例的人員都可能會(huì)遺漏人工審計(jì)所捕獲的內(nèi)容。你的工具應(yīng)該包括人工代碼審計(jì)——至少對(duì)新代碼進(jìn)行定期抽查，或者像 Dockerfile 之類的掃描中經(jīng)常省略的東西。許多公司仍在利用 Web 應(yīng)用程序防火墻，但 Web 防火墻的使用正在下降。我們看到越來(lái)越多地公司在生產(chǎn)環(huán)境中使用運(yùn)行時(shí)應(yīng)用程序自我保護(hù)來(lái)加強(qiáng)日志記錄和保護(hù)工作。這些平臺(tái)提供工具代碼，提供運(yùn)行時(shí)保護(hù)，并在某些情況下識(shí)別應(yīng)用程序里了哪些代碼行是易受攻擊的。DevOps 要求你進(jìn)行更好的監(jiān)控，以便收集指標(biāo)，從而可以根據(jù)操作數(shù)據(jù)進(jìn)行調(diào)整。為了驗(yàn)證新的應(yīng)用程序部署是否正常運(yùn)行，通常內(nèi)置監(jiān)視和檢測(cè)。在某些情況下，這些是使用自定義包和 ELK 堆棧實(shí)現(xiàn)的，在另一些情況下，則只需在生產(chǎn)環(huán)境中打開(kāi)日志記錄和“調(diào)試”風(fēng)格的語(yǔ)句(通常在開(kāi)發(fā)階段使用)。這在公有云 IaaS 中更為突出，在本地日志不能提供充分可見(jiàn)性的情況下， 你完全負(fù)責(zé)數(shù)據(jù)和應(yīng)用程序安全。單元測(cè)試是檢查應(yīng)用程序中較小的子組件或片段(“單元”)。這些測(cè)試由程序員在開(kāi)發(fā)新功能時(shí)編寫(xiě)，通常由開(kāi)發(fā)人員在代碼提交到倉(cāng)庫(kù)之前運(yùn)行，但也可能在構(gòu)建管道中運(yùn)行。這些測(cè)試應(yīng)該是長(zhǎng)期的，與新代碼一起存入代碼存儲(chǔ)庫(kù)，并由每個(gè)后續(xù)的開(kāi)發(fā)人員運(yùn)行，這些開(kāi)發(fā)人員為代碼模塊做出了貢獻(xiàn)。對(duì)于安全性來(lái)說(shuō)，這些攻擊可能很簡(jiǎn)單(比如針對(duì) web 表單的 SQL 注入) ，也可能是針對(duì)被測(cè)功能的更復(fù)雜的攻擊(比如業(yè)務(wù)邏輯攻擊) ，所有這些都是為了確保每一段新代碼都能正確反映開(kāi)發(fā)人員的意圖。每個(gè)單元測(cè)試都側(cè)重于特定的代碼片段，而不是系統(tǒng)或事務(wù)。單元測(cè)試試圖在過(guò)程的早期捕捉錯(cuò)誤，按照Deming的說(shuō)法，越早識(shí)別出缺陷，修復(fù)它們的成本就越低。在構(gòu)建單元測(cè)試時(shí)， 你將需要支持開(kāi)發(fā)人員和基礎(chǔ)設(shè)施來(lái)體現(xiàn)你的測(cè)試，并且還要鼓勵(lì)團(tuán)隊(duì)足夠認(rèn)真地對(duì)待測(cè)試以構(gòu)建良好的測(cè)試。讓多個(gè)團(tuán)隊(duì)成員編寫(xiě)相同的代碼并編寫(xiě)單元測(cè)試，有助于識(shí)別出單個(gè)程序員可能沒(méi)有考慮到的弱點(diǎn)。回歸測(cè)試驗(yàn)證最近更改的代碼是否仍然按預(yù)期的方式運(yùn)行。在安全方面，這對(duì)于確保漏洞得到修復(fù)尤為重要。DevOps 回歸測(cè)試通常與功能測(cè)試并行運(yùn)行ーー在構(gòu)建了代碼堆棧之后。在某些情況下，這可能需要在一個(gè)專用的環(huán)境中進(jìn)行，在這種環(huán)境中， 安全測(cè)試可能具有破壞性，并在具有真實(shí)客戶數(shù)據(jù)的生產(chǎn)服務(wù)器上產(chǎn)生一些不可接受的副作用。利用虛擬化和云基礎(chǔ)設(shè)施可以加快新測(cè)試環(huán)境的實(shí)例化。測(cè)試工作本身通常就是通過(guò)自己構(gòu)建的測(cè)試用例利用以前發(fā)現(xiàn)的漏洞，無(wú)論是作為單元測(cè)試還是系統(tǒng)測(cè)試都是如此。測(cè)試用例的編寫(xiě)人員使用這類測(cè)試來(lái)確保像密碼和證書(shū)這樣的憑據(jù)不包含在文件中，并且基礎(chǔ)架構(gòu)不允許訪問(wèn)端口22或3389。混沌工程通常在生產(chǎn)環(huán)境中引入隨機(jī)故障，以了解應(yīng)用程序環(huán)境如何處理不利條件。像 Netflix 這樣的公司已經(jīng)率先在這個(gè)領(lǐng)域做出努力，以迫使他們的開(kāi)發(fā)團(tuán)隊(duì)理解常見(jiàn)的故障類型，并在他們的代碼中構(gòu)建優(yōu)雅的故障和恢復(fù)。從安全性的角度來(lái)看，如果攻擊者可以強(qiáng)制應(yīng)用程序進(jìn)入壞的狀態(tài)，那么他們通?？梢詮?qiáng)制應(yīng)用程序執(zhí)行不打算執(zhí)行的任務(wù)。將堅(jiān)固性構(gòu)建到代碼中可以提高可靠性和安全性。最簡(jiǎn)單的模糊測(cè)試實(shí)質(zhì)上是向應(yīng)用程序丟棄大量隨機(jī)的垃圾，看看是否有任何特定(類型)的垃圾會(huì)導(dǎo)致錯(cuò)誤。許多動(dòng)態(tài)掃描供應(yīng)商會(huì)告訴你他們提供了模糊測(cè)試。實(shí)際上并非這樣。去參加任何安全會(huì)議，比如Black Hat、 DefCon、 RSA 或 B-Sides 后你都會(huì)發(fā)現(xiàn)，大多數(shù)安全研究人員更喜歡通過(guò)模糊測(cè)試查找易受攻擊的代碼。這種方式已成為識(shí)別可能被攻擊者利用的存在缺陷的代碼的關(guān)鍵。在過(guò)去的10年里，隨著敏捷開(kāi)發(fā)過(guò)程，甚至是 DevOps 的出現(xiàn)，開(kāi)發(fā)團(tuán)隊(duì)和 QA 團(tuán)隊(duì)對(duì)模糊測(cè)試的使用逐漸減少。這是因?yàn)樗苈? 執(zhí)行一個(gè)大型惡意輸入測(cè)試任務(wù)運(yùn)行需要大量的時(shí)間。這對(duì)于 web 應(yīng)用程序來(lái)說(shuō)不是什么大問(wèn)題，因?yàn)楣粽卟豢赡馨阉袞|西都扔進(jìn)代碼里，但是對(duì)于交付給用戶的應(yīng)用程序(包括移動(dòng)應(yīng)用程序、桌面應(yīng)用程序和汽車系統(tǒng))來(lái)說(shuō)，問(wèn)題就很大。我們幾乎排除了這一部分，因?yàn)樵谑褂弥泻苌倏吹秸嬲哪：郎y(cè)試，但是對(duì)于關(guān)鍵系統(tǒng)，定期和帶外模糊測(cè)試應(yīng)該是你的安全測(cè)試工作的一部分。將來(lái)自應(yīng)用程序掃描中發(fā)現(xiàn)的安全問(wèn)題集成到 bug 跟蹤系統(tǒng)中，在技術(shù)實(shí)現(xiàn)上并不困難。大多數(shù)產(chǎn)品都將其作為一個(gè)內(nèi)置的特性提供。困難的部分是弄清楚一旦獲得數(shù)據(jù)后該如何處理。被發(fā)現(xiàn)的安全漏洞真的是一個(gè)問(wèn)題嗎？如果不是誤報(bào)，是否可以利用漏洞？相對(duì)于其他一切，它的臨界性和優(yōu)先性是什么？如果我們選擇解決這個(gè)漏洞，我們又該如何從一系列選項(xiàng)(單元測(cè)試，補(bǔ)丁，RASP) 中選擇一種方式來(lái)進(jìn)行處理？另一個(gè)需要考慮的方面是，這種信息的分布不會(huì)使利益相關(guān)者超負(fù)荷。使用 DevOps， 你需要關(guān)閉基礎(chǔ)設(shè)施、安全測(cè)試以及代碼等問(wèn)題的循環(huán)。Dev 和 Ops 為大多數(shù)漏洞提供了不同的可能有效的解決方案，因此管理安全的人員里面也需要包括運(yùn)營(yíng)團(tuán)隊(duì)。修補(bǔ)、代碼變更、阻斷和功能性白名單都是關(guān)閉安全漏洞的選項(xiàng); 所以你需要 Dev 和 Ops 來(lái)權(quán)衡利弊。本章旨在幫助安全人員為應(yīng)用程序安全程序創(chuàng)建一個(gè)大綱或結(jié)構(gòu)。我們將回答一些常見(jiàn)的問(wèn)題，比如“我們?nèi)绾伍_(kāi)始構(gòu)建應(yīng)用程序安全策略? ” “我如何開(kāi)始合并 DevSecOps? ” 及”我應(yīng)該遵守什么樣的應(yīng)用程式安全標(biāo)準(zhǔn)? ”我將討論軟件開(kāi)發(fā)生命周期(SDLC) ，介紹在實(shí)施計(jì)劃時(shí)需要考慮的安全事項(xiàng)，并參考一些應(yīng)用程式安全標(biāo)準(zhǔn)，作為應(yīng)采取哪些安全措施的指引。本章將幫助你制定戰(zhàn)略; 下一章將介紹戰(zhàn)術(shù)工具的選擇。
安全軟件開(kāi)發(fā)生命周期(S-SDLC)本質(zhì)上描述了安全該如何適應(yīng)軟件開(kāi)發(fā)生命周期的不同階段。我們將研究 SDLC 中的每個(gè)階段，并討論哪些安全工具和技術(shù)是適當(dāng)?shù)摹?/span>請(qǐng)注意，S-SDLC 通常是作為一個(gè)瀑布開(kāi)發(fā)過(guò)程描繪的，具有線性進(jìn)程中的不同階段，但這實(shí)際上只是為了更清晰地描述——實(shí)際的 SDLC 可能是敏捷的、極限的，或者像瀑布一樣的螺旋式的。有充分的理由將 S-SDLC 基于更現(xiàn)代的 SDLC之上; 但是架構(gòu)、設(shè)計(jì)、開(kāi)發(fā)、測(cè)試和部署階段都可以很好地映射到任何開(kāi)發(fā)過(guò)程中的開(kāi)發(fā)階段。它們提供了一個(gè)很好的起點(diǎn)，可以將當(dāng)前的模型和流程適應(yīng)到 DevOps 框架中。在我們之前的文章中，我們希望你將 S-SDLC 看作是構(gòu)建你的安全程序的框架，而不是一個(gè)完整的循序漸進(jìn)的過(guò)程。我們認(rèn)識(shí)到這與課堂教學(xué)和維基教學(xué)有所不同，但是對(duì)于每個(gè)階段的安全計(jì)劃來(lái)說(shuō)更好一些。參考安全體系架構(gòu)適用于不同類型的應(yīng)用程序和服務(wù)，包括 web 應(yīng)用程序、數(shù)據(jù)處理應(yīng)用程序、應(yīng)用程序的身份和訪問(wèn)管理服務(wù)、流或事件處理、消息傳遞等。架構(gòu)在公共云環(huán)境、 Kubernetes 集群和服務(wù)網(wǎng)格環(huán)境中甚至更有效——在這些環(huán)境中，我們可以通過(guò)策略嚴(yán)格控制每個(gè)應(yīng)用程序的操作和通信方式。對(duì)于云服務(wù)，我們建議你利用服務(wù)提供商關(guān)于部署安全的指導(dǎo)方針，盡管他們可能不會(huì)稱之為“參考安全體系架構(gòu)” ，但他們確實(shí)提供了這些指導(dǎo)方針。了解應(yīng)用程序平臺(tái)，并詢問(wèn)軟件設(shè)計(jì)師和架構(gòu)師他們使用了哪些方法。如果對(duì)于傳統(tǒng)的應(yīng)用程序，如果他們給你一個(gè)茫然的眼神，不要感到驚訝。但是新的應(yīng)用程序應(yīng)該包括流程隔離、分離和數(shù)據(jù)安全計(jì)劃，以及完整的 IAM 模型，以促進(jìn)職責(zé)分離和數(shù)據(jù)訪問(wèn)控制。與你的開(kāi)發(fā)團(tuán)隊(duì)一起定義最小的安全測(cè)試需求，以及關(guān)鍵的和高優(yōu)先級(jí)的問(wèn)題。你將需要協(xié)商哪些安全缺陷將導(dǎo)致構(gòu)建失敗，并提前定義流程。你可能需要就修復(fù)問(wèn)題的時(shí)間框架達(dá)成一致，并需要某種類型的虛擬補(bǔ)丁來(lái)解決難以修復(fù)的應(yīng)用程序安全問(wèn)題。你需要預(yù)先定義這些事情，并確保你的開(kāi)發(fā)人員和 IT 合作伙伴同意這些事情。就像在代碼驗(yàn)收之前必須運(yùn)行的最小功能測(cè)試一樣，你將在部署之前運(yùn)行一組安全測(cè)試。這些可能是針對(duì)你的團(tuán)隊(duì)所寫(xiě)的具體威脅而商定的一系列單元測(cè)試?；蛘吣憧赡芤笏?OWASP 十大漏洞在代碼或支持產(chǎn)品中得到緩解，將每個(gè)威脅映射到所有 web 應(yīng)用程序的特定安全控制。不管你選擇什么，你的基準(zhǔn)需求應(yīng)該既考慮到舊的功能，也考慮到新的功能。越來(lái)越多的測(cè)試需要更多的資源進(jìn)行驗(yàn)證，并且隨著時(shí)間的推移可能會(huì)減慢測(cè)試和部署周期，因此你可以決定哪些測(cè)試可以阻止發(fā)布，哪些測(cè)試可以掃描以便進(jìn)行后期生產(chǎn)。如果你將在每個(gè)版本中進(jìn)行小的迭代改進(jìn)，那么需要修復(fù)什么？哪些代碼模塊對(duì)安全有問(wèn)題？什么是有效的，你如何證明它？度量標(biāo)準(zhǔn)是回答所有這些問(wèn)題的關(guān)鍵。你需要考慮需要收集哪些數(shù)據(jù)，并將其構(gòu)建到 CI:CD 和生產(chǎn)環(huán)境中，以度量腳本和測(cè)試的執(zhí)行情況。這意味著你需要讓開(kāi)發(fā)人員和 IT 人員參與收集數(shù)據(jù)。你將不斷改進(jìn)度量標(biāo)準(zhǔn)的收集和使用，但是從一開(kāi)始就要對(duì)數(shù)據(jù)的基本收集和傳播進(jìn)行規(guī)劃。一些應(yīng)用程序的安全設(shè)計(jì)和操作原則提供了重大的安全改進(jìn)。例如用于幫助修補(bǔ)和減少攻擊者持久性的臨時(shí)實(shí)例、用于移除攻擊表面的不可變服務(wù)、用于確保服務(wù)器和應(yīng)用程序正確設(shè)置的配置管理、用于配置一致的云環(huán)境部署的模板、自動(dòng)化修復(fù)、通過(guò)鎖定開(kāi)發(fā)人員和 QA 人員而將職責(zé)分離出生產(chǎn)資源等等。同樣重要的是，這些方法是 DevOps 的關(guān)鍵，因?yàn)樗鼈兪管浖慕桓逗凸芾碜兊酶旄菀?。這聽(tīng)起來(lái)似乎有很多需要解決的問(wèn)題，但 IT 和開(kāi)發(fā)人員也投入其中，因?yàn)檫@也使他們的生活變得更加容易。隨著開(kāi)發(fā)和生產(chǎn)環(huán)境更加固定，開(kāi)發(fā)和測(cè)試服務(wù)器成為更具吸引力的目標(biāo)。傳統(tǒng)上，這些運(yùn)行環(huán)境的安全性很低或根本沒(méi)有安全性可談。但是，對(duì)安全源代碼管理、構(gòu)建服務(wù)器和部署管道的需求正在增長(zhǎng)。由于 CI/CD 管道提供了進(jìn)入生產(chǎn)的自動(dòng)化路徑，你至少需要對(duì)這些系統(tǒng)進(jìn)行更嚴(yán)格的訪問(wèn)控制——特別是構(gòu)建服務(wù)器和代碼庫(kù)。而且，如果腳本在后臺(tái)連續(xù)運(yùn)行，并且人工監(jiān)視很少，那么你將需要額外的監(jiān)視來(lái)捕捉錯(cuò)誤和不當(dāng)使用。許多工具提供了良好的安全性，具有數(shù)字指紋、2FA、日志、以角色為基礎(chǔ)的訪問(wèn)控制和其他安全特性。當(dāng)部署在云環(huán)境中時(shí)，管理臺(tái)允許控制整個(gè)環(huán)境，必須非常小心地進(jìn)行訪問(wèn)控制和職責(zé)分離。威脅建模仍然是最有成效的安全實(shí)踐之一。雖然 DevOps 沒(méi)有改變這一點(diǎn)，但它確實(shí)為安全團(tuán)隊(duì)成員提供了機(jī)會(huì)，可以指導(dǎo)開(kāi)發(fā)團(tuán)隊(duì)成員處理常見(jiàn)的威脅類型，并幫助計(jì)劃單元測(cè)試來(lái)應(yīng)對(duì)攻擊。這個(gè)時(shí)候你需要決定是否在公司內(nèi)部培養(yǎng)這個(gè)人才，還是聘請(qǐng)一個(gè)顧問(wèn)，因?yàn)闆](méi)有哪個(gè)產(chǎn)品可以為你做到這一點(diǎn)。威脅建模通常在設(shè)計(jì)階段執(zhí)行，但也可以在開(kāi)發(fā)較小的代碼單元時(shí)執(zhí)行，有時(shí)也可以通過(guò)自建單元測(cè)試執(zhí)行。- 基礎(chǔ)架構(gòu)和自動(dòng)化優(yōu)先
自動(dòng)化和持續(xù)改進(jìn)是關(guān)鍵的 DevOps 原則，對(duì)于安全也同樣重要。正如前面的文章所討論的，自動(dòng)化是必不可少的，因此你需要選擇和部署安全工具。我們強(qiáng)調(diào)這一點(diǎn)是因?yàn)橛?jì)劃很重要，有助于開(kāi)發(fā)人員在交付新代碼之前計(jì)劃出他們需要部署的工具和測(cè)試工作。請(qǐng)記住，許多安全工具需要集成一些開(kāi)發(fā)技能，因此要么計(jì)劃讓你的員工提供幫助，要么參與專業(yè)服務(wù)。壞消息是，在準(zhǔn)備過(guò)程中需要預(yù)先支付費(fèi)用和完成工作; 好消息是，未來(lái)的每一個(gè)構(gòu)建都將從這些努力中受益。請(qǐng)記住，開(kāi)發(fā)并不是編寫(xiě)代碼和構(gòu)建腳本的唯一團(tuán)隊(duì)——現(xiàn)在操作也是如此。這就是 DevOps 如何將修復(fù)和加固帶到一個(gè)新的水平。運(yùn)維的 DevOps 角色是提供構(gòu)建腳本，用于構(gòu)建開(kāi)發(fā)、測(cè)試和生產(chǎn)服務(wù)器的基礎(chǔ)設(shè)施。好消息是，你現(xiàn)在正在測(cè)試的是生產(chǎn)環(huán)境的精確副本。模板和配置管理解決了傳統(tǒng) IT 多年來(lái)一直努力解決的一個(gè)問(wèn)題: 臨時(shí)性的無(wú)文檔的工作“調(diào)整”環(huán)境使得環(huán)境能夠正常工作。同樣，要使環(huán)境完全自動(dòng)化需要做大量的工作——在服務(wù)器、網(wǎng)絡(luò)配置、應(yīng)用程序等等上面——但是它使未來(lái)的工作更快、更一致。我們采訪的大多數(shù)團(tuán)隊(duì)每周都會(huì)構(gòu)建新的機(jī)器鏡像，并更新他們的腳本以應(yīng)用補(bǔ)丁、更新配置和構(gòu)建腳本以適應(yīng)不同的環(huán)境。這項(xiàng)工作確保了一致性和安全的基線。你希望為開(kāi)發(fā)人員提供一種簡(jiǎn)便的方法來(lái)獲得安全的和(內(nèi)部)批準(zhǔn)的開(kāi)放源碼庫(kù)。我們的許多客戶都保留了經(jīng)過(guò)批準(zhǔn)的庫(kù)的本地副本，使得訪問(wèn)這些資源變得很容易。然后，在將代碼部署到生產(chǎn)環(huán)境之前，他們使用成分分析工具和腳本的組合，以確保開(kāi)發(fā)人員使用的是經(jīng)過(guò)批準(zhǔn)的版本。這有助于減少易受攻擊的開(kāi)放源碼的使用。如前一章節(jié)所述，DevOps 是與流程無(wú)關(guān)的。你可以根據(jù)自己的喜好使用螺旋式，敏捷，或手術(shù)團(tuán)隊(duì)的方法。但是敏捷 Scrum和看板技術(shù)非常適合 DevOps。他們專注于較小的、重點(diǎn)突出的、快速可證明的任務(wù)上，這很好地實(shí)現(xiàn)了協(xié)調(diào)一致。我們建議在這個(gè)時(shí)候設(shè)置你的“安全冠軍”程序，在每個(gè)團(tuán)隊(duì)中至少培訓(xùn)一個(gè)人學(xué)習(xí)安全基礎(chǔ)知識(shí)，并確定哪個(gè)團(tuán)隊(duì)成員對(duì)安全主題感興趣。通過(guò)這種方式，安全任務(wù)可以很容易地分配給那些有興趣并且有一定的技能處理這些任務(wù)的團(tuán)隊(duì)成員。- 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)
持續(xù)集成的一個(gè)核心原則是永遠(yuǎn)不要將有錯(cuò)誤或未經(jīng)測(cè)試的代碼提交到代碼庫(kù)中。錯(cuò)誤和未經(jīng)測(cè)試的定義取決于你。與編寫(xiě)巨大的瀑布式規(guī)范文檔以提高代碼質(zhì)量或安全性不同，你正在用函數(shù)腳本和程序編寫(xiě)策略文檔。單元測(cè)試和功能測(cè)試不僅定義而且增強(qiáng)安全需求。許多開(kāi)發(fā)團(tuán)隊(duì)使用所謂的“測(cè)試驅(qū)動(dòng)開(kāi)發(fā)” ，其中的測(cè)試確保所需的功能——并避免不需要的結(jié)果——與代碼一起構(gòu)建。這些測(cè)試用例被存入代碼庫(kù)，并成為應(yīng)用程序測(cè)試套件的永久部分。安全團(tuán)隊(duì)沒(méi)有充分利用這種類型的測(cè)試，但是這是檢測(cè)特定于代碼的安全問(wèn)題的一個(gè)極好方法，而商業(yè)工具卻沒(méi)有這樣做。DevOps 顛覆了 IT 和軟件開(kāi)發(fā)中許多長(zhǎng)期堅(jiān)持的原則。例如，耐久性過(guò)去意味著“正常運(yùn)行時(shí)間” ，但現(xiàn)在是更換的速度。帶有詳細(xì)產(chǎn)品規(guī)格的大型文檔已經(jīng)被便利貼所取代。對(duì)于安全性來(lái)說(shuō)，曾經(jīng)專注于讓代碼通過(guò)功能需求的團(tuán)隊(duì)現(xiàn)在正在尋找趕在其他人之前破壞應(yīng)用程序的方法。這種“混沌工程”的新方法有意破壞了應(yīng)用程序的部署，迫使工程師在可靠性和安全性方面進(jìn)行構(gòu)建。詹姆斯 · 維克特的《哥特列特》中有一句話: 對(duì)你的代碼要刻薄——就像它雄辯地表達(dá)了你的思想一樣。我們的目標(biāo)不僅僅是在自動(dòng)交付過(guò)程中測(cè)試功能，而且是要真正測(cè)試代碼的堅(jiān)固性，并大幅度的提高可接受發(fā)行版的最低安全性。我們通過(guò)在應(yīng)用程序上線之前有意地對(duì)其進(jìn)行各種功能測(cè)試、壓力測(cè)試和安全測(cè)試，從而加強(qiáng)了應(yīng)用程序的性能——減少了安全專家親自測(cè)試代碼所需的時(shí)間。如果你能夠找到某種方法來(lái)破壞你的應(yīng)用程序，那么攻擊者也有可能破壞你的應(yīng)用程序，因此，你需要在應(yīng)用程序啟動(dòng)之前構(gòu)建測(cè)試以及補(bǔ)救措施。你需要計(jì)劃這些測(cè)試工作，以及構(gòu)建它們所需的資源。所有敏捷開(kāi)發(fā)方法都有一個(gè)共同的問(wèn)題，那就是如何處理比開(kāi)發(fā)周期更長(zhǎng)的測(cè)試。例如，我們知道對(duì)關(guān)鍵代碼片段進(jìn)行模糊測(cè)試所需的時(shí)間比敏捷 Sprint 的平均時(shí)間要長(zhǎng)。對(duì)大量代碼進(jìn)行 SAST 掃描通常要比構(gòu)建過(guò)程長(zhǎng)一個(gè)數(shù)量級(jí)。DevOps 也是如此—— 使用 CI 和 CD 代碼可能在創(chuàng)建后的幾個(gè)小時(shí)內(nèi)交付給用戶，而且可能無(wú)法執(zhí)行完整的白盒測(cè)試掃描或動(dòng)態(tài)代碼掃描。為了解決這個(gè)問(wèn)題，DevOps 團(tuán)隊(duì)同時(shí)運(yùn)行多個(gè)安全測(cè)試以避免延遲。他們將大型應(yīng)用程序分解成服務(wù)，以加快掃描速度。針對(duì)已知關(guān)鍵問(wèn)題的驗(yàn)證由單元測(cè)試來(lái)處理，以便進(jìn)行快速抽查，并將失敗的代碼返回給開(kāi)發(fā)團(tuán)隊(duì)。代碼掃描器通常與單元測(cè)試或其他功能測(cè)試并行運(yùn)行。我們的觀點(diǎn)是，作為一名安全專家，你應(yīng)該尋找加快安全測(cè)試的方法。組織效率與速度的測(cè)試以及完整性與完成時(shí)間的測(cè)試，對(duì)于我們交談過(guò)的每個(gè)開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)，都是一種持續(xù)的平衡過(guò)程。將掃描集中在代碼的特定區(qū)域有助于更快地發(fā)現(xiàn)問(wèn)題。一些公司還討論了維護(hù)預(yù)填充和完全配置的測(cè)試服務(wù)器的計(jì)劃——就像他們維護(hù)生產(chǎn)服務(wù)器一樣——等待下一個(gè)測(cè)試周期以避免延遲。為了提高效率和快速部署而重寫(xiě)和重新配置測(cè)試環(huán)境有助于 CI。有了公共云和虛擬化資源后，快速提供測(cè)試服務(wù)器變得更加容易。我們現(xiàn)在可以通過(guò)一些 API 調(diào)用啟動(dòng)新環(huán)境，并在不使用時(shí)縮容。利用隨需應(yīng)變的彈性云服務(wù)來(lái)加速安全測(cè)試。開(kāi)發(fā)人員和測(cè)試人員有一個(gè)非常壞的習(xí)慣，就是將生產(chǎn)數(shù)據(jù)復(fù)制到開(kāi)發(fā)和測(cè)試環(huán)境中以改進(jìn)他們的測(cè)試。在過(guò)去的幾十年里，這一直是許多數(shù)據(jù)泄露事件的源頭。鎖定生產(chǎn)環(huán)境，這樣 QA 和開(kāi)發(fā)人員就不能泄露受管制的數(shù)據(jù)，這很好，但也確保他們不會(huì)繞過(guò)你的安全控制。數(shù)據(jù)屏蔽、標(biāo)記化和各種工具都可以生成高質(zhì)量的測(cè)試數(shù)據(jù)，從而最大限度的降低它們使用生產(chǎn)數(shù)據(jù)的動(dòng)機(jī)。這些工具提供來(lái)自生產(chǎn)數(shù)據(jù)的測(cè)試數(shù)據(jù)，但去除了敏感信息。這種方法已經(jīng)證明對(duì)于許多公司是成功的，而且大多數(shù)廠商為 DevOps 管道提供了合適的 API 或自動(dòng)化功能。通過(guò)自動(dòng)化將新代碼推入生產(chǎn)環(huán)境非常容易。但對(duì)代碼進(jìn)行審查，或者在出現(xiàn)錯(cuò)誤時(shí)進(jìn)行回滾，要困難得多。與我們交談過(guò)的大多數(shù)團(tuán)隊(duì)還不能完全適應(yīng)全自動(dòng)化部署——這會(huì)嚇壞許多安全人員。持續(xù)的軟件交付實(shí)際上只有少數(shù)公司使用。大多數(shù)公司每隔幾周才向客戶發(fā)布新代碼，通常是在一系列沖刺之后。這些公司通過(guò)腳本執(zhí)行許多部署操作，但是在操作和開(kāi)發(fā)資源可用時(shí)手動(dòng)啟動(dòng)腳本以完全監(jiān)視推送操作。有些組織確實(shí)對(duì)完全自動(dòng)化的生產(chǎn)推送非常滿意，每天會(huì)發(fā)布幾次。沒(méi)有單一的正確答案，但無(wú)論哪種方式，自動(dòng)化都能完成大部分工作，從而騰出人員進(jìn)行測(cè)試和監(jiān)視。為了仔細(xì)檢查在預(yù)部署前的測(cè)試中工作的代碼能夠在開(kāi)發(fā)環(huán)境中仍然可以工作，我們交談過(guò)的團(tuán)隊(duì)仍然會(huì)進(jìn)行“冒煙”測(cè)試，但是他們已經(jīng)將這些測(cè)試進(jìn)化為自動(dòng)化和更細(xì)粒度的控制。我們看到了三個(gè)常用于增強(qiáng)部署的技巧。第一個(gè)也是最強(qiáng)大的部署稱為藍(lán)-綠或紅-黑部署。新舊代碼并排運(yùn)行，各自在自己的一組服務(wù)器上。在負(fù)載均衡器級(jí)別，如果發(fā)現(xiàn)錯(cuò)誤，負(fù)載均衡器就會(huì)指向舊代碼。第二種是金絲雀測(cè)試，其中一小部分單獨(dú)的會(huì)話是針對(duì)新代碼的——優(yōu)先的對(duì)內(nèi)部員工的測(cè)試人員開(kāi)放，然后開(kāi)放給外部客戶的子集。如果金絲雀死亡(遇到錯(cuò)誤) ，新代碼將退出，直到發(fā)出的代碼可以修復(fù)為止，此時(shí)將重復(fù)該過(guò)程。最后，特性標(biāo)記通過(guò)配置文件啟用和禁用新的代碼元素。如果在新的代碼段中發(fā)現(xiàn)了事件錯(cuò)誤，則可以關(guān)閉該特性，直到該特性得到修復(fù)。在不同的模型和組織之間，自動(dòng)化和人工干預(yù)的程度有很大的不同，但總的來(lái)說(shuō)，這些部署比傳統(tǒng)的 web 服務(wù)環(huán)境更加自動(dòng)化。即使安全控制失敗，應(yīng)用程序通常也能繼續(xù)運(yùn)行。例如，一個(gè)新的部署腳本可能會(huì)錯(cuò)過(guò)對(duì) web或應(yīng)用層防火墻策略的更新，或者應(yīng)用程序可能在沒(méi)有任何防火墻保護(hù)的情況下啟動(dòng)。驗(yàn)證——至少是關(guān)鍵安全組件的健全性檢查——對(duì)于生產(chǎn)環(huán)境是必不可少的。我們采訪的大多數(shù)大公司都雇傭了滲透測(cè)試人員，許多公司都有專職的“紅隊(duì)”來(lái)檢查應(yīng)用程序運(yùn)行時(shí)的安全缺陷。- 自動(dòng)化運(yùn)行時(shí)的安全防護(hù)
許多公司將 Web 應(yīng)用程序防火墻(WAF)作為其應(yīng)用程序安全程序的一部分，通常是為了滿足 PCI-DSS 需求。與我們交談過(guò)的大多數(shù)公司對(duì)這些工具都不滿意，所以當(dāng)他們繼續(xù)利用 WAF 黑名單時(shí)，他們采用了運(yùn)行時(shí)應(yīng)用程序自我保護(hù)(RASP)來(lái)填補(bǔ)剩余的空白。RASP 是一種應(yīng)用安全技術(shù)，嵌入到應(yīng)用程序或應(yīng)用程序運(yùn)行時(shí)環(huán)境中，檢查應(yīng)用層的請(qǐng)求，以實(shí)時(shí)檢測(cè)攻擊和誤用。除了“應(yīng)用程序上下文中的 WAF” ，RASP 還可以在應(yīng)用程序框架的許多地方進(jìn)行監(jiān)控和執(zhí)行，既可以針對(duì)特定類型的攻擊定制保護(hù)，也可以允許 web 應(yīng)用程序請(qǐng)求“完成” ，直到在阻止請(qǐng)求之前發(fā)現(xiàn)某個(gè)請(qǐng)求確實(shí)是惡意的。在過(guò)去三年里，我們接到的幾乎所有討論應(yīng)用程序安全和 DevOps 的電話都討論了 RASP，而且我們接觸的大多數(shù)公司都部署了這項(xiàng)技術(shù)。5.8 應(yīng)用程序安全標(biāo)準(zhǔn)?目前已經(jīng)有一些應(yīng)用程序安全標(biāo)準(zhǔn)可用。開(kāi)放式 Web 應(yīng)用程序安全項(xiàng)目(OWASP) TOP 10和 SANS 常見(jiàn)弱點(diǎn)枚舉 TOP 25 是最流行的安全漏洞，但也有其他威脅和常見(jiàn)弱點(diǎn)列表，這些列表通常側(cè)重于特定的子主題，如云部署或應(yīng)用程序安全度量。每個(gè)標(biāo)準(zhǔn)都傾向于被一個(gè)或多個(gè)標(biāo)準(zhǔn)組織所接受，因此你使用的標(biāo)準(zhǔn)通常取決于你所處的行業(yè)?；蛘吣憧梢园阉鼈兌加蒙?。無(wú)論你的選擇如何，我們的想法都是了解哪些攻擊是常見(jiàn)的，并在構(gòu)建管道中使用一個(gè)或多個(gè)安全控制和應(yīng)用程序安全測(cè)試來(lái)解釋這些攻擊。本質(zhì)上，你構(gòu)建的是一個(gè)威脅矩陣，并將它們映射到安全控制。此步驟將幫助你計(jì)劃采用哪些安全工具并將這些工具放入構(gòu)建過(guò)程，以及在生產(chǎn)中使用哪些安全工具。正如前面提到的，DevOps 并不完全是工具和技術(shù)，但它的成功很大程度上取決于人們?cè)谶@個(gè)模型中的工作方式。我們已經(jīng)對(duì)工具和流程進(jìn)行了詳細(xì)的介紹，并且從安全從業(yè)者與 DevOps 合作的角度探討了大部分內(nèi)容。由于本文主要是為了幫助安全人員，所以我們?cè)谶@里概述他們?cè)?DevOps 環(huán)境中的作用。我們希望這個(gè)總結(jié)能幫助你和其他團(tuán)隊(duì)一起工作，減少摩擦。
雖然我們有意將這篇文章命名為企業(yè) DevSecOps，但請(qǐng)記住，你的開(kāi)發(fā)，IT 同行們認(rèn)為根本沒(méi)有這回事。對(duì)他們來(lái)說(shuō)，安全性成為集成和交付代碼的操作過(guò)程的一部分。我們稱安全性為一個(gè)獨(dú)立的東西，是因?yàn)楫?dāng)它被編入 DevOps 框架時(shí)，安全人員實(shí)際上更難適應(yīng)。你需要了解如何改進(jìn)安全代碼的交付，而不會(huì)浪費(fèi)時(shí)間，也不會(huì)在你可能并不熟悉的開(kāi)發(fā)過(guò)程中引入瓶頸。好消息是，安全性非常適合 DevOps 模型，但是你需要在組織使用的自動(dòng)化和編排中進(jìn)行調(diào)整以獲得成功。在本文中，我們甚至還沒(méi)有觸及 DevOps 的理論和實(shí)踐。在基本概念和實(shí)踐方面有很多東西需要你學(xué)習(xí)。要在 DevOps 環(huán)境中工作，你需要了解它是什么以及它是如何工作的。你需要了解文化和哲學(xué)上的變化，以及它們?nèi)绾斡绊戇^(guò)程、工具和優(yōu)先級(jí)。你需要了解公司的方法，以便最好地集成安全工具和指標(biāo)。一旦你了解了開(kāi)發(fā)團(tuán)隊(duì)的機(jī)制，你就會(huì)對(duì)如何在他們的流程上下文中與他們一起工作有了更好的了解。參與 DevOps 團(tuán)隊(duì)意味著你需要適應(yīng) DevOps，而不是相反。DevOps 的目標(biāo)是快、更快、最快: 提供快速反饋的小型迭代更改，最終減少在制品(Work In Progress，WIP)。為提高安全性而進(jìn)行的小型迭代變更符合這個(gè)模型。你將優(yōu)先考慮那些使得安全軟件的交付優(yōu)于新功能交付的事情，這通常是一項(xiàng)巨大的任務(wù)，以改變長(zhǎng)期存在的“功能優(yōu)先”的文化。你需要調(diào)整需求和建議，使它們適合于流程，通常簡(jiǎn)化為小步驟，并提供足夠的信息，使任務(wù)既可以自動(dòng)化，又可以被監(jiān)視。你可以建議進(jìn)行人工代碼審計(jì)或模糊測(cè)試，只要你了解它們?cè)诹鞒讨械倪m用位置，以及哪些可以發(fā)布哪些不能發(fā)布。?我們的經(jīng)驗(yàn)表明，使開(kāi)發(fā)團(tuán)隊(duì)加快安全性的最佳方法之一是培訓(xùn): 內(nèi)部解釋或演示、幫助應(yīng)用程序安全的第三方專家、威脅建模、在線學(xué)習(xí)或各種商業(yè)課程。歷史的負(fù)面影響是成本，許多課程要花費(fèi)數(shù)千美元。你需要評(píng)估如何最好地利用你的資源——這個(gè)問(wèn)題的答案通常包括為所有員工提供一些在線教學(xué)，選擇參加課程的人，然后教同齡人。邀請(qǐng)現(xiàn)場(chǎng)專家教學(xué)的費(fèi)用可能很高，但是整個(gè)團(tuán)隊(duì)都可以參加培訓(xùn)。?如果沒(méi)有幫助，安全團(tuán)隊(duì)根本無(wú)法擴(kuò)展他們的知識(shí)。這并不意味著會(huì)有數(shù)百名新的安全崗位的員工，而是意味著要委托開(kāi)發(fā)人員幫助產(chǎn)品提高安全性。安全團(tuán)隊(duì)通常很小，而且開(kāi)發(fā)人員比例為100:1。此外，安全人員在大多數(shù)開(kāi)發(fā)會(huì)議上都不出席，因此他們?cè)谌粘５拿艚莼顒?dòng)中缺乏可見(jiàn)性。為了幫助擴(kuò)展安全團(tuán)隊(duì)的覆蓋范圍，看看是否可以讓每個(gè)開(kāi)發(fā)團(tuán)隊(duì)中的某個(gè)人——也就是所謂的“安全冠軍”——充當(dāng)安全倡導(dǎo)者。這不僅有助于擴(kuò)展安全團(tuán)隊(duì)的覆蓋范圍，還有助于擴(kuò)展安全意識(shí)。?- 幫助 DevOps 團(tuán)隊(duì)理解威脅
大多數(shù)開(kāi)發(fā)人員并不完全理解攻擊者是如何攻擊系統(tǒng)的，或者當(dāng)代碼或 SQL 注入攻擊是可能出現(xiàn)的時(shí)候，這又意味著什么。安全威脅的深度和廣度超出了他們的經(jīng)驗(yàn)，大多數(shù)公司不教授威脅建模。OWASP Top 10是一個(gè)很好的指南，指出了困擾開(kāi)發(fā)團(tuán)隊(duì)的代碼缺陷類型，但是你應(yīng)該將這些威脅映射回現(xiàn)實(shí)世界的示例，展示 SQL 注入攻擊可能造成的損害，并解釋 Heartbleed 類型的漏洞如何能夠完全暴露客戶憑證?？梢园堰@些現(xiàn)實(shí)世界中的用例看作是“震撼和敬畏” ，這對(duì)于幫助開(kāi)發(fā)人員“理解它”大有幫助。如果你的安全建議只是“加密數(shù)據(jù)”或“安裝 WAF” ，那么這種建議是不夠的。通常情況下，開(kāi)發(fā)人員和 IT 人員對(duì)于安全性的構(gòu)成只有一個(gè)單一的想法，他們希望設(shè)置并忘記一個(gè)單一的工具。幫助構(gòu)建安全性程序的元素，包括代碼內(nèi)增強(qiáng)和支持工具。教導(dǎo)他們?nèi)绾螏椭鉀Q特定的威脅，并提供部署和策略設(shè)置方面的幫助。過(guò)去，公司常常制作代碼風(fēng)格指南，教給年輕的開(kāi)發(fā)人員正確編寫(xiě)的代碼是什么樣的。通常情況下，這些資源都不是在線的。考慮一個(gè)關(guān)于安全編碼實(shí)踐和其他參考資料的Wiki頁(yè)面，這些資料很容易被沒(méi)有安全背景的人發(fā)現(xiàn)并且很容易閱讀。?對(duì)于安全之外的人來(lái)說(shuō)，充分理解安全工具的作用或工作方式是不尋常的。因此，你可以通過(guò)兩種方式提供幫助: 首先，幫助開(kāi)發(fā)人員選擇工具。錯(cuò)誤的概念到處都是，這不僅僅是因?yàn)楣?yīng)商承諾的能力過(guò)高。此外，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，評(píng)估代碼掃描器、活動(dòng)監(jiān)視器甚至補(bǔ)丁管理系統(tǒng)的有效性是不常見(jiàn)的。作為顧問(wèn)，你有責(zé)任幫助 DevOps 了解這些工具能夠提供什么能力，以及在你的測(cè)試框架中適合什么。當(dāng)然，你可能無(wú)法評(píng)估 API 的質(zhì)量，但是你可以判斷一個(gè)產(chǎn)品在什么時(shí)候不能提供有意義的結(jié)果。其次，你應(yīng)該幫助定位開(kāi)支，因?yàn)檎莆召Y金的人并不總是清楚具體的工具如何解決安全性和遵從性要求。你應(yīng)該為滿足業(yè)務(wù)需求的工具指定功能和報(bào)告要求。?在我們的研究過(guò)程中，許多安全專家告訴我們，所有的漏洞看起來(lái)都像是高優(yōu)先級(jí)的，區(qū)分一個(gè)對(duì)組織有影響的漏洞和一個(gè)沒(méi)有影響的漏洞是非常困難的。漏洞披露分析領(lǐng)域超出了開(kāi)發(fā)人員的技能范圍。你需要幫助填補(bǔ)這個(gè)空白，因?yàn)椴⒎敲總€(gè)漏洞都會(huì)帶來(lái)真正的風(fēng)險(xiǎn)。而且，安全人員長(zhǎng)期以來(lái)都喜歡使用恐怖主義威脅等級(jí)，含糊地警告“嚴(yán)重風(fēng)險(xiǎn)”和“高威脅等級(jí)”。如果不把威脅和可能的漏洞利用聯(lián)系起來(lái)，不把漏洞利用對(duì)企業(yè)意味著什么說(shuō)清楚，或者不知道如何解決和降低風(fēng)險(xiǎn)，這些警告都是沒(méi)有價(jià)值的。例如，你可以修復(fù)代碼中一個(gè)關(guān)鍵的應(yīng)用程序漏洞，對(duì)支持系統(tǒng)打補(bǔ)丁，如果不是關(guān)鍵的功能禁用則該功能，或者用 IDS 或防火墻進(jìn)行阻止，甚至是用 WAF 或 RASP 技術(shù)進(jìn)行過(guò)濾?；蛘咴诼┒蠢脤?shí)際上并不會(huì)損害業(yè)務(wù)的情況下，“什么都不做”反而是正確的答案。而不是下意識(shí)的“天哪！現(xiàn)在就修復(fù)它! ” 我們?cè)跉v史上看到過(guò)這樣的反應(yīng)—— 通常有幾種選擇來(lái)修復(fù)一個(gè)漏洞，所以向 DevOps 團(tuán)隊(duì)提出折衷方案可以讓他們選擇最適合的。DevOps 已經(jīng)將一些操作和版本管理人員置于一個(gè)不舒服的位置，他們必須學(xué)習(xí)編寫(xiě)腳本，編寫(xiě)代碼，并將他們的工作公開(kāi)給大眾評(píng)審。它在短期內(nèi)將人們推出他們的舒適區(qū)，但這是在中期內(nèi)建立一個(gè)有凝聚力的團(tuán)隊(duì)的關(guān)鍵部分。安全人員向團(tuán)隊(duì)貢獻(xiàn)測(cè)試是完全可以接受的: 驗(yàn)證證書(shū)的掃描、檢查已知的 SQL 注入攻擊、定位漏洞的開(kāi)源工具等等。如果你對(duì)此感到擔(dān)心，那么請(qǐng)幫助并集成單元測(cè)試和回歸測(cè)試。融合和迎合！要參加一個(gè) DevOps 團(tuán)隊(duì)，其中自動(dòng)化起著關(guān)鍵作用，你可能需要知道如何編寫(xiě)腳本或模板。好消息是，你們的策略現(xiàn)在已經(jīng)體現(xiàn)在環(huán)境的定義中。不要害怕你不知道源代碼控制或腳本的正確格式; 這是開(kāi)發(fā)人員通常熱衷于提供幫助的領(lǐng)域。在將你的測(cè)試集成到構(gòu)建和部署服務(wù)器之前，你可以在腳本編寫(xiě)方面學(xué)一些東西，但是你要做的不僅僅是宣揚(yáng)安全性——你也可以做出貢獻(xiàn)！?你可以幫助開(kāi)發(fā)團(tuán)隊(duì)的一個(gè)關(guān)鍵領(lǐng)域是了解公司和外部的策略需求。正如 CVE 條目幾乎不告訴你如何修復(fù)某個(gè)安全問(wèn)題一樣，內(nèi)部安全和隱私策略執(zhí)行對(duì)于開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)常常是個(gè)謎。開(kāi)發(fā)者不能在谷歌上搜索這些答案，所以你可以提供自己作為顧問(wèn)。你至少應(yīng)該像開(kāi)發(fā)團(tuán)隊(duì)中的任何人一樣理解遵從性、隱私、軟件授權(quán)和安全策略，所以他們可能會(huì)感激你的幫助。
小編注：
這個(gè)系列文章比大多數(shù)其他文章都要長(zhǎng)一點(diǎn)，DevSecOps是一個(gè)特別的領(lǐng)域，所有人都關(guān)注安全，但所有人好像又都不知道什么是安全，如何達(dá)成。對(duì)于未知事物的恐懼，造成了人們談虎色變，安全的舉措也逐漸開(kāi)始變味走了型。本次特意將系列文章編著在一篇推文中，目的就是希望從全局的視角給大家一個(gè)完整的DevSecOps。
（本系列文章發(fā)表于Securosis網(wǎng)站，原文標(biāo)題是“企業(yè)DevSecOps”，我們是從嘶吼的內(nèi)容轉(zhuǎn)發(fā)的（做了少許文字上的優(yōu)化），并不確認(rèn)嘶吼就是原始的譯者，無(wú)從考究。）
玩樂(lè)高，學(xué)敏捷，【規(guī)模化敏捷聯(lián)合作戰(zhàn)沙盤之「烏托邦計(jì)劃」】，2022年3月5-6日登陸深圳，將“多團(tuán)隊(duì)敏捷協(xié)同”基因內(nèi)化在研發(fā)流程中，為規(guī)?；嵘邪l(fā)效能保駕護(hù)航！!???
企業(yè)組隊(duì)和個(gè)人均可報(bào)名參加，一起挑戰(zhàn)極客烏托邦
