Home 播客 EP4 – DevSecOps:向左移動以避免將產品藍圖向右移動
Applications

EP4 – DevSecOps:向左移動以避免將產品藍圖向右移動

About The Author

Outline

Edgio的“超越邊緣”播客簡介第4集:DevSecOps:向左移動以避免改變您的產品路線圖,由Edgio全球行銷活動經理Lauren Bradley主持。

Lauren Bradley:大家好,歡迎來到Beyond the Edge,在這裡我們深入了解現代數字業務的內涵。 我是Lauren Bradley,您本集的共同領航者,今天我們將探討向左移動的主題,特別是隨著Web應用程式和API保護的發展,文化和技術如何改變,成為DevOps生命週期的固有組成部分。

讓我們從Ponemon Institute的驚人統計數據開始。 如今,大多數公司甚至需要200天以上的時間才能發現漏洞。 如果您發現漏洞的速度不夠快,將會花費您很大的成本。 IBM發現測試階段發現的修復錯誤的成本比設計階段發現的成本高15倍。

簡而言之,發現問題的等待時間越長,所付出的代價就越高。 而且,我們不只是談論金錢,返工,時間和能源,最終會使產品發展藍圖倒退。 那麼,您如何有效地左轉,避免浪費寶貴的資源和拖延進度?

今天,Edgio的平臺工程總監Michael Grimshaw和Edgio安全平臺產品管理高級總監Richard Yew參加了我們的會議。 歡迎,Michael和Richard。 很高興您能繼續工作。

Michael Grimshaw:謝謝你,Lauren。 很高興來到這裏。 謝謝你。

Lauren Bradley:你們能告訴我一下你們自己和你們對這個話題的初步想法嗎? Mike,我們將從您開始。

Michael Grimshaw:沒錯。 首先,讓我首先感謝勞倫,感謝你如此關心。 在這個非常重要的話題中,您正在深入探討和不斷發展,我們已經和正在就這一問題進行的對話(包括這一年在內)對我們在業界所做的工作來說是非常寶貴和必要的。

Michael Grimshaw:這種理解需要得到廣泛的廣泛認同,並且真正理解這種興趣。 我是Michael Grimshaw。 我是Edgio的平臺工程總監。 對於那些不熟悉或超級熟悉平臺行業術語的人來說,IT部門真正考慮將您的應用程序和基礎架構統一爲一個連貫的單元。

而且,我來到這個平臺時,我對這個領域充滿了激情,因為它在安全性,盈利性以及對我們的行業非常重要的許多方面都起了巨大的推動作用。

我可以繼續介紹DevSecOps,但讓我將其交給Richard進行介紹。

李察耀:非常感謝Michael。 是的。 是的。 這是一個非常重要的話題。 這對我來說非常重要,因為我個人經歷了整個軟體開發生命週期的過程,並將這些過程轉化為業務。

…說到我不知道的事情,正如Lauren所說,我在Edgio經營我們的安全產品管理組織。 因此,我的日常工作包括與研發團隊,工程團隊合作,以確保我們為客戶提供價值。 而且,所有顯然包括優化我們的開發實踐,安全性,CI CD實踐的一切。 確保我們能夠真正交付安全的產品。

對。 這實際上為我們的客戶提供了價值,按時,按預算交付,並確保我們為客戶提供出色的體驗。 所以,我的眼光是從人們的角度來看整個DevSecOps—流程與技術相對,以及我們如何實際為行業實施最佳實踐。

什麼是DevSecOps?

Michael Grimshaw:Richard,如果你不介意的話,讓我把球丟在那裡。

只是我想讓我們對DevSecOps的含義進行標準化,然後向左移動,對吧? 有Gartner,這裏有些人在聽DevSecOps,而術語“左移”,“右移”等聽起來可能比較新。 這不是新的,你知道,它不像是一年前剛創下的最新熱的東西。

不,這在業界已經有一段時間了。 事實上,Gartner有一份2017年的DevSecOps生命週期報告。 只是DevOps (DevOps)的延伸,也是業界DevOps趨勢的延伸,只是將資訊安全納入意見回饋循環和軟體開發生命週期。

就像我說的,Gartner在2017年寫了這篇文章,它已經是行業中的一個過程和一個運動。 在這之前有一段時間。 因此,這些不是全新的概念。 這只是我們多年來一直在努力的一個延伸。 實際上,DevSecOps就是採用類似的DevOps模型,因為您有開發方面,也有真正的營運方面。

關鍵是,它會儘快滿足您所有的安全需求,我的意思是,從設計開始,就構建整個過程,到您的開發人員在左岸的開發方,對不起,右移更多的是操作可視性。 我們今天將重點放在左側,但基本上是在測試掃描和驗證時,最早會在最左邊。 並儘早在SDLC的開發生命週期中使用。 例如,它談到的其中一件事,這一點可以追溯到七年多以前,是像安全性,掃描和掃描你的開源第三方庫,存儲庫,代碼庫以及你編寫的代碼,設計,架構,整個九碼,然後從一開始就開始烘焙。 我舉出的一個例子是,在開發人員使用的IDE中構建和安全掃描。 這只是其中一個例子,其中有很多。

因此,當他們編寫代碼時,他們可以立即獲得反饋。 哦,我只是把門敞開了,你知道,撞庫或連續注入,他們就像一個語法錯誤,他們就遇到了一個安全錯誤,就在編寫代碼的過程中。 因此,他們可以立即解決這個問題,這樣他們就不會有客戶抱怨客戶或最終用戶被擱置,一個月後,問題就在現場處理。

最便宜,最快,最簡單。 Richard,你要說些什麼。

為什麼在成本方面,偏移如此重要?

Yew Richard:哦,是的。 是的。 就像我認為成本實際上非常重要,大家都知道很多營運成本,任何組織,它就像開發一樣,對吧? 研發過程。

那麼,當談到成本時,這就是為什麼向左移動更重要,對吧? 因為我們付出了很多努力,並討論了為什麼,我相信我們稍後會討論“如何”,但我們想要了解為什麼這一點如此重要,因為我們有數據。

是的。 根據我們的研究,這表明您知道,如果您要修復在發布代碼後發現的安全漏洞,那麼您的產品成本比您在設計階段發現的成本高出15倍。 顯然,我們並不是說您知道,開發工作的早期階段將完全捕獲所有安全漏洞。

這就是為什麼我們需要實施深度防禦的原因。 但是,當您看一看八個階段時,您必須知道,一般而言,債務週期,生命週期從計劃,編碼,構建,測試到喜歡監控和操作。 對。 如果您對它們進行深入的觀察,就像發現安全漏洞時,它所花費的代價就越高。

讓您的組織真正解決問題。 因此,我們討論的是在您已經向產品發布了大量代碼之後在掃描中發現漏洞與在將代碼發送到產品之前在暫存環境中執行動態應用程式安全任務,以便在將代碼發送到產品之前及早發現漏洞之間的區別,對吧?

Richard Yew:您或許能夠在發布代碼縮減來緩解這種情況之前解決這些問題,或者提前實施某種虛擬修補。 但是,再次強調一點非常重要的是,您必須從流程的第一步開始就充分考慮安全性,甚至在您開始編寫代碼之前,再將任何內容放入IDE並開始考慮進行威脅建模。 嘿,設計的哪一部分可能容易被利用?

對DevOps和安全團隊的日常影響

Lauren Bradley:是的,這些都是很好的地方,你們 我的意思是,從用戶的角度來看,如果DevOps或安全團隊不從一開始就實施這一權利,那麼除了成本之外,這對他們的日常體驗又意味著什麼?

此外,我還想談談我們如何有效地將其實施到DevOps生命週期中。

Michael Grimshaw:問得好。 問得好。 讓我在最初的回應中直截了當。 是業界的每一個人,每一位CEO,CTO,CFO–每一位工程師,每一位使用者–我們都想要的只是一顆不可思議的子彈,讓我們每天都能做什麼。

然後我們有一個神奇的安全彈,只需按下開關,您的所有工作就會突然變得安全。 這是每個人都想要的,但這不是現實。 也就是說,人們問我們。 我想問他們,幻想地的天氣如何? 我聽說很好。 如果您接近安全性,資訊安全以及您的開發,這只是一個螺栓。 您知道,“哦,我要購買一些工具,在我們開發,構建和部署了一切之後,我要將這些工具固定下來,並且它將繼續確保一切安全”,坦白說,您購買的是一種非常昂貴的紙質重量。

這就是為什麼人們提到了人員,流程和工具的原因。 這就是為什麼這種辦法的連貫性是如此重要的。 你,我們是多年,幾十年,甚至是可能的。 坦白地說,我們從您只需設計一些產品和安裝安全工具的想法中汲取了許多教訓,您就可以開始使用了。

它會影響您的成本,開發人員的速度和客戶的成本。 我懷疑這方面的一個很好的例子是,幾乎每個在職業生涯中某個時候收聽此播客的人都遇到了一個新功能或新服務或類似的情況,甚至只是部署了修補程序和更新。 一切看起來都很好。 一切都執行良好。 然後突然你接到一位客戶的電話,或者資訊安全員接到一位客戶的電話。 “我們只是被騙了,”或“我們剛剛發生了安全事件”或類似的事情。 原因是,好的,您已經部署了它,但可能掃描尚未完成運行,或者您沒有進行掃描,或者您沒有對它們進行適當調整,而且您剛剛引入了一個巨大的安全漏洞。

也許它會影響您,但更重要的是,它會影響您的客戶。 DevSecOps是為了在一個連貫的流程中將所有這些都集中在一起,並避免這種情況。 這是關於削減成本。 當然。 這是否涉及提高利潤? 哦,在一個很大的方面。 但這也關係到免除公司和客戶的責任。

將安全性整合到DevOps中–就像做蛋糕一樣!

Yew:沒錯。 你知道,說到,說到烘焙,你知道,就像邁克用了這樣一個術語“一致的整體”。 這是真的。 這是非常強大的,這是一個非常有力的詞來說明為什麼要把它放到位很重要,就像我在Edgio中所說的那樣。

我想用一些比喻來說,我聽說這很棒。 我認為比喻可以作為在任何組織內推動正確文化的堅實基礎,正如我們所知,作為安全人員,我們的大部分工作都是福音派。 這不僅僅是實施正確的技術和創建流程,而且還真正進行大量內部行銷。

告訴人們安全對企業來說很重要,對嗎? 您知道,作為安全領導者,這不僅僅是像人們經常想到安全,比如在您的工作流中添加額外的流程層,但您知道,正確的思維方式是安全如何加速業務?

安全性如何真正帶來更多收益,因為這是一種很好的方法,可以證明您必須執行的其他安全性實施來確保組織的安全性。 所以,我聽到的一個很好的比喻是,安全不應該被看作是錦上添花,你知道,你是如何烘焙的,把所有冰塊放在最後一步,你知道,這通常是人們在沒有安全性的ICD工作流時所做的,他們只是在生產的最後階段實施防火牆和API保護。 它應該是什麼,安全,它就像麵粉,你知道,它應該是從一開始就有的東西。

安全性就像麵粉一樣,你可以烘烤蛋糕。 如果安全性正確,您就看不到了。 安全的全部要點是,當它做得正確時,它應該已經被烘焙而不顯而易見。 它不應該是造成挑戰的事情。 這不應使組織速度變慢。

就像比喻一樣,我曾經用來向企業展示為什麼這一點很重要,因為擁有強大的安全流程,安全技術文化,就像有了強大的制動。 在賽車中,你知道為什麼每一輛超級跑車都有很大的,很大的,很棒的制動器,因為它能讓它們更快地轉彎。

它使它們能夠強力制動。 它能讓他們更快,轉身更艱難,對吧? 這使他們能夠贏得比賽。 因此,強力制動與強力發動機同樣重要,對吧? 這就是我們應該從哲學角度看待安全的方式。 很明顯,我們談論了很多關於高水平的問題,對吧? 所以,我們顯然想要更深入地了解這一點。 要點是,好吧,所有這些都很好,但我們到底要怎麼實施呢?

Michael Grimshaw:是的。 我認為這是一個很好的號召,就是剎車。 強力煞車讓您掌控自如。 我們前面的當前道路充滿了彎道,轉彎,所有這些都是,當然,有直路可以讓你踩在地板上,你不會觸碰剎車,而是要導航一切,那剎車,我想,愛,我喜歡這兩個比喻,理查德,因為剎車比喻,它可以讓你控制,當你面對意外的事情時,它會給你更精細的穀物控制。

李察耀:很棒的電話。 順便說一下,我想說一下,我沒有想到這個比喻,這是一個叫Eric Koh博士的人。 他擁有,並且他主持了一個很棒的播客。 所以,我建議大家都去觀看。 但是的,我覺得向企業解釋這個概念是非常恰當的,特別是對這種概念的新手。

問題,孤立的團隊和不斷變化的路線圖

Lauren Bradley:Richard,你說過你是怎麼做的,你知道,如果DevSecOps完成了,對吧? 您看不到它。 顯然,成本是其中一個明顯的遠見。 它也是孤立的團隊。 當出現這些問題時,團隊之間也會有脫節的感覺,為什麼他們以前沒有被抓住呢?

為了快速或有效地解決這些問題,沒有進行哪些流程和通信? 所以,我要問的問題是,根據您的經驗,哪一項…您知道,可能缺乏透明度。 決策緩慢,可能會浪費資源。

如果您的團隊處於孤立狀態,那麼在您看來,團隊在孤立狀態下營運時,哪些問題往往是最大的問題?

李察耀:是的,我要拿這個。 我想,我個人在過去的一生中經歷過的一件事是,當我們談論類似產品時,就像規劃一樣,重要的是有時您有一個不是嵌入研發部門的安全小組,比如CTO組織。

有時,在許多組織中,我們會發現安全小組和CTO組織之間存在孤立的情況,您會發現許多流程都是在事後完成的。 例如,我們遇到了這樣一種情況:我們發布了大量產品,發布了大量代碼,因為安全團隊和工程團隊之間沒有強大的通信協作。

您最終得出的結論是,組織必須遵守法規。 有時,具體的例子是您有團隊每年進行一次或兩次掃描。 這些掃描的結果是什麼? 我會被告知,“嘿Richard,我們下一季度不得不放慢腳步,因為我們發現了一百個不同的大小安全漏洞,你知道,也許,像20個,像前20個中的嚴重級別1和2及以上,而其他的,你知道,你必須專注於修復這些問題。”

組織內部有一個SLA供您修復,結果是這樣做,您基本上只是按照我的路線圖進行,而您只需將它們提交到下一季度。 因此,通過不向左移動,不真正地將這一流程落實到位,只是在右側做這些事情,我們基本上是在推動我們的路線圖,即創收交付物,這可能有助於拓展我們的業務。 我們可能會將其正確地移動,這樣我們就可以在事後花費四分之一的時間來緩解這些問題。

這就是為什麼我說,對於組織和企業來說,如果想要將路線圖項目每季度進行一次調整,那麼成本就會非常高。 因此,您的新產品,特性和功能的所有發布計劃都必須改變,對嗎? 因爲您並沒有離開練習場。

其中一些內容可以通過更好的協作來改進,尤其是組織內的應用程式安全團隊與開發團隊之間的協作。 這就是為什麼我們看到許多組織開始擁有這一新概念的原因。 大家都聽說過HR BP,HR業務合作夥伴,這些合作夥伴都嵌入了不同的業務部門。

現在有一個應用程式安全BP的概念。 因此,您將開始聽到這些術語,例如APP SEC BP,這些術語可能會在您有員工工作的情況下變成實踐。 幾乎就像工程團隊的半嵌入式經理一樣,確保他們在開發工作流程的每個步驟中提供正確的指導,工具和流程,例如,實施軟體組合分析,實施安全ID,實施所有黑白任務,在整個過程中確保我們能夠在開發生命週期的早期捕獲這些問題。

Michael Grimshaw:我愛這一切。 問得好,Lauren。 我喜歡你剛纔說的一切,理查德。 因爲這會產生成本。 你知道,如果人們,如果有人在產品中聽到聲音,等待,如果我向左移動,我就不必向右移動我的路線圖。

這就是他們耳朵的音樂。 但對於CFO,甚至是營運或其他業務領域,您可能會說,好吧,這會帶來什麼影響? 影響巨大。 您只是跪在銷售部門。 您影響了您的客戶,因爲您遇到了大量客戶,尤其是在安全方面。 我知道在平臺方面,當我與我的供應商交談時,我想知道路線圖是什麼,因為,好吧,也許我必須找我的審計員,我需要得到補償控制,直到您發布路線圖上的內容。 如果你剛纔告訴我,好的,我預期在一個季度內交付的內容將是四分之三。 我將開始研究其他供應商。 為什麼? 因為我對我的審計員負有義務,我必須履行這些義務。

Richard,我也很喜歡你提出的審計員和合規流程。 這是勞倫的另一個例子,它說明了孤島化可以從根本上打擊一切的地方。

如果您正處於PCI,SOC,ISO,FedRAMP等各種合規性框架的中間,並且您還沒有真正集成,您仍然在營運避難心態,您可能會有一個合規性或資訊安全的人員與您的審計員交談,他們將不得不通過一兩層轉換到工程方面,希望工程方面能夠實施所有計劃,然後這只是為了實施。 然後,所有證據和掃描以及您需要提供給他人的一切,祝你好運。

如果這一點真的可以轉化為現實,我們都玩過小學的舊傳聞遊戲,這是一種類似的功能,如果您有與審計員合作的集成團隊,他們會立即知道如何將這種技術轉化為特定技術,並且您已經進行了掃描,您可以立即將它轉到規則集中,並在與審計員會面時進行實時掃描和驗證。 所有證據都在這裏。 這是一個徹底改變遊戲規則的人。 它使您能夠更快地向客戶交付產品,而不是像Richard所說的那樣,現在就改變您的路線圖。

Lauren Bradley:是的。 因此,為了更具體地了解這一點,我的意思是,CISO和AppSec領導者如何量化其指標來了解成本影響,甚至只是總體成功?

Richard Yew:你知道,這很有趣,因為我們談論了為什麼,你知道,但讓我們更深入地了解一下如何,因為我知道,這是我們許多觀眾的目標。 我們不是爲了給您蓬鬆,高層次的陳述。 我們希望在這裡提供的是一點價值,具體涉及到如何實施這一點。

也許我們可以彈出我們擁有的DevSecOps圖表,然後我們就可以簡單地了解如何優化步驟。 好的。 您可以看到傳統的安全測試,就像是線性執行的,對吧? 它就像我們談論瀑布一樣,就像你的計劃,你有,美麗,測試,對吧?

在操作員監控階段進行了許多安全測試。 因此,它位於右側。 所以,現在新的概念是,如果我們繼續下一幅圖片,對吧? 您可以在此圖表中找到100種不同的變種。 比如,當您今天只使用Google DevSecOps時,就像Mike之前所說的那樣,這個概念已經存在了7年,對吧? 您知道有些組織可能不稱之為這種週期。 有些組織只是稱之為AppSec,對吧? 因此某些組織會將其稱為安全管道。 因此,這是安全管道代表什麼的粗略表述。 對吧? 所以,從一開始,您就處於規劃階段,對吧?

您有威脅建模威脅分析。 在設計解決方案時,您會嘗試確保在所有這些建模中都能做到這一點。 因此,當您進行編碼時,當您進入第二個階段,即您的編碼階段,對吧? 您想要確保您已掛鉤。 您希望確保您擁有一個安全的IDE,因為開發人員在編寫代碼時實際上實時捕獲了一些問題。 顯然,這不是一顆銀子,對吧? 但它是一個額外的層,我們討論的是深度防禦週期中的額外層。 現在,隨著我們在這一過程中不斷前進,對吧? 一旦您承諾使用代碼,對吧? 您希望確保您擁有一個流程–誰能夠提供對所有代碼的靜態掃描,以確保他們檢查自動依賴性,供應鍊,漏洞等,以及軟體補償分析,以創建一個軟體視圖,顯示您使用的軟體版本? 他們多少歲?

因為,我不帶你開玩笑,我只是在一兩周前讀到了一項統計數據,Apache Log4j的下載量中有25%仍然存在漏洞。 這讓我感到困惑的是,現在我們已經將近兩年了。 我不知道,從12月初宣布第一個Apache Log4j零日漏洞到現在,是兩年還是三年? 是2021年嗎? 因此,我們需要專注於做得更好,並進行這種軟體對話/分析,以確保您確切了解所執行的軟體版本。

這很重要。 那麼,我們就開始測試了,對吧? 您想要確保您有內部測試,您已經實施了動態測試以確保這一點。 我們能夠測試正在執行的應用程式,並查看是否存在任何可被利用的漏洞。

你知道這通常是通過模糊完成的。 現在,在傳統DevSecOps週期中,這裡沒有顯示什麼? 因為這一切看起來都是相當標準的行業實踐,對吧? 隨著我們一路向右部署,監控和響應。 過去,您會將Web應用程式防火牆,爬蟲程序管理器,API安全,以及他們的所有Web應用程式API保護解決方案置於響應和監控階段,對吧? 當您監控生產流量時,您可以確保不會利用。

但需要考慮的是實際移動您已有的一些Web應用程式API保護。 同時將它們向左移動。 在這種情況下,戴上它們,在圖片中,這是向前邁出的一步。 當您正在進行動態應用程式安全測試時,請將其置於測試階段,對嗎? 爲什麼不通過生產安全機制對它們進行測試? 因此,您知道代碼之間存在多少漏洞,其中多少漏洞可以緩解,因為重要的是,我們總是嘗試通過實際加快開發工作來改善當前應用程式週期的生命週期。 當您在測試期間發現安全漏洞時,通常的做法是基本上停止列車。 你回來了,對吧? 您修復了代碼,然後重新發布它們。 您再次完成八個步驟。 但如果我告訴您,也許有辦法讓您說:“嘿,我們不要停止火車?”

讓我們繼續訓練。 讓我們通過在第四步之前對安全解決方案進行一次額外的測試來發布這一點,這樣您就可以提前清楚地知道在生產中要進行哪些虛擬修補,這樣您就不必停止火車了。 讓你的火車繼續前進。 您保持自己的速度。

您發布了帶有虛擬修補程序的代碼來緩解漏洞,然後在下一個週期修復它們,希望這一週期能很快完成。 這也是其中一種方法,我們希望通過創新的方法來教育和與客戶合作,努力改進現有的CICD安全工作流。

Michael Grimshaw:我喜歡,Richard。 我愛你稱之為拉出這個事實,把它拉到左邊。 因此,如果您的遊戲計劃是,哦,讓我們將其投入生產,然後我們就會擔心這一問題。 您將遇到一些問題,並且有一些可以緩解的方法,可以在開發,部署和操作過程中涵蓋您的後端。 我喜歡你在那裡所說的。 我想說,一個類似的比喻,就像混亂猴。 這就是問題。 如果您有Chaos Monkey在生產中工作,而您處理Chaos Monkey的唯一時間是在生產中時,您將會遇到可怕的開發和操作經驗。

您必須在生產之前就對其進行規劃,設計和設計。 否則,您將陷入苦難。

量化指標以了解成本影響和成功

Richard Yew:是的,Lauren,我想回答前面提到的問題,我們現在如何衡量成功,現在我們只要看看整個DevSecOps生命週期,以及如何優化它。 什麼是最佳實踐,對吧?

很快。 所以我們要跟蹤成功。 因此,您顯然需要能夠量化成功。 對。 因此,如果您是安全性領導者,並且您正在嘗試衡量應用程式安全性計畫的成功程度,您可以看看其中的一件事,您的應用程式涵蓋範圍有多大,對嗎?

例如,您的組織中是否有超過90/95%的應用程式或面向網際網路的應用程式都屬於同一流程? 您是否具有相同的標準化流程? 對。 包括軟體組合,分析,SAS,測試,測試,測試,測試,測試等一切,如Web應用程式,API保護。

您是否準備好了這些東西來保持跟蹤覆蓋範圍? 您多長時間釋放一次?多長時間必須回滾一次? 由於您檢測到的安全漏洞在哪個階段,您必須在生產階段回滾一次,而您知道,在代碼提交階段回滾的頻率是多久,在該階段,由於明顯回滾生產,您需要執行靜態分析。

這比在進行一點靜態代碼分析後修復代碼要昂貴得多。 對。 另外兩個統計數據,你肯定想測量,就像Lauren前面提到的那樣。 檢測我們稱之為MTTD的行業平均平均時間為200天。 因此,我相信,通過右移向左流程,您可以在這段時間內大幅縮短檢測時間,縮短檢測時間。 因此,嘗試將度量彙集在一起,以檢測從漏洞披露到檢測組織內部的那些建築物需要多長時間。

同時實施應對措施,對吧? 同時解決決議問題,對吧? 行業平均爲70天,因此發現漏洞後70天,對吧? 利用此漏洞的組織平均需要70天的時間才能解決此問題。 但是,通過這種開始跟蹤,您可以多快地解決這些問題? 當您在軟體組合分析中使用代碼找到J的易受攻擊的日誌版本時,您可以多快地用防火牆對其進行虛擬修補,或者多快地更新庫以使用不同的軟體,對吧? 因此,在一個非常成熟的組織中,我已經與一些組織談過,他們實際上有四個小時的平均時間來解決log4j事件。

這讓人印象深刻。 這說明他們DevSecOps流程的成熟度。 所以,我看過所有種類。 我還看到客戶組織有幾個星期甚至幾個月的時間來解決log4j等關鍵問題。 因此,當您嘗試從整體上改進流程時,務必牢記這些指標。

Michael Grimshaw:還有一些我想介紹的其他KPI,比如在平臺方面,當您處理基礎架構或在許多情況下處理任何工程時,成本一直是其中的一個重要因素。 但是在過去幾年裡利率不斷上升的情況下,問題是風險投資資金,其中很多資金都在枯竭,但遊戲的名稱和利率上升的環境卻是一種非常有利的競爭。

這裡有一個方面。 我喜歡這種技術。 顯然,平臺工程總監。 我喜歡技術方面,但特別是在過去幾年中,如果您在平臺上工作,就像我所說的那樣,基礎設施和類似的事情,財務方面以及向首席財務官和首席技術官澄清和提供反饋的工作已經成為當務之急。

KPI是關於成本和收入的,這是另一個重要方面。 我只想強調一些像這樣的事情,例如,在收入方面。 如果您正在進行紅線討論,如果您的客戶想購買您的產品,但您的產品,您將經歷一條安全紅線,因爲每個人都會考慮安全問題,而您的客戶希望確保他們得到保護。

他們希望儘量降低風險。 如果你帶著老派的心態來找他 哦,是的,我們開發了東西,然後我們讓我們確保資訊安全掃描這些東西和所有這些東西。 我已經參加過很多紅線討論和合同討論,但這只是不再飛了。

在過去五年中,客戶風險部門和法律部門的調查問卷和調查問卷的詳細程度已經達到了其他級別,更不用說10年了。 此外,還能擁有完全集成的左移位解決方案,以獲得Web應用程式和API保護–所有這些都是如此。 當您與其他人的律師交談時,這會大大地移動針頭。 這是什麼意思? 這意味著您可以更快地完成交易。 如果您沒有練習左班,或者只是將資訊安全作為附加產品,我建議您回頭看看您的成交率和分解情況,並特別關注安全紅線討論,因為這些類型的產品問題經常被視為成本中心。 但他們可以解除收入的限制,並且可以為您節省大量資金。

在播客的前面,我們討論了大量成本節約,包括內部成本,但我認為,在這方面,Beta版的收入是非常重要的,因為在這個利率不斷上升的世界中,這是許多人關注的問題。

總結

李察耀:這是一個很好的地方。 我很高興我們換了一下帽子,就像戴上SDLC帽子,戴上您的商務帽子。 好極了。 我希望我們分享的所有這些東西都能為我們的受眾帶來一些價值。

Lauren Bradley:非常感謝你們。 我認為這是一個很好的結尾。 我們已經介紹了向左移動的重要性,以及如何將Web應用程式和API保護有效地融入DevOps生命週期。 當然,如何有效衡量成功。 誤報率是否較低? 您的平均時間解析度是多少? 您發貨軟體的速度有多快? 您是否獲得了更多收入?

所有這些指標都是企業成功的關鍵。 因此,我感謝Michael和Richard今天與我一起參加。 這是一次非常愉快的經歷,同時也感謝我們的觀眾參加了Beyond the Edge大會。 我們將在下一集見到您。