企業SDLC建設不成熟設想

1、說明

1.1 背景說明

以前在N市，面試的是「IT系統安全工程師」的崗位但合同上籤的是「集成工程師」的名頭（前陣子找以前的郵件offer才注意到的），工做內容如今看來仍是和當時離職時表述同樣基本一半是系統集成的工做一半是安全的工做。其好處是一方面對數據庫、中間件、大數據平臺等技術有比較深刻的瞭解，另外一方面對4A、SoC、安全基線等安全概念也有必定程度的認識。

來到S市，司職是正經的安全崗位「滲透測試工程師」，滲透能力逐漸造成了比較完整的知識體系，最後又演變成了當前的SDLC認識。

之因此說「不成熟」，一是由於從本身感受上沒有很完善，二是由於沒有大量的實踐證實其可靠性和可行性；而之因此要「強行描繪」，一是爲了作個階段總結，二是感受後邊去T公司後短期內也沒機會實踐SDLC全流程。

其實感受企業安全體系核心包括兩方面，一是以SDLC爲核心的單個應用的從設計到上線全流程，二是以SoC爲核心的全部安全設備、安全系統的統籌管理。但對於後者一是本身概念就更模糊了，二是感受即使在業界也未造成統一的認識，若是之後有更深的理解再說了。

 

1.2 安全行業一些不成熟預測

出身：即使到如今網上還能夠常常聽到某某黑客大佬不是信息安全專業出身、不是計算機學院出身、沒讀過大學、小學沒畢業之類的說法。但就趨勢而言，之後科班出身的比例會愈來愈高，專業知識掌握得越深的人走得越遠。

入行：如今進入安全行業，主流途徑通常是學校課上學計算機/信息安全的知識、課餘本身找環境實操打打CTF，畢業後進入安全乙方安全公司、安全崗，積累必定程度後轉入甲方安全崗。

歸宿：在職業前中期更多要求技術深度，在職業中後期更要求知識廣度；公司越大技術深度的存活度就越久。其實就和程序員相似，更多的出路就是管理崗，更多的公司要的就是你能給公司架起安全體系。

 

2、SDLC概念理解

2.1 關於SDLC名詞來歷

最開始聽到的應該不是SDLC而是SDL，而最先開始聽到SDL應該是在軟件工程課上講的微軟的SDL；由於軟件工程講的是軟件開發生命週期，因此我一直覺得講課一筆帶過的微軟SDL是「Software Development Lifecycle」。

近幾個月聽到不少公司不少安全崗位都講SDLC，感受雖然意思能夠理解但安全直接佔用開發的名詞不太好吧，但回頭一看其實出自微軟的SDL並非「Software Development Lifecycle」而是「Security Development Lifecycle」，確實自己就是一個安全名詞。

一方面，可能安全人員之間說SDL或SDLC不會有歧義但與開發等交流就會有問題；另外一方面，當下安全所謂的SDL就是指安全人員要介入到軟件開發生命週期的整個流程中，在開發框架大致不變基礎上建設安全。因此如今書面形式上更多使用S-SDLC（Secure Software Development Lifecycle）的說法（好比OWASP）。

 

2.2 SDLC的含義

咱們前面說，當下在安全行業中，SDL、SDLC、S-SDLC都是一個意思，都是指介入到「Software Development Lifecycle」中建設安全，那具體怎麼個建設法呢。

咱們知道軟件開發生命週期能夠分爲可行性分析、需求分析、設計、編碼、測試、上線、運維幾個階段。在最開始的時候，軟件通常是都不作安全的基本都是在運維階段發現安全漏洞後再去進行修復；在開始作安全後發現不少漏洞徹底能夠在上線時自我檢測發現（不少公司如今都是作到這一步在上線時設置安全關卡）；在積累到必定程度後人們又發現，檢測出的不少安全問題要麼都是同類緣由引發的（好比SQL注入都是由於使用拼接形式）要麼就是由於軟件架構緣由修改工做量至關大（好比原來沒有水平越權防禦數據庫的全部資源都沒有權限標識），若是安所有門在編碼等更早階段介入那就能夠更多避免」翻工「的狀況。

總而言之，安全中的SDLC就是指將原來集中在軟件開發生命週期後期進行的工做，散佈到軟件開發生命週期各個階段去，在每一個階段作安全該作能作的事。

 

3、SDLC各階段安全可作的事情

3.1 軟件開發開始前

安全培訓：主要是告訴開發安全是什麼、安全要作什麼、安全怎麼作的。可選的一些主題，如」滲透測試方法「、」滲透測試工具使用「、」某種語言的安全編碼規範「等。

 

3.2 可行性分析階段

法律法規可行性分析----針對要開發的系統，衡量其是否違背法律法規，或者有哪些須要注意的點。

 

3.3 需求分析階段

安全編碼規範----參與需求分析會議，瞭解需求，針對需求擬定相應的安全編碼規範。

 

3.4 設計階段

各方案數據流圖----要求開發提供數據流圖、設計文檔，對各方案進行安全評審。

 

3.5 編碼階段

靜態代碼審計（SAST）----使用Fortify、Sonarqube等工具對代碼進行掃描，一方面理解代碼是否按設計實現，另外一方面看是否有存在問題的地方。注意靜態代碼掃描誤報通常會比較大要注意先本身確認，而不要一把就給開發。

 

3.6 測試階段

第三方組件列表----要求開發整理使用到的的第三方組件列表，做爲運維階段的輸入。主要包括組件名稱、組件官網、當前使用組件版本等列。

端口矩陣列表----要求開發整理端口矩陣列表。主要包括進程名、運行用戶、監聽IP、監聽端口等列。

手工滲透----對系統進行手工滲透測試。可參考「滲透測試思路總結 」。

 

3.7 上線階段

基線掃描----自行編寫基線規範檢測程序，在上線時要保證主機和服務都符合基線規範。可參考「安全基線自動化掃描、生成報告、加固的實現（以Tomcat爲例） 」。

網絡掃描----使用Nessus等網絡掃描器對主機進行掃描，確保服務器上運行的服務軟件沒有什麼重大漏洞。

web掃描----使用AWVS等掃描器對web進行掃描，確保別人使用這些通用工具也掃不出什麼問題。

 

3.8 運維階段

第三方組件最新版本跟蹤----在提供的第三方組件列中中添加最新版本一列，編寫自動追蹤腳本每次運行就能夠在「最新版本」列顯示最新版本。可參考「Python3第三方組件最新版本追蹤實現 」。

第三方組件CVE跟蹤----編寫腳本，天天爬取更新的CVE並篩選出產品使用的全部第三方組件的CVE。可參考「最強半自動化抓雞工具打造思路 」。

應急響應中心----包括SRC郵箱、SRC網站。