亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

什么是DevSecOps

DevSecOps是為了讓安全能夠融入現(xiàn)代應(yīng)用開發(fā)和部署的快節(jié)奏周期，而進(jìn)行的一種文化的改變。DevSecOps意味著開發(fā)中的安全左移，從而需要縮減開發(fā)團(tuán)隊(duì)和安全團(tuán)隊(duì)之間的距離，使得開發(fā)團(tuán)隊(duì)自身可以通過自動(dòng)化的方式處理大量的安全工作。

傳統(tǒng)的軟件開發(fā)流程中，大部分開發(fā)者都需要數(shù)月，甚至數(shù)年才會(huì)發(fā)布新版本的應(yīng)用。這就有了大量的時(shí)間，讓不同的內(nèi)部和外部團(tuán)隊(duì)，對(duì)代碼進(jìn)行質(zhì)量檢測和安全測試，但是，隨著過去十年中，公有云、容器和微服務(wù)模型的發(fā)展，單一的應(yīng)用被分解成不同的小組件，獨(dú)立運(yùn)作。這對(duì)軟件開發(fā)的方式帶來了直接的沖擊，形成了滾動(dòng)發(fā)布和敏捷化的開發(fā)模式。在這一模式下，新的功能和代碼會(huì)持續(xù)地快速被投入使用。許多此類流程通過新的技術(shù)和工具自動(dòng)化實(shí)現(xiàn)，讓企業(yè)能更高速地進(jìn)行創(chuàng)新，從而在競爭中獲得領(lǐng)先。

云、容器和微服務(wù)同樣產(chǎn)生了DevOps文化。開發(fā)者可以自己解決對(duì)于架構(gòu)的需求，而不需要另一個(gè)分離的架構(gòu)團(tuán)隊(duì)來幫他們實(shí)現(xiàn)。現(xiàn)在所有的主流云供應(yīng)商都提供相關(guān)的API和配置工具，幫助客戶能夠通過預(yù)設(shè)的模板，用代碼對(duì)架構(gòu)進(jìn)行配置。

盡管說DevOps文化給軟件開發(fā)帶來了很多創(chuàng)新因素，但是安全卻無法跟上代碼的迭代速度。DevSecOps則應(yīng)運(yùn)而生，試圖解決這個(gè)問題，并將安全測試完全結(jié)合進(jìn)持續(xù)集成（continuous integration, CI）與持續(xù)交付（continuous delivery, CD）流水線中，同時(shí)將相關(guān)的知識(shí)和技能嵌入開發(fā)團(tuán)隊(duì)，從而開發(fā)團(tuán)隊(duì)可以內(nèi)部解決安全隱患。

DevSecOps的三個(gè)關(guān)鍵要點(diǎn)在于：

• 開發(fā)團(tuán)隊(duì)自己完成安全測試
• 測試中發(fā)現(xiàn)的問題由開發(fā)團(tuán)隊(duì)進(jìn)行管理
• 開發(fā)團(tuán)隊(duì)完成修復(fù)工作

應(yīng)用安全測試公司Veracode的聯(lián)合創(chuàng)始人兼CTO，Chris Wysopal表示：“第三個(gè)要點(diǎn)會(huì)需要一些時(shí)間才能實(shí)現(xiàn)，但是我認(rèn)為那才是應(yīng)用安全真正成為DevSecOps的時(shí)候。那樣就不需要另一個(gè)不同的團(tuán)隊(duì)去處理安全相關(guān)的問題。”

實(shí)現(xiàn)真正的安全+開發(fā)

在Wysopal看來，第三點(diǎn)的實(shí)現(xiàn)難點(diǎn)在于開發(fā)者必須在不需要外部幫助的情況下，有修復(fù)安全漏洞的能力，而做到這一點(diǎn)需要不少時(shí)間。許多團(tuán)隊(duì)通過在開發(fā)組中加入一名安全領(lǐng)袖來實(shí)現(xiàn)這一點(diǎn)。這個(gè)人員往往在應(yīng)用安全方面有相當(dāng)多的經(jīng)驗(yàn)，并且相比團(tuán)隊(duì)其他成員受到更多的相關(guān)訓(xùn)練。這個(gè)人能夠檢查相關(guān)的安全修復(fù)，并確保他們被正確應(yīng)用。

不過，這不意味著這位安全領(lǐng)袖不能從團(tuán)隊(duì)外部獲取專家意見。他們依然可以從公司的應(yīng)用安全測試服務(wù)的供應(yīng)商處獲得咨詢服務(wù)。但這應(yīng)該是特殊情況，而不能成為常態(tài)。安全領(lǐng)袖模式不同于安全團(tuán)隊(duì)成員分散在不同開發(fā)小組的模式。

DevOps自動(dòng)化與開源管理公司Sonatype的CTO，Brian Fox則認(rèn)為，開發(fā)和安全的集成也需要從管理層面著手。在他看來，如果安全無法自上而下地完全集成進(jìn)開發(fā)流程中，就無法達(dá)到預(yù)期的效；即使同一團(tuán)隊(duì)的人也會(huì)產(chǎn)生管理層面的目標(biāo)分歧——有時(shí)候盡管兩個(gè)人并未有沖突產(chǎn)生，但是他們也相互無視對(duì)方，并沒有進(jìn)行合作。

同樣的問題也曾發(fā)生質(zhì)量檢測（Quality Assurance, QA）中。之前會(huì)有一名QA經(jīng)理和一名工程師經(jīng)理，理論上他們應(yīng)該一同合作，但事實(shí)上兩者之間總會(huì)會(huì)有派系斗爭。Fox提到，一當(dāng)QA成為開發(fā)團(tuán)隊(duì)工作的一環(huán)的時(shí)候，就會(huì)發(fā)現(xiàn)精神上的敵對(duì)關(guān)系消失了；而同樣的問題依然出現(xiàn)在安全上，而這需要很多的努力才能去改變。

DevSecOps測試與相關(guān)工具

硅谷的科技公司屬于早期就開始采用DevSecOps方法的，但是當(dāng)時(shí)的安全測試工具并不適合開發(fā)者使用。開發(fā)者希望用一些能夠自動(dòng)化使用的命令行工具，這樣他們能夠輕松地修改不同的設(shè)置，并且能將獲得的結(jié)果輸入到漏洞追蹤器中。而在傳統(tǒng)的安全團(tuán)隊(duì)和CISO的理念中，安全的目標(biāo)是治理、合規(guī)和風(fēng)險(xiǎn)管理。

之后逐漸有新的工具開始出現(xiàn)。這些工具都是由開發(fā)者自己編寫給其他開發(fā)者的，并且集成到了開發(fā)環(huán)境以及CI/CD工作流中。一些工具是開源的，其他則是由一些初創(chuàng)公司基于這些開源工具進(jìn)一步改造的。盡管這些工具確實(shí)解決了開發(fā)者的需求，但是它們卻不再真正意義上解決CISO的需求了。

但是Wysopal又提到，雖然對(duì)于開發(fā)團(tuán)隊(duì)而言，使用大量不同的開源工具會(huì)讓他們覺得他們覆蓋了所有自己的需要面；但從企業(yè)治理的角度來看，過多零碎的工具反而會(huì)讓安全團(tuán)隊(duì)難以根據(jù)公司的策略進(jìn)行管理。

在過去的數(shù)年中，傳統(tǒng)的應(yīng)用安全廠商開始改造他們的產(chǎn)品以解決以下兩個(gè)場景需求：提供CISO需要的分析和報(bào)告，同時(shí)也提供開發(fā)者所需要的靈活些和易用性。一些如GitHub的針對(duì)開發(fā)者的云服務(wù)供應(yīng)商已經(jīng)開始將安全測試直接加入他們的服務(wù)之中；如果這些安全測試服務(wù)不時(shí)原生的功能，它們也會(huì)以第三方集成的形式在可購買的服務(wù)項(xiàng)目中出現(xiàn)。

Fox表示，在他的整個(gè)職業(yè)生涯中，總是能看到一些反復(fù)的規(guī)律：用戶總有兩個(gè)傾向——一種是需要一個(gè)供應(yīng)商提供完整的工具組，另一種則更愿意自己將不同的工具集成到一起。而在過去兩年中，他認(rèn)為用戶更傾向于用統(tǒng)一完整的工具組。

Fox同時(shí)也提醒，這種需求可能會(huì)在某個(gè)時(shí)間點(diǎn)逆轉(zhuǎn)——比如在下一個(gè)開創(chuàng)性的技術(shù)出現(xiàn)的時(shí)候，而企業(yè)也需要為此做好準(zhǔn)備。一個(gè)完整的工具組的問題在于，工具組可能有一些組織需求之外的功能；這些功能往往不是因?yàn)閷?duì)企業(yè)更有效而存在的，僅僅是因?yàn)樗鼈兪敲赓M(fèi)的。在一定時(shí)間后，隨著開發(fā)者對(duì)工具的使用，他們自己會(huì)采用更適合自己工作需求的工具，而非企業(yè)認(rèn)可的工具組。

從治理的角度來看，不受管理的團(tuán)隊(duì)必然有負(fù)面影響；但是企業(yè)必須意識(shí)到在未來的一兩年中，這些事情將會(huì)無法避免地發(fā)生，即使試圖限制工具的使用，還是會(huì)有一些開發(fā)者會(huì)我行我素。

Fox補(bǔ)充認(rèn)為，早期的云使用者很多是很不情愿使用云服務(wù)的大組織中，存在的一些小團(tuán)隊(duì)。因此，如果組織能夠意識(shí)到這是不可避免會(huì)發(fā)生的事情，并不對(duì)相關(guān)團(tuán)隊(duì)限制過多，可能反而有機(jī)會(huì)發(fā)現(xiàn)一些開創(chuàng)性的前沿技術(shù)，甚至能真的替換現(xiàn)有的技術(shù)。

DevSecOps實(shí)踐

根據(jù)Wysopal的說法，越來越多的企業(yè)將自動(dòng)安全掃描集成為CI/CD流水線的一部分，但是效果并不能立竿見影。Wysopal認(rèn)為這是所謂的“安全債務(wù)”，因?yàn)橹伴_發(fā)者選擇不修復(fù)的漏洞數(shù)目角度造成的。“安全債務(wù)”產(chǎn)生的原因很多，包括沒有立即修復(fù)發(fā)現(xiàn)的漏洞；也可能決定不修復(fù)，而使用其他方式緩解；還可能因?yàn)橥{級(jí)別較低而不選擇修復(fù)。在Veracode自己的2019年軟件安全報(bào)告趨勢當(dāng)中提到，在基于過去一年對(duì)85,000個(gè)應(yīng)用進(jìn)行掃描獲得的數(shù)據(jù)中發(fā)現(xiàn)，平均修復(fù)應(yīng)用中發(fā)現(xiàn)的漏洞時(shí)間為171天，而在十年前第一份報(bào)告出現(xiàn)的時(shí)候才59天。但是，產(chǎn)生這個(gè)區(qū)別的原因是因?yàn)橹岸诜e了大量沒有修復(fù)的漏洞，而修復(fù)時(shí)間的中位數(shù)依然很相近。

當(dāng)將某個(gè)應(yīng)用的掃描結(jié)果和掃描頻率相關(guān)聯(lián)以后可以發(fā)現(xiàn)，增加在CI/CD流水線上集成的自動(dòng)化掃描頻率，能夠更快修復(fù)漏洞：每天被掃描的應(yīng)用修復(fù)漏洞的時(shí)間中位數(shù)為19天，而每月掃描則為68天。

而從經(jīng)濟(jì)的角度來說，如果需要從安全債務(wù)中減少損失，就需要改變一些開發(fā)習(xí)慣；而DevOps和DevSecOps的實(shí)踐過程，也確實(shí)地使原有的文化發(fā)生了變化。

DevSecOps文化的另一個(gè)利好，是在代碼中存在的嚴(yán)重漏洞數(shù)量也會(huì)大幅度減少。Veracode的數(shù)據(jù)顯示，沒有漏洞的應(yīng)用比例相比十年前降低了，這似乎看上去比之前更糟糕了；但從另一組數(shù)據(jù)中則能發(fā)現(xiàn)，沒有高危漏洞的應(yīng)用比例則從66%上升到了80%。

不過，即使DevSecOps的模式存在，依然有很多工作需要安全人員來處理，而且仍然很依賴人工測試——尤其是對(duì)于邏輯漏洞以及設(shè)計(jì)缺陷等無法通過純自動(dòng)掃描解決的問題。Wysopal表示，人工測試已經(jīng)逐漸不再是一年，甚至兩年一次的行為。人工測試需要反復(fù)進(jìn)行，最好能作為DevOps流程的一部分，在為期兩周的項(xiàng)目階段中，針對(duì)新出的功能進(jìn)行人工測試。如果開發(fā)團(tuán)隊(duì)對(duì)人工測試有了足夠的了解，那就可以由安全領(lǐng)袖進(jìn)行，并且真正滿足開發(fā)團(tuán)隊(duì)自己的需求。

來源：數(shù)世咨詢