1. 傳統安全實踐面臨著嚴峻的挑戰
隨著網際網路應用、移動應用爆發式的增長，伴隨而來的黑客攻擊事件也是層出不窮。僅在過去的2015年裡，被公開報導的資料洩露安全事件就有約3930起，將近7.36億條資料被洩漏。顯而易見的是，如果某家企業被爆出安全問題，對企業造成的影響不僅僅只是名譽、財務上的損失，還會遭受法律訴訟，陷入競爭不利的局面。安全已經是企業不可忽視的問題。
近年來，黑客攻擊的趨勢已經發生了顯著的改變，由最初的針對網路、作業系統以及伺服器的攻擊，已經轉變為針對應用程式的攻擊。根據Garnter的調研報告顯示，有將近80%的安全漏洞發生在應用層。為了應對新的安全威脅，企業也做出了各種嘗試，例如為員工提供安全培訓、設立安全規範文件、部署Web應用防火牆、建立安全監控中心、利用安全滲透測試尋找安全漏洞等等。經過一些列的努力，取得的成果也是比較顯著的，例如老生常談的SQL隱碼攻擊，其全球範圍內的漏洞數量呈現出了非常顯著的下降趨勢，如圖1-1所示。
圖 1-1 SQL 注入漏洞數量趨勢
然而並不是所有發生在應用程式中的安全漏洞的數量都得到了有效抑制，例如跨站指令碼攻擊漏洞的數量似乎並不受安全措施數量的影響，如圖1-2所示。
圖 1-2 XSS 漏洞數量趨勢
一個現象是，企業為應對應用安全問題採取了各種措施，雖然有一定成效但是也有或多或少的問題，如圖1-3所示，隨著安全措施數量的增加，應用中的安全漏洞的數量不再顯著減少。似乎無論如何努力，開發出來的應用中始終有安全漏洞。
圖 1-3 安全措施和安全漏洞數量的關係
除此之外，企業還面臨著更多的困境：
- 安全漏洞總是很晚才被發現出來，造成的結果是安全漏洞的修復成本高昂。
- 未能檢查出隱藏在應用中的安全漏洞，含有安全缺陷的應用被髮布到生產環境中，這將增加企業面臨的安全風險。
- 某些安全措施容易被誤解為是團隊的負擔
- 開發團隊人員安全技能有所缺失，應用的安全性過度依賴於應用安全團隊
2. 為何安全漏洞如此難以消除？
為消除安全漏洞，企業採取了不少措施，然而一個不爭的事實是，企業主要依賴於Web應用防火牆（Web Application Firewall，下文簡稱WAF）和滲透測試（或安全審計）。然而問題在於，這兩種措施固然有效，但是也存在著明顯的不足。
2.1 WAF是把雙刃劍
WAF主要的職責是阻擋攻擊，為開發團隊爭取修復漏洞的時間。換言之，只要應用中存在安全問題的程式碼沒有被修復，漏洞就會一直存在，一旦WAF規則被繞過，或者配置不當，反而會將應用置於更高的安全風險當中。此外，誤報和漏報始終是WAF無法徹底解決的問題，與此同時，隨著應用規模的擴大，業務邏輯複雜度的增加，對於WAF的管理維護難度也在不斷增加。
2.2 滲透測試讓企業面臨兩難的境地
滲透測試確實能發現安全漏洞，但是也存在著明顯的不足。首先是太晚才能得到安全問題的反饋，因為通常而言，滲透測試會被安排在產品上線釋出之前進行，此時如果檢查出安全漏洞，企業反而會面臨兩難的境地：修復安全漏洞之後再發布產品，或者強行釋出包含安全漏洞的產品。同修復業務缺陷一樣，修復安全漏洞也是越晚修復成本越高，開發團隊需要投入更多的時間和人力，而這可能導致產品推遲釋出，錯失市場機會；如果強行釋出含有安全漏洞的產品，又將增加被黑客攻擊利用的風險。
2.3 拋開現象看本質，問題的根源在於缺乏高效的安全反饋機制
應用中的安全漏洞是在開發過程當中由於各種原因被引入的，然而回顧現有的安全措施就會發現，其中大量的措施發生在應用程式開發過程之外，例如WAF、安全監控發生在產品上線之後，滲透測試需要等待開發完畢後才能進行，而安全培訓、安全規範只能起到預防作用。儘管各種安全措施都能為開發團隊提供不同程度的安全反饋資訊，然而問題在於，大量的安全措施都發生在開發過程之外，距離安全問題被引入的時間點之間有很長的距離，因此安全問題不能及時的反饋給開發團隊。
此外，由於不少安全措施的成本高、耗時長，因此難以持續性的為開發團隊提供安全反饋。例如聘請第三方安全公司對應用進行安全滲透測試的價格較高，且往往需要幾天甚至更多時間才能收到安全報告。
3. 更好的解決安全問題
安全漏洞本質上是軟體質量缺陷，安全性是軟體質量的重要組成部分，而現如今應用安全面臨的問題和多年以前軟體測試面臨的問題極其相似。當時人們在開發軟體的時候，採取的做法往往是在軟體開發臨近結束之時集中性的進行測試，修復發現的質量缺陷，結果是當時的軟體質量普遍不高，不少專案因此失敗。
為了提高軟體質量，開發團隊採取了一些措施，例如將測試介入的時間點提前，儘早進行測試，甚至是先寫測試後寫實現程式碼，與此同時也大量採用自動化測試來加快測試執行速度，採用構建流水線持續關注軟體質量，並且每位團隊成員都對軟體質量負責，而不再認為只是測試人員的職責。這些措施之所以能夠顯著提高軟體質量，關鍵在於它們能夠更加高效的為開發團隊提供軟體質量相關的反饋資訊，使得開發團隊能夠基於反饋結果迅速進行改進。
同理，要更好的解決安全問題，開發團隊應當建立起一個高效的安全反饋機制，在開發過程中引入一些安全活動，儘早開始收集安全反饋資訊，加快獲取安全反饋的速度，在整個開發過程中持續性的關注應用的安全性，與此同時團隊成員共同來承擔安全職責。我們將這些在實踐中總結出來的經驗命名為內建安全的軟體開發方式（Build Security In DnA，下文簡稱BSI），從源頭上儘早、儘快、持續性的，以團隊共同協作的方式發現並解決安全問題。
圖 3-1 內建安全的軟體開發方式 (Build Security In)
3.1 儘早獲取安全反饋
越早獲取到安全反饋資訊，越有利於開發團隊以更低的成本將其修復。一個反面例子是，安全問題在早期就已經引入了，但是隻能通過後期的滲透測試才能暴露出來，安全反饋資訊經歷了很長一段時間才能反饋給開發團隊。與其依賴於後期的滲透測試，不如在開發過程當中引入一些適當的安全實踐，比如在分析業務需求的同時主動分析安全需求，將其作為質量驗收標準在團隊內明確出來，再比如，針對每次程式碼提交都對其進行安全評審、測試人員在測試業務功能的同時還對安全性進行驗證。通過這種方式，使得團隊能夠儘快得知應用的安全狀況，而不必依賴於很晚才能提供安全反饋的滲透測試。
圖 3-2 在開發過程當中引入安全實踐
3.2 通過自動化加速獲取安全反饋的速度
從安全形度對程式碼進行的評審，以及測試人員主動進行安全測試等等手段都能更早的產出安全性的反饋資訊，但是傳統的安全測試、滲透測試主要是以手動的方式進行，造成的結果是需要耗費許多時間才能收集到安全反饋資訊。更好的做法是，對於常規的安全測試可以藉助工具以自動化的方式進行，不僅能夠以更快的速度得到安全性反饋，還能在一定程度上彌補由於人員安全技能不足所造成的安全測試不夠全面的問題。自動化帶來的另外的好處是，它可以整合入CI伺服器，從而讓開發團隊可以在CI流水線完成之後第一時間發現應用的常規安全問題，而不必等到上線前由安全專家來發現安全問題。
例如，應用通常依賴於各種第三方元件，這些元件可能含有已知的安全漏洞，手工對每個元件進行安全檢查是行不通的，更好的做法是利用自動化的檢查工具如OWASP Dependency Check，以更快的速度對元件進行安全檢查並且生成結果報告。這一過程是完全自動化的，開發團隊只需定期檢查報告即可，使得開發團隊獲取反饋的速度得到極大的提升。
3.3 在開發過程中持續性的關注安全
收集安全反饋不是一次性的活動，高效的安全反饋機制和持續整合秉持相同的理念：除了儘早整合、儘快整合之外，很重要的一點就是讓整合活動能夠持續性的發生。類似的，對於建立高效的安全反饋機制而言，在能夠儘早、快速的獲取安全反饋的同時，還需要讓這個反饋循機制在應用開發過程中持續的執行下去。
自動化使得開發團隊能夠更容易的做到對安全的持續關注。例如，將自動化的程式碼安全掃描和持續整合伺服器結合起來，這樣在每次程式碼提交後都能得到一份安全報告，從而可以立刻著手進行相應的修復。此外，對於那些不適合自動化執行的安全實踐而言，開發團隊依然有必要持續性的去做。例如，每當應用的功能發生變更之時都應該進行一次威脅建模以分析安全威脅，明確安全需求，每當新的功能被開發出來，測試人員都要對其安全性進行驗證。
圖 3-3 對安全保持持續性的關注
3.4 團隊成員共同承擔安全職責
大多數人認為團隊中的測試人員應該對產品的安全負責，理由是他們要進行各種測試，安全測試理應包含在內。如果有專門的安全團隊，則更多的人會認為安全團隊應該主導產品的安全性，畢竟，在他們眼裡這是安全團隊天生的職責。
但這是一種誤解，只要人們認為安全應該由團隊中的某個角色或者某個獨立的團隊負責，就容易形成消極的氛圍：既然有專門的人在負責產品安全，那就說明安全不是自己的職責，等發現安全問題了再說。這種氛圍會帶來很多負面影響，例如：安全問題難以及早發現並解決，人員安全技能得不到鍛鍊，安全改進在團隊內難以推動，等等。
和傳統的高度依賴於某個角色或者安全團隊來保證產品安全的做法不同，BSI則是把安全職責拆分到團隊中的每個角色身上，讓所有人都參與進來，共同協作解決安全問題。每個人都肩負著維護產品安全性的責任，主動為此付出努力。
業務分析人員在分析業務需求的同時把產品的安全性納入考慮的範圍之內，如果他們沒有相關的安全技能，則可以和技術人員合作共同來完成這一任務，與此同時，開發人員在編碼的過程中有意識的去避開安全風險，並協助測試人員對產品進行安全測試。在產品交給安全團隊進行安全審查之前，一些安全漏洞已經被發現並修復了，甚至在需求分析之時就已經被規避了。此時的產品已經具備了一定的安全性，也為安全團隊爭取到了更多的時間，使得他們可以把更多的精力放在檢測深層次安全漏洞上面。
通過這種共同分擔職責的方式，開發團隊在應對安全問題上的內部凝聚力會得到增強，團隊成員會更有意願和動力去提升自己的安全能力。更重要的是，這種做法可以使得團隊成員以及安全團隊能更好的進行協作，從而逐漸形成良性迴圈。
圖 3-4 共同承擔安全職責
4. 總結
安全，是每個企業都需要做到的，在網際網路時代更是重中之重。企業正面臨著全新的安全挑戰，然而現有的一些傳統安全措施卻並不能高效的解決這些問題，主要的原因在於過度依賴WAF、滲透測試等被動防禦手段，往往是在比較晚的時候才獲取的安全反饋，導致安全問題修復成本高昂，甚至使企業陷入進退兩難的局面。
為了提高應用的安全性，並且彌補傳統安全措施的不足，Build Security In應運而生：在軟體開發過程中引入合適的安全實踐以儘早發現安全問題，利用自動化的優勢縮短安全問題的反饋週期，持續的、以共同協作的方式主動預知並化解安全問題。在減輕開發團隊和安全團隊負擔的同時，提高發現、解決安全問題的效率。
安全不是絕對的，所以BSI對於安全的保證也是相對的，但是對於業務越來越複雜，規模越來越龐大的軟體系統，BSI這種內建安全的軟體開發方式必將從源頭上減少安全風險，降低被黑客攻擊的可能，從而顯著減少系統在上線使用後因安全問題造成的損失，使其在網際網路的大潮中生存下來。