安全開發流程（SDL）

SDL：Security Development Lifecycle 安全開發生命週期

培訓	要求	設計	實施	驗證	發佈	響應
核心安全培訓	肯定安全要求 建立質量門/錯誤標尺 安全和隱私風險評估	肯定設計要求 分析攻擊面 威脅建模	使用批准的工具 棄用不安全的函數 靜態分析	動態分析 模糊測試 攻擊面評析	事件響應計劃 最終安全評析 發佈存檔	執行事件響應計劃

一、培訓

培訓對象：開發人員、測試人員、項目經理、產品經理

培訓內容：安全設計、威脅建模、安全編碼、安全測試、隱私等

二、安全要求

項目確立前與項目經理或產品全部者進行溝通，肯定安全的要求。

三、質量門/bug 欄

質量門和 bug 欄用於肯定安全和隱私質量的最低可接受級別。項目團隊必須協商肯定每一個開發階段的質量門。bug 欄是應用於整個軟件開發項目的質量門，用於定義安全漏洞的嚴重性閾值。

四、安全和隱私風險評估

安全風險評估（SRA）和隱私風險評估（PRA）用於肯定軟件中須要深刻評析的功能環節。包括 ① 項目的哪些部分在發佈前須要創建威脅模型？② 哪些部分在發佈前須要進行安全設計評析？③ 哪些部分須要由不屬於項目團隊且雙方承認的小組進行滲透測試？④ 是否存在安全顧問認爲有必要增長的測試或分析？⑤ 模糊測試的具體範圍？⑥ 隱私對評級的影響。

五、設計要求

在設計階段仔細考慮安全和隱私問題。

六、減少攻擊面

減少攻擊面與威脅建模緊密相關。它經過減小攻擊者利用潛在弱點或漏洞的機會來下降風險，包括關閉或限制對系統服務的訪問，應用「最小權限原則」，儘量分層防護。

七、威脅建模

微軟的 STRIDE 模型

八、使用指定的工具

開發團隊使用的編譯器、連接器等工具及其版本應由安全團隊肯定安全性。

九、棄用不安全的函數

禁用不安全的函數或 API

十、靜態分析

能夠由工具輔助完成

十一、動態分析

在測試環節驗證程序安全性

十二、模糊測試

模糊測試是一種特定的動態分析方法，經過故意向應用程序引入不良格式或隨機數據誘發程序故障。測試策略的制定以應用程序的預期用途、功能、設計規範爲基礎。

1三、威脅模型和攻擊面評析

項目因需求變動等因素致使最終產出偏離原定目標，爲此項目後期有必要對威脅模型和攻擊面進行從新評析。

1四、事件響應計劃

每一個軟件在發佈時都必須包含事件響應計劃。尤爲若是產品中包含第三方的代碼，要求留下第三方的聯繫方式並加入事件響應計劃。

1五、最終安全評析

在產品發佈以前對軟件執行的安全活動。

1六、發佈/存檔

在經過最終安全評析後能夠完成產品的發佈。同時，對各種問題和文檔進行存檔，爲緊急響應和產品升級提供幫助。

 

SAMM：Software Assurance Maturity Model，OWASP 推出的軟件認證成熟模型 

參考連接：http://www.opensamm.org/

 

SDL 適用於軟件開發商，他們以販售軟件爲主要業務；SAMM 適用於自主研發軟件的組織，如銀行、在線服務提供商。軟件開發商的軟件工程比較成熟，有嚴格的質量控制；而自主開發軟件的企業組織更強調效率。

 

 敏捷 SDL

 對於使用敏捷開發的團隊，需求和功能一直在變化，代碼也在發生變化，這要求在實施 SDL 的過程當中在每一個階段更新威脅模型和隱私策略，在必要的緩解迭代模糊測試、代碼安全分析等工做。

 

 互聯網公司 SDL 實踐經驗

準則1、與項目經理進行充分溝通，排出足夠時間

準則2、規範公司的立項流程，確保全部項目都能通知到安全團隊，避免遺漏

準則3、樹立安所有門的權威，項目必須由安所有門審覈完成後才能發佈

準則4、將技術方案寫入開發、測試的工做手冊中

準則5、給工程師培訓安全方案

準則6、記錄全部的安全 bug，激勵程序員編寫安全的代碼

 

產品研發階段的安全

需求分析與設計階段

需求分析階段能夠對項目經理，產品經理或架構師進行訪談，瞭解產品背景和技術架構，並給出相應的建議。

應該瞭解項目中是否包含了第三方軟件，認真評估第三方軟件是否存在安全問題。規避第三方軟件帶來的安全風險。

參考連接：https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet

 

開發階段

提供安全的函數

OWASP 的開源項目 OWASP ESAPI 爲安全模塊的實現提供了參考。若是開發者沒有把握實現一個足夠好的安全模塊，最好參考 OWASP ESAPI 的實現方式。（其中 Java 版本最爲完善）。

不少安全功能能夠放到開發框架中實現，這樣能夠大大下降程序員的開發工做量。

定製開發者的開發規範，並將安全技術方案寫進開發規範中，讓開發者牢記。在代碼審計階段，能夠經過白盒掃描的方式檢查變量輸出是否使用了安全的函數。將安全方案寫入開發規範中讓安全方案實際落地，不只方便開發者寫出安全的代碼，同時爲代碼審計帶來方便。

代碼安全審計工具

常見的代碼審計工具對複雜項目的審計效果很差：① 函數調用是個複雜的過程，當審計工具找到敏感函數時，回溯函數的調用路徑經常會遇到困難；② 若是程序使用了複雜框架，代碼審計工具每每因爲缺少對框架的支持，從而形成誤報或漏報。

代碼自動化審計工具的一個思路：找到全部可能的用戶輸入入口，而後跟蹤變量的傳遞狀況，看變量最後是否會走到危險函數。

對於甲方公司來講，能夠根據開發規範來定製代碼審計工具 —— 並不是直接檢查代碼是否安全，而是檢查開發者是否遵照了開發規範。

測試階段

安全測試應該獨立於代碼審計。有些代碼邏輯較爲複雜，經過代碼審計難以發現全部問題，而經過安全測試能夠將問題看清楚；有些邏輯漏洞經過安全測試能夠更快地獲得結果。

安全測試分爲自動化測試和手動測試兩種。

自動化測試能夠經過 web 安全掃描器對項目或產品進行漏洞掃描：XSS、SQL  Injection、Open Redirect、PHP File Include；CSRF、越權訪問、文件上傳等漏洞因爲涉及系統邏輯或業務邏輯，有時須要人機交互參與頁面流程，所以須要依靠手動的方式完成測試。

skipfish 是 Google 使用的一款 Web 安全掃描器，性能優異，能夠用於二次開發。