Categories
程式開發

是時候構建安全服務平台了


安全開發生命週期能夠確保應用程序具備充足的安全性,而自動化是推行它的一個重要手段。不少企業的安全團隊已經在這方面進行了很多努力,但也面臨著新的挑戰。比如重複建設、實施質量良莠不齊、信息分散、沒有形成閉環等等。安全服務平台是這個困境的破局者。

1. 自動化是解決S-SDLC落地難的重要途徑之一,但這件事本身也存在挑戰

為提高軟件的安全性,在企業中實施 安全軟件開發生命週期 (下文簡稱S-SDLC)是必然的選擇。自動化為企業推動S-SDLC提供了有力支持,可以很大程度上降低S-SDLC中各項安全活動的實施難度,從而使得開發團隊願意主動的落地執行這些安全活動。典型的例子就是自動化源碼安全掃描。

不少企業已經在自動化這條路上做出了很多努力,效果當然是有的,但是自動化僅僅只是起步,還有更多挑戰等著企業來解決,比如下面這些:

  • 各個團隊使用的安全工具的版本、掃描規則不一致,以至於同一種安全活動的產出物質量參差不齊。
  • 運行頻率沒保障。有可能是臨到審計前趕緊運行一下。
  • 覆蓋面不全。有些團隊用的自動化安全工具多,有些團隊可能一個都沒用。
  • 升級維護難。由於是開發團隊自行使用自動化安全工具,因此要對其進行升級、維護,也只能由開發團隊來實施,如此一來,什麼時候能完成升級、維護,在很大程度上就取決於開發團隊的配合程度了。
  • 重複建設,用完就扔。每當啟動一個項目,或者開始構建一個新應用,就得把那些安全工具重新配置一遍。項目結束開發後,這些工具也就被廢棄了。雖說是一次配置多次使用,而且一個團隊每次花在配置上的時間也不算多,但站在公司的角度來看,可能每天都有不同的開發團隊在做著差不多相同的事情,重複建設的問題會更加明顯。
  • 信息分散。開發團隊通常會使用好幾個不同的工具,而這些工具所產出的結果就會比較分散,不利於開發團隊、安全團隊整體把握應用的安全現狀。
  • 安全活動沒有形成閉環。自動化的工具倒是有了,但工具所產出的結果往往就那麼靜悄悄的躺在某個角落裡,少有人問津,只有在面臨安全審計、安全檢查的時候才會被翻出來交差。

久而久之,自動化所帶來的紅利也逐漸被這些挑戰所吞噬,甚至對於使用自動化來解決S-SDLC落地難的信心也開始了動搖。

2. 破局者:安全服務平台

什麼是安全服務平台?我們先不急著看它的定義,我們先來看看下面幾個場景,感性的認識一下安全服務平台。

場景1

開發團隊在公司統一搭建的持續交付流水線里新建了一個項目,隨後驚喜的發現流水線裡默認已經有了好幾個安全環節,無需開發團隊再做任何額外的搭建和集成工作:

  • 自動化源碼安全掃描會在每次檢測到有新代碼提交時自動觸發,更關鍵的是,掃描結果能在持續交付流水線裡直接看到,並且可以對報告的問題直接進行標註處理
  • 第三方組件安全掃描,和源碼安全掃描類似,只是運行頻率是每天晚上定時執行,並且在發現問題時提示開發團隊
  • 持續交付流水線中,部署應用程序到測試環境這個步驟中,默認加入了黑盒安全掃描。每當部署一個新版本到測試環境,掃描就會進行一次,發現的問題不僅能在持續交付流水線裡看到,還能一鍵創建工單,方便的對問題進行追踪

場景2

分析業務需求中有哪些安全風險,這項活動對業務分析師而言挑戰太大,但他/她發現用JIRA管理起來的用戶故事卡里,有一部分故事卡中自動出現了一些安全風險提示。這是安全服務平台基於用戶故事卡中的業務和技術上下文自動推斷出來的,提醒開發團隊對安全進行必要的考慮。

場景3

某天,開發團隊的項目經理和安全團隊同時收到了一條短信,提示說檢測到了源碼及密鑰洩露。這是安全服務平台自動發送的報警提醒,原因是安全服務平台檢測到了開發團隊中的某位同事的個人Github賬號下的公開代碼倉庫裡,發現了公司的源代碼,還有一些內部服務器的賬號和密碼。

場景4

有一個類似於數據駕駛艙的Web頁面近實時的呈現了當前整個企業中所有開發團隊已經開展了的安全活動。查看這個頁面的是安全團隊,他們能從這些可視化後的數字錶盤裡,輕鬆的掌控各個開發團隊S-SDLC的實施情況。

與此同時,當前整個企業範圍內有哪些開發團隊“編碼出來的”安全漏洞、危害級別如何、是否得到修復等等信息也是一目了然。應用安全風險是在趨於收斂還是滑向失控的邊緣,安全團隊也能得到更好的了解。

安全服務平台的定義

雖然還有更多安全服務平台的使用場景,但這不妨礙我們給出關於安全服務平台的定義了。安全服務平台,核心是對多種安全工具、服務進行統一封裝,並通過API或UI交互,以及融入交付基礎設施等途徑,向開發團隊提供便捷易用的安全服務集合。這些通過安全服務平台而提供出來的安全服務集合,貫穿了軟件開發的完整生命週期,從需求分析和技術設計,一直到上線運營及運維。與此同時,安全服務平台也服務於安全團隊,向其提供一系列安全管理服務。

3. 為什麼需要安全服務平台

之所以說安全服務平台是目前推行S-SDLC的困境的破局者,是因為它所創造出來的獨特的價值:

(1)提供開箱即用的安全服務,在把使用門檻降至最低。

經常聽到有安全團隊抱怨說,開發團隊並不是真正的重視安全,不然為何那些明明對開發團隊有好處的安全活動,到最後他們都不做呢?還有的安全團隊使勁猛推S-SDLC,結果推得開發團隊繞著安全團隊走,唯避之而不急。

其實並不是開發團隊對安全漠不關心,也不是他們有意躲著安全團隊,他們的內心其實也是希望看到自己開發出來的應用程序的安全性足夠高,只是開發團隊有一個隱藏的要求:不管做什麼安全活動,以及怎麼做這些安全活動,實施成本必須足夠低,低到開發團隊認為這不會影響交付速度,不會導致lead time的增加。

把安全活動自動化是一個很好的開始,但這不是終點,開發團隊的需求並沒有得到很好的滿足。儘管一些安全活動(例如自動化源碼安全掃描)已經高度自動化了,但是在開發團隊還是免不了要做一些搭建或者配置工作。這一點點看似微不足道的時間消耗或者精力投入,就猶如軟件發布最後1公里這個問題一樣,阻礙了安全活動最終的落地實施。

安全服務平台秉承了自動化的理念,並且把其發揮到了極致,通過技術手段直接幫開發團隊搭建、配置好安全工具,如此一來造就了開箱即用的服務,對開發團隊而言使用成本直接降到了0,使用這個安全服務的意願和動力一下就充足了起來。還是以自動化源碼安全掃描為例,當開發團隊新建一條流水線的時候,默認直接就有安全源碼掃描環節,無需配置,直接運行查看結果即可。

(2)減少甚至避免了重複建設

一個開發團隊搭建一套安全掃描系統,N個開發團隊就會搭建N套安全掃描系統,儘管可以通過自動化腳本來加速這個過程,但從資源的使用角度來看,始終存在重複建設的問題。

安全服務平台對安全工具進行了封裝,統一對開發團隊提供服務,這使得開發團隊無需再自己搭建一套安全掃描系統,避免了系統的重複建設。

(3)是安全信息集散中心,且形成信息閉環

安全服務平台提供了多種安全服務,並且把這些服務的運行結果統一匯集起來,讓開發團隊能夠更加方便的在一個地方查閱到自己所構建的應用程序的安全性。

更進一步,安全服務平台還能把各項安全服務的運行結果反饋回持續交付流水線,這使得開發團隊能夠在第一時間知曉安全活動的結果,並及時的做出處理。這樣的做法能夠幫助開發團隊形成安全信息閉環,構建出一個正向良性的反饋環路。

(4)提供多維度的信息可視化,便於安全團隊追踪管理、推動S-SDLC中各項活動的開展

儘管S-SDLC提倡賦能開發團隊,讓開發團隊以自驅動的方式去開展各項安全活動,但這些安全活動到底有沒有開展?開展的效果怎麼樣?有沒有遇到什麼困難或者異常情況?這些信息在以前只能靠安全審計,或者安全團隊主動去追問才能得知,而且得到的答案可能也比較模糊。

而安全服務平台由於記錄下了各個開發團隊、各項安全活動的詳細運行數據,通過可視化等手段能夠向安全團隊提供更加精準的數據反饋,使得安全團隊能夠獲得數據支撐,以便於持續改進優化S -SDLC的推行計劃。

(5) 集中管理,易於維護

安全服務平台統一封裝了各種安全工具或者第三方安全服務,因此對這些工具或服務做維護也變得更加容易操作。比如,某個安全工具需要進行版本升級,原先只能以發送通知的方式告訴開發團隊盡快完成升級,但開發團隊是否及時響應就不能很好的控制了,而且如果某些開發團隊並沒有使用這款安全工具,那麼這樣的通知對他們而言也是信息噪音。現如今,只需安全團隊將安全服務平台所封裝的這個工具進行升級,那麼所有通過平台使用這款工具的開發團隊無需做任何操作,便能直接享受升級後的功能。同理,對於安全掃描規則的更新也是類似的過程,將變得更加易於維護。

當我們了解了安全服務平台的這些獨特價值之後,讓我們再回過頭來看看之前提到的那些新冒出來的挑戰,你會發現通過安全服務平台都能得到比較好的解決:

  • 安全服務平台提供統一的工具版本和掃描規則,安全活動的質量更有保障,同時也使得對工具和規則的升級維護變得更加容易
  • 類似於自動化源碼安全掃描的安全活動的運行頻率,儘管可以由開發團隊進行自定義,但也可以由安全服務平台設置最低可接受頻率,因此相關安全活動的執行頻率也能得到保障
  • 安全服務平台所提供的部分安全服務直接集成到了持續交付流水線,變成了默認就有的環節,這使得更多的開發團隊能夠輕鬆便捷的把S-SDLC中的安全實踐做起來
  • 安全服務平台提供開箱即可用的安全服務,此舉將開發團隊所需要做的工具類建設活動的成本降至最低。與此同時,對於不同的開發團隊而言,他們是對安全服務平台所提供的安全服務進行分時復用,因此重複建設的問題也不復存在
  • 安全服務平台將眾多安全工具和服務匯集在一起,同時也就把各項安全活動的產出物也都集中到了一起。這既有助於開發團隊更全面的了解自己正在構建的應用程序的安全狀況,又便於安全團隊把握整個企業範圍內的眾多應用程序的安全狀況
  • 通過安全服務平台提供了兩個信息閉環:(1)通過平台開展的安全活動,相關產出物(典型的如發現的安全漏洞)會通過持續交付流水線、郵件短信等方式及時反饋回開發團隊,促進安全問題的修復;(2)安全團隊推薦或要求開發團隊執行的安全活動,到底有沒有被執行,執行的情況怎麼樣,在沒有安全服務平台時,只能通過內部安全審計、安全檢查,甚至動用安全團隊成員的私人關係來了解。而一旦安全活動通過平台開展,必然會在平台上留下各種數據,那麼借助數據可視化等手段,安全團隊就可以方便的獲取到以及追踪安全活動的開展情況,並基於此不斷推動安全活動落地執行,提高活動實施效果。

4. 小結

S-SDLC,也即安全開發生命週期能夠確保應用程序具備充足的安全性,而自動化是推行S-SDLC的一個重要手段。不少企業的安全團隊已經在這方面進行了很多努力,但也面臨著新的挑戰。比如重複建設、實施質量良莠不齊、信息分散、沒有形成閉環等等。

安全服務平台是這個困境的破局者,它封裝了一系列安全工具和第三方安全服務,並通過多種方式統一的向開發團隊提供便捷的安全服務,使得開發團隊更有意願落地實施S-SDLC中的安全活動。並且安全服務平台還為安全團隊的管理提供了支持。

既然安全服務平台如此優秀,那麼該如何構建這樣的平台呢?有沒有什麼核心原則需要考慮?有沒有什麼前提條件?它似乎有多種服務提供形式,那到底有哪幾種呢?除了S-SDLC相關的安全服務外,平台還可融入其他安全功能嗎?這些問題我們留著下篇文章為大家詳細解答。

本文轉載自公眾號ThoughtWorks洞見(ID:TW-Insights)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MjM5MjY3OTgwMA==&mid=2652468388&idx=1&sn=8e79e7b5aca43a9c619175fe6f469bbf&chksm=bd4f46b38a38cfa541916c95cc8424f436136a5a8a40c126e138771bc518f2f3d557283ccff4&scene=27#wechat_redirect