1. 自動化是解決S-SDLC落地難的重要途徑之一褥影，但這件事本身也存在挑戰(zhàn)
為提高軟件的安全性，在企業(yè)中實施安全軟件開發(fā)生命周期（下文簡稱S-SDLC)是必然的選擇咏雌。自動化為企業(yè)推動S-SDLC提供了有力支持凡怎，可以很大程度上降低S-SDLC中各項安全活動的實施難度校焦，從而使得開發(fā)團隊愿意主動的落地執(zhí)行這些安全活動。典型的例子就是自動化源碼安全掃描统倒。
不少企業(yè)已經在自動化這條路上做出了很多努力寨典，效果當然是有的，但是自動化僅僅只是起步房匆，還有更多挑戰(zhàn)等著企業(yè)來解決耸成，比如下面這些：
- 各個團隊使用的安全工具的版本、掃描規(guī)則不一致浴鸿，以至于同一種安全活動的產出物質量參差不齊井氢。
- 運行頻率沒保障。有可能是臨到審計前趕緊運行一下岳链。
- 覆蓋面不全花竞。有些團隊用的自動化安全工具多，有些團隊可能一個都沒用宠页。
- 升級維護難左胞。由于是開發(fā)團隊自行使用自動化安全工具，因此要對其進行升級举户、維護烤宙，也只能由開發(fā)團隊來實施，如此一來俭嘁，什么時候能完成升級躺枕、維護，在很大程度上就取決于開發(fā)團隊的配合程度了供填。
- 重復建設拐云，用完就扔。每當啟動一個項目近她，或者開始構建一個新應用叉瘩，就得把那些安全工具重新配置一遍。項目結束開發(fā)后粘捎，這些工具也就被廢棄了薇缅。雖說是一次配置多次使用，而且一個團隊每次花在配置上的時間也不算多攒磨，但站在公司的角度來看泳桦，可能每天都有不同的開發(fā)團隊在做著差不多相同的事情，重復建設的問題會更加明顯娩缰。
- 信息分散灸撰。開發(fā)團隊通常會使用好幾個不同的工具，而這些工具所產出的結果就會比較分散，不利于開發(fā)團隊浮毯、安全團隊整體把握應用的安全現狀完疫。
- 安全活動沒有形成閉環(huán)。自動化的工具倒是有了亲轨，但工具所產出的結果往往就那么靜悄悄的躺在某個角落里趋惨，少有人問津，只有在面臨安全審計惦蚊、安全檢查的時候才會被翻出來交差器虾。
久而久之，自動化所帶來的紅利也逐漸被這些挑戰(zhàn)所吞噬蹦锋，甚至對于使用自動化來解決S-SDLC落地難的信心也開始了動搖兆沙。
2. 破局者：安全服務平臺
什么是安全服務平臺？我們先不急著看它的定義莉掂，我們先來看看下面幾個場景葛圃，感性的認識一下安全服務平臺。
場景1
開發(fā)團隊在公司統(tǒng)一搭建的持續(xù)交付流水線里新建了一個項目憎妙，隨后驚喜的發(fā)現流水線里默認已經有了好幾個安全環(huán)節(jié)库正，無需開發(fā)團隊再做任何額外的搭建和集成工作：
- 自動化源碼安全掃描會在每次檢測到有新代碼提交時自動觸發(fā)，更關鍵的是厘唾，掃描結果能在持續(xù)交付流水線里直接看到褥符，并且可以對報告的問題直接進行標注處理
- 第三方組件安全掃描，和源碼安全掃描類似抚垃，只是運行頻率是每天晚上定時執(zhí)行喷楣，并且在發(fā)現問題時提示開發(fā)團隊
- 持續(xù)交付流水線中，部署應用程序到測試環(huán)境這個步驟中鹤树，默認加入了黑盒安全掃描铣焊。每當部署一個新版本到測試環(huán)境，掃描就會進行一次罕伯，發(fā)現的問題不僅能在持續(xù)交付流水線里看到曲伊，還能一鍵創(chuàng)建工單，方便的對問題進行追蹤
場景2
分析業(yè)務需求中有哪些安全風險追他，這項活動對業(yè)務分析師而言挑戰(zhàn)太大熊昌，但他/她發(fā)現用JIRA管理起來的用戶故事卡里，有一部分故事卡中自動出現了一些安全風險提示湿酸。這是安全服務平臺基于用戶故事卡中的業(yè)務和技術上下文自動推斷出來的，提醒開發(fā)團隊對安全進行必要的考慮灭美。
場景3
某天推溃，開發(fā)團隊的項目經理和安全團隊同時收到了一條短信，提示說檢測到了源碼及密鑰泄露届腐。這是安全服務平臺自動發(fā)送的報警提醒铁坎，原因是安全服務平臺檢測到了開發(fā)團隊中的某位同事的個人Github賬號下的公開代碼倉庫里蜂奸，發(fā)現了公司的源代碼，還有一些內部服務器的賬號和密碼硬萍。
場景4
有一個類似于數據駕駛艙的Web頁面近實時的呈現了當前整個企業(yè)中所有開發(fā)團隊已經開展了的安全活動扩所。查看這個頁面的是安全團隊，他們能從這些可視化后的數字表盤里朴乖，輕松的掌控各個開發(fā)團隊S-SDLC的實施情況祖屏。
與此同時，當前整個企業(yè)范圍內有哪些開發(fā)團隊“編碼出來的”安全漏洞买羞、危害級別如何袁勺、是否得到修復等等信息也是一目了然。應用安全風險是在趨于收斂還是滑向失控的邊緣畜普，安全團隊也能得到更好的了解期丰。
安全服務平臺的定義
雖然還有更多安全服務平臺的使用場景，但這不妨礙我們給出關于安全服務平臺的定義了吃挑。安全服務平臺钝荡，核心是對多種安全工具、服務進行統(tǒng)一封裝舶衬，并通過API或UI交互埠通，以及融入交付基礎設施等途徑，向開發(fā)團隊提供便捷易用的安全服務集合约炎。這些通過安全服務平臺而提供出來的安全服務集合植阴，貫穿了軟件開發(fā)的完整生命周期，從需求分析和技術設計圾浅，一直到上線運營及運維掠手。與此同時，安全服務平臺也服務于安全團隊狸捕，向其提供一系列安全管理服務喷鸽。
3. 為什么需要安全服務平臺
之所以說安全服務平臺是目前推行S-SDLC的困境的破局者，是因為它所創(chuàng)造出來的獨特的價值：
（1）提供開箱即用的安全服務灸拍，在把使用門檻降至最低做祝。
經常聽到有安全團隊抱怨說，開發(fā)團隊并不是真正的重視安全鸡岗，不然為何那些明明對開發(fā)團隊有好處的安全活動混槐，到最后他們都不做呢？還有的安全團隊使勁猛推S-SDLC轩性，結果推得開發(fā)團隊繞著安全團隊走声登，唯避之而不急。
其實并不是開發(fā)團隊對安全漠不關心，也不是他們有意躲著安全團隊悯嗓，他們的內心其實也是希望看到自己開發(fā)出來的應用程序的安全性足夠高件舵，只是開發(fā)團隊有一個隱藏的要求：不管做什么安全活動，以及怎么做這些安全活動脯厨，實施成本必須足夠低铅祸，低到開發(fā)團隊認為這不會影響交付速度，不會導致lead time的增加合武。
把安全活動自動化是一個很好的開始临梗，但這不是終點，開發(fā)團隊的需求并沒有得到很好的滿足眯杏。盡管一些安全活動（例如自動化源碼安全掃描）已經高度自動化了夜焦，但是在開發(fā)團隊還是免不了要做一些搭建或者配置工作。這一點點看似微不足道的時間消耗或者精力投入岂贩，就猶如軟件發(fā)布最后1公里這個問題一樣茫经，阻礙了安全活動最終的落地實施。
安全服務平臺秉承了自動化的理念萎津，并且把其發(fā)揮到了極致卸伞，通過技術手段直接幫開發(fā)團隊搭建、配置好安全工具锉屈，如此一來造就了開箱即用的服務荤傲，對開發(fā)團隊而言使用成本直接降到了0，使用這個安全服務的意愿和動力一下就充足了起來颈渊。還是以自動化源碼安全掃描為例遂黍，當開發(fā)團隊新建一條流水線的時候，默認直接就有安全源碼掃描環(huán)節(jié)俊嗽，無需配置雾家，直接運行查看結果即可。
（2）減少甚至避免了重復建設
一個開發(fā)團隊搭建一套安全掃描系統(tǒng)绍豁，N個開發(fā)團隊就會搭建N套安全掃描系統(tǒng)芯咧，盡管可以通過自動化腳本來加速這個過程，但從資源的使用角度來看竹揍，始終存在重復建設的問題敬飒。
安全服務平臺對安全工具進行了封裝，統(tǒng)一對開發(fā)團隊提供服務芬位，這使得開發(fā)團隊無需再自己搭建一套安全掃描系統(tǒng)无拗，避免了系統(tǒng)的重復建設。
（3）是安全信息集散中心昧碉，且形成信息閉環(huán)
安全服務平臺提供了多種安全服務蓝纲，并且把這些服務的運行結果統(tǒng)一匯集起來阴孟，讓開發(fā)團隊能夠更加方便的在一個地方查閱到自己所構建的應用程序的安全性。
更進一步税迷，安全服務平臺還能把各項安全服務的運行結果反饋回持續(xù)交付流水線，這使得開發(fā)團隊能夠在第一時間知曉安全活動的結果锹漱，并及時的做出處理箭养。這樣的做法能夠幫助開發(fā)團隊形成安全信息閉環(huán)，構建出一個正向良性的反饋環(huán)路哥牍。
（4）提供多維度的信息可視化毕泌，便于安全團隊追蹤管理、推動S-SDLC中各項活動的開展
盡管S-SDLC提倡賦能開發(fā)團隊嗅辣，讓開發(fā)團隊以自驅動的方式去開展各項安全活動撼泛，但這些安全活動到底有沒有開展？開展的效果怎么樣澡谭？有沒有遇到什么困難或者異常情況愿题？這些信息在以前只能靠安全審計，或者安全團隊主動去追問才能得知蛙奖，而且得到的答案可能也比較模糊潘酗。
而安全服務平臺由于記錄下了各個開發(fā)團隊、各項安全活動的詳細運行數據雁仲，通過可視化等手段能夠向安全團隊提供更加精準的數據反饋仔夺，使得安全團隊能夠獲得數據支撐，以便于持續(xù)改進優(yōu)化S-SDLC的推行計劃攒砖。
（5） 集中管理缸兔，易于維護
安全服務平臺統(tǒng)一封裝了各種安全工具或者第三方安全服務，因此對這些工具或服務做維護也變得更加容易操作吹艇。比如惰蜜，某個安全工具需要進行版本升級，原先只能以發(fā)送通知的方式告訴開發(fā)團隊盡快完成升級掐暮，但開發(fā)團隊是否及時響應就不能很好的控制了蝎抽，而且如果某些開發(fā)團隊并沒有使用這款安全工具，那么這樣的通知對他們而言也是信息噪音÷房耍現如今樟结，只需安全團隊將安全服務平臺所封裝的這個工具進行升級，那么所有通過平臺使用這款工具的開發(fā)團隊無需做任何操作精算，便能直接享受升級后的功能瓢宦。同理，對于安全掃描規(guī)則的更新也是類似的過程灰羽，將變得更加易于維護驮履。
當我們了解了安全服務平臺的這些獨特價值之后鱼辙，讓我們再回過頭來看看之前提到的那些新冒出來的挑戰(zhàn)，你會發(fā)現通過安全服務平臺都能得到比較好的解決：
- 安全服務平臺提供統(tǒng)一的工具版本和掃描規(guī)則玫镐，安全活動的質量更有保障倒戏，同時也使得對工具和規(guī)則的升級維護變得更加容易
- 類似于自動化源碼安全掃描的安全活動的運行頻率，盡管可以由開發(fā)團隊進行自定義恐似，但也可以由安全服務平臺設置最低可接受頻率杜跷，因此相關安全活動的執(zhí)行頻率也能得到保障
- 安全服務平臺所提供的部分安全服務直接集成到了持續(xù)交付流水線，變成了默認就有的環(huán)節(jié)矫夷，這使得更多的開發(fā)團隊能夠輕松便捷的把S-SDLC中的安全實踐做起來
- 安全服務平臺提供開箱即可用的安全服務葛闷，此舉將開發(fā)團隊所需要做的工具類建設活動的成本降至最低。與此同時双藕，對于不同的開發(fā)團隊而言淑趾，他們是對安全服務平臺所提供的安全服務進行分時復用，因此重復建設的問題也不復存在
- 安全服務平臺將眾多安全工具和服務匯集在一起忧陪，同時也就把各項安全活動的產出物也都集中到了一起扣泊。這既有助于開發(fā)團隊更全面的了解自己正在構建的應用程序的安全狀況，又便于安全團隊把握整個企業(yè)范圍內的眾多應用程序的安全狀況
- 通過安全服務平臺提供了兩個信息閉環(huán)：（1）通過平臺開展的安全活動赤嚼，相關產出物（典型的如發(fā)現的安全漏洞）會通過持續(xù)交付流水線旷赖、郵件短信等方式及時反饋回開發(fā)團隊，促進安全問題的修復更卒；（2）安全團隊推薦或要求開發(fā)團隊執(zhí)行的安全活動等孵，到底有沒有被執(zhí)行，執(zhí)行的情況怎么樣蹂空，在沒有安全服務平臺時俯萌，只能通過內部安全審計、安全檢查上枕，甚至動用安全團隊成員的私人關系來了解咐熙。而一旦安全活動通過平臺開展，必然會在平臺上留下各種數據辨萍，那么借助數據可視化等手段棋恼，安全團隊久可以方便的獲取到以及追蹤安全活動的開展情況，并基于此不斷推動安全活動落地執(zhí)行锈玉，提高活動實施效果爪飘。
4. 小結
S-SDLC，也即安全開發(fā)生命周期能夠確保應用程序具備充足的安全性拉背，而自動化是推行S-SDLC的一個重要手段师崎。不少企業(yè)的安全團隊已經在這方面進行了很多努力，但也面臨著新的挑戰(zhàn)椅棺。比如重復建設犁罩、實施質量良莠不齊齐蔽、信息分散、沒有形成閉環(huán)等等床估。
安全服務平臺是這個困境的破局者含滴，它封裝了一系列安全工具和第三方安全服務，并通過多種方式統(tǒng)一的向開發(fā)團隊提供便捷的安全服務丐巫，使得開發(fā)團隊更有意愿落地實施S-SDLC中的安全活動蛙吏。并且安全服務平臺還為安全團隊的管理提供了支持。
既然安全服務平臺如此優(yōu)秀鞋吉，那么該如何構建這樣的平臺呢？有沒有什么核心原則需要考慮励烦？有沒有什么前提條件谓着？它似乎有多種服務提供形式，那到底有哪幾種呢坛掠？除了S-SDLC相關的安全服務外赊锚，平臺還可融入其他安全功能嗎？這些問題我們留著下篇文章為大家詳細解答屉栓。
