【SDL最初實踐】安全開發

• 2019 年 11 月 8 日
• 筆記

在確定產品原型與功能之後，便交由開發負責推進。然而關注點大多僅在於業務流程與功能點的實現，具體使用的技術決定於公司技術棧和個人能力，對於帶着安全意識去編碼這件事兒，大多都沒太在意。

01

—

安全目標

通過提供公共安全組件、制定安全開發規範、提供靜態代碼審計系統給業務方，從基礎安全服務提供者、安全規範制定者和安全質量把關者角度出發，對開發進行賦能，想辦法讓其按照安全開發規範進行編碼，並提供一套強有力的代碼安全檢測系統，把控代碼安全質量，從而減少或消除因編碼而產生的安全漏洞。

02

—

安全活動

在代碼編寫階段，安全活動主要圍繞安全開發規範、安全組件接入和靜態代碼掃描開展。

1）安全開發規範

從隱私和安全角度兩方面出發，結合當前發現的高危問題；參考業界的安全開發規範，融合公司當前的技術棧；站在開發視角，進行安全開發規範的編寫。規範項不在多，關鍵是需要清晰、易懂、針對性強、易判斷是否違規。

2）安全組件接入

分析企業中存在的常見安全漏洞，來源可能是內部安全測試結果、外部漏洞收集（SRC、第三方漏洞平台、CVND等），並結合漏洞影響、開發難易程度、加固效果，對業務部門輸出統一的安全組件，快速、高效、低成本解決普遍存在的安全問題。常見的可能有：統一登錄安全網關、短訊安全網關、CSRF-token組件、XSS過濾器（適用於非富文本框場景）等。

3）靜態代碼掃描

代碼的白盒測試，最好是嵌入到發佈流程中。一方面對源代碼起到保護作用，不用另闢蹊徑存放源代碼，打破源代碼統一管控的好局勢；另一方面可以在流程中設置卡點，形成強有力的抓手。不少人對代碼分析存在恐懼，覺得是效率低並且要求高的工作，但是在代碼層面找出問題對於整個SDL都是十分必要、有效的一環。市面上的代碼審計工具不少，商業的包括checkmarx、fortify、coverity，開源的有check style、findbugs、cobra、Rips等，需要從語言的支持、誤報率、購買以及維護成本等不同維度進行綜合評估。

03

—

安全實踐

1）開發安全規範

• 開發語言：隨着技術的不斷更新與發展，公司中必然會出現不同的開發語言，按照先cover住公司主流語言的思路，確定Java安全開發規範的編寫工作。
• 編寫內容：比較快速的一種方法是引入外部優質資源，現網上公開的優質資源有阿里的安全開發規範、華為早期的安全開發規範，參考其內容與格式，針對公司主流語言系統常見高中危漏洞進行編寫。
• 規範框架：包括漏洞描述、檢測方法、代碼示例（不合規代碼示例、合規代碼示例）及修復方案。

• 架構評審：安全人員有時不禁僅從安全的角度來編寫規範，如果沒有專業的開發技術和對漏洞足夠的了解，預期的產物與效果往往會大打折扣。邀請架構組和業務線上的開發參與規範評審，不僅會從專業的技術角度提出建議，還會從實際可落地性和開發容易理解的視角進行完善。
• 發文上線：發文之前有一必備的步驟就是會簽，找各業務線的領導和大老闆會簽，讓他們知道有安全開發規範的存在，對日後可能產生的違規處罰進行聲明。

2）代碼審計系統

• 代碼掃描工具選型：以來自互聯網上的一張改編圖進行說明，對主流的掃描工具進行對比。

本文中的示例，以fortify為例。（網上出現不少帶license的破解版本，有興趣的自尋查找）

• 嵌入系統發佈流程：將代碼掃描工具集成到系統發佈流程，是安全開發階段最重要的步驟。在發佈系統中加入靜態代碼掃描按鈕，開發創建項目並提交代碼後，觸發fortify在掃描服務器上進行掃描，掃描結束後以郵件的方式告知開發。大體流程如下：

• 提供代碼掃描服務：以安全服務提供給業務方，除了代碼掃描的能力外，還有安全掃描的流程與使用方法介紹、掃描出的漏洞解讀與技術支持、總結常見問題並歸檔對外輸出。比如往期的文章中，將fortify漢化版漏洞說明，統一放到內部技術平台以供學習。

3）輸出公共安全組件

• 現狀分析：針對普遍存在於業務線或高頻出現的高危漏洞，結合不同的場景進行分析，衡量是否有輸出公共安全組件的必要性。別讓開發花大量時間在修復漏洞上，解放他們，回歸系統功能的開發與實現。
• 協作部門：單靠安全部門，在一般的公司難以做起來，尤其是缺少安全開發或開發能力不強的團隊。比較好的一種方法便是拉上中間件等中台部門進行合作，優勢互補輸出公共安全組件。
• 安全評估：針對公共安全組件的安全評估，包括功能設計、實現邏輯以及最後的安全測試，都需要安全人員的重點關注，避免安全組件出現繞過的場景，杜絕因為安全組件而引入新的安全隱患。比如使用已知的成熟算法，切勿私自發明創造。

04

—

持續優化

安全運營的思想，也同樣適合在SDL的各個階段，即：在推行中發現問題，解決問題，優化功能。在安全開發階段，安全開發規範需要優化，代碼掃描系統也需要優化，覆蓋率需要考慮，準確率也需要琢磨。簡而言之，大致可以從以下三個方面進行考慮：

1）安全開發語言覆蓋面

開發技術棧的多元化，帶來最直接的問題便是覆蓋面。安全開發規範、靜態代碼掃描都需要由最開始的cover主流語言，擴展到公司第二、第三…主流語言。在資源受限的情況下引入一些開源工具應對不同的語言審計，或許是個必要的選擇。

2）靜態代碼審計系統誤報

幾乎所有的互聯網公司都是追求「寧可漏報，不可誤報」，由於發佈量特別大不得不這樣。然而在傳統行業里，開發模式可能還是瀑布模式，對各個環節的誤報要求難以媲美互聯網公司，但是減少誤報率也是十分必要的。對於使用商業版（破解了也算）的代碼審計工具而言，其規則難以調整，故可以在掃描的結果上進行優化，比如要求開發僅解決Critical、High級別的漏洞，甚至是可以具體到兩種級別中的具體漏洞類型。

3）第三方開源組件技術檢測手段

使用已知漏洞的組件，在最近兩次的OWASP Top 10中均上榜，由此見得其重要程度。目前在市面上還很少出現專門的檢測工具，商業版的幾款靜態代碼掃描器有所涉及，但未能試用對比。目前而言，稍微較好一點的方法可能是使用OWASP提供的Dependency-Check，有如下特點：

• 支持Maven、Jenkins等集成
• 支持Java、.Net
• 漏洞信息來源於nvd
• 檢測規則為特徵匹配（類似工具基本都是該原理）

05

—

安全招聘

團隊招人，希望有想法的小夥伴，一起共創未來。希望你是：

• base：北京
• 具備：一定的SDL經驗，並想在該方向深究與沉澱
• 聯繫：歡迎微我，更多細節詳聊

06

—

安全交流

近來發現SDL越來越「火」，於是產生了創建微信群、專門交流SDL的想法。

• 入群請加我：姓名-公司（甲方）-SDL
• 入群請須知：僅討論SDL相關話題、僅分享SDL相關材料
• 拒絕伸手黨、斗圖黨、開車黨以及抱着心態進來學習（潛水）黨