這是鼎叔的第一百零八篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社），文末有連結。
鼎叔曾經花了一年多的時間組建了一個安全工程師團隊，並系統化地學習了安全技術理論和實踐方案，藉著 DevOpsSec 的東風，聊聊測試（質量）與安全的關係，以及如何在持續測試中落實安全檢測能力。
部分圖片來自賴東方同學的分享。
測試（質量）與安全
從大的質量角度來定義，質量是包含功能，效能，安全，合規，相容，易用性等多個維度的，所以安全類測試也是測試體系中的一個型別。
受限於安全意識和安全技術的專業門檻比較高，大多數測試工程師非常缺乏安全測試的能力，本質上，這類能力是可以刻意練習的。
先來理解一個問題，安全工程師和其他開發工程師有什麼不同？
最大的區別，是對於引入風險的敏感度。安全工程師優先關注漏洞和被利用的可能性，而不是關注便利性。比如快取的設計，業務開發用快取來提高響應效能和使用者滿意度，安全工程師一看見 “快取” 眼睛就亮了，眼裡馬上浮現出各種利用快取的漏洞。
另外一個例子是對 “客戶端的不信任”，不盲目相信客戶端的提交，對涉及許可權的資訊要有不可猜測性。比如有的使用者可以透過遍歷連結中的 ID 號，可以檢視其他使用者的交易記錄。
專業的安全高手（白帽子）從大學開始就參加各種安全比賽（挖洞），並對各種最新的威脅漏洞和安全檢測工具非常敏感。
優秀的測試工程師不也是應該這樣麼？——對於各種缺陷非常敏感，形成直覺。安全缺陷也是缺陷中的一類，優先順序通常很高。
安全和其他測試一樣，也很容易成為軟體釋出的瓶頸，團隊經常為了達到安全標準，安排特定的評審和測試驗收環節。
但如果安全流程嚴苛，安全技術人員人手不足，安全檢測自動化水平低，整個業務的釋出節奏都會被影響。
助力安全左移的 DevOpsSec
敏捷團隊經常強調質量內建，安全也同樣要內建，內建的意思就是業務研發和安全團隊責任共擔。
關於安全內建和安全左移，微軟有一套著名的 SDL(應用安全開發生命週期) 實踐方案：
如何快速內建，降低安全評審依賴，縮短交付週期？解法和持續測試是一樣的，在 DevOps 閉環中賦予安全能力和安全工具，同時解決快速交付和資訊保安的難題，即業界熱門的 DevOpsSec。
DevOps 引入安全能力面對的通用挑戰是：引入成本和工具誤報，弱化安全設計帶來的風險，以及如何真正做到快。
那什麼是 DevOpsSec 的指導原則？
安全左移
預設安全
執行時安全
安全服務自動化/自助化
IaC-基礎設施即程式碼，製品庫安全等
利用好 CI/CD
組織和文化建設。對於產研團隊，最重要的就是意識和技術兩方面的安全培訓，相關內容可以看看下面。
工欲善其事，必先利其器。融合安全的持續交付必然離不開常見的持續整合安全工具，如：
靜態應用安全測試工具 (SAST)
第三方安全掃描工具
動態安全測試（DAST）工具，模擬駭客的攻擊行為
互動式安全測試工具 (IAST)，透過在測試環境插樁或埠截流的分析方式。
日誌安全分析工具
製品管理安全工具
資訊保安自動化工具對於開發和運維工程師來說最好是 “透明無感知” 的，這樣才能保證 DevOps 的敏捷。
類似鼎叔在持續測試提到的成熟度概念，DevOpsSec 也是可以定義成熟度的，需要明確哪些指標納入成熟度考核，並進行合理的分級。比如下面幾個成熟度的參考維度：
安全工具鏈的建設，整合和使用的情況
團隊敏捷工作方式和團隊的組織架構情況
人員的安全能力：知識經驗和問題解決能力
產品交付的質量資料和安全水平
安全團隊在幹什麼
回憶一下，鼎叔在組建安全團隊期間具體做過哪幾件事。
安全滲透測試。給公司的資料資產做深度檢查。入職的第一位安全工程師，就在第一週發現了後臺資料庫的一個重大漏洞，匯出了所有員工的登入賬號密碼並暴力破解，讓技術部門吃了一驚。滲透測試怎麼展開，可以看看這張思維導圖
安全自動化掃描能力，和前面提到的 DevOps 工具鏈的聚合。釋出了多端產品（H5 官網，App 端，後端等）的掃描安全問題分析報告。
業務安全，分為業務架構的安全評審，以及使用者可疑操作行為的風控等兩大類工作。
對於 APP 羊毛黨使用者，我們能夠從登入地點，登入 IP，登入頻率，登入時間，交易操作頻次，以及第三方登入方式等資訊，判斷其對業務帶來的風險。我們甚至為此建設了異常登入規則庫。
安全團隊可以把需求安全評審的關注點做成 checklist，具體考慮這些維度：資訊保安資產的機密性，完整性和可用性；針對安全控制設計與變更，基礎設施的變更，合規性的變更，給出具體的控制評審清單。
對 GitHub 上的公司敏感程式碼洩露進行監控，落實管理辦法。
給公司員工賦能安全能力和安全意識。安全是質量的一個維度，這句話類似 “培養員工的質量能力和質量意識”，讓全員重視安全，遠比一個小團隊辛苦救火要好。
安全賦能 - 意識
安全防範體系的四部曲：讓壞人進不來，看不到，改不了，賴不掉。
鼎叔曾經花了四個月的時間（每天一個小時），看完了 CISSP 考試教程的內容，裡面提到了十大安全設計原則，可以用來避免 90% 的安全問題：
簡單易懂
最小特權
故障安全化 - 即使發生故障，也能安全處理業務
保護最薄弱環節
縱深防禦。多層次地防禦攻擊
隔離原則
總體調節
預設不信任
保護隱私。包括脫敏和加密，明確禁止的資料不要採集
公開設計才是安全的設計。
一張很有趣的圖片，開著這輛車去街上溜達一圈，就可能入侵各個攝像頭網路的資料庫：
為了提升員工安全意識，安全團隊會聯合 IT 做一些安全演練，最常見的就是發釣魚軟體，看看哪些人會上當。
對於灰產羊毛黨最喜歡的大規模自動化惡意操作，如擼羊毛和撞庫，也有不少的圖片資料，提升員工的直觀感受。
安全賦能 - 技術能力
安全技術能力主要包括這麼幾大類：
Web 安全漏洞挖掘能力
APP 安全漏洞挖掘
隱私合規能力
安全編碼能力。最突出的是輸入輸出引數處理不當產生的漏洞。大公司都會搞一個安全編碼規範，注意：如果安全人員做的規範不太考慮編碼語言，不考慮開發人員的視角，會給開發人員帶來較多的負面體驗。
框架安全，安全函式庫和安全元件。直接提供一系列的安全函式，或者內建了安全特性的元件，對開發人員的幫助會更有效。
原始碼安全管理。程式碼安全管理允許開發人員協作處理並跟蹤更改。原始碼屬於公司的敏感資料，對其訪問控制也需要遵循最小許可權原則。
編譯環境和開發環境安全。第三方提供的構建依賴包等，可能會成為安全隱患的源頭。如 2015 年的 XcodeGhost 事件，受影響的使用者數量超過了一億。
構建基本的自動化攻防能力。一旦樹大招風，被黑產盯上還是很要命的，基本能力需要日常演練。
資料安全，本質上是保障儲存，傳輸，使用的安全。傳輸要看簽名完整性，使用上要看操作和日記記錄。
安全團隊的新挑戰
自動化時代的低程式碼平臺在前些年挺火，但是對於 DevOps 公司很難深度使用，低程式碼平臺始終不能緩解自動化焦慮，長期看也不能提高效率，開發團隊也不願意接手低程式碼遺產。
對於當前普遍上雲和微服務的業務而言，面臨更多具體的新安全挑戰：
對於雲和微服務，攻擊面小很多，邊界不清晰，審計困難。
容器的安全技術和以往不同，要考慮資產的銷燬，相容性等新風險。
雲原生的安全也有所不同，它包括程式碼安全，映象安全，編排系統安全，容器執行時安全。這四種安全分別對應著程式碼，容器，叢集和雲這四個層級。
結語
安全團隊投入的成本很高，不要指望 100% 的安全，安全工作的本質就是儘可能降低風險，積極攻防實踐，儘量藉助自動化機制快速驗證，並對一線工程師賦能。