S-SDLC影響因素分析*

顧先華，施 勇，薛 質(zhì)

（上海交通大學(xué) 電子信息與電氣工程學(xué)院，上海200240）

0 引 言

安全一直是軟件開發(fā)的一個(gè)重要研究領(lǐng)域。在當(dāng)今復(fù)雜的威脅形勢下，從頭開始將安全性構(gòu)建進(jìn)軟件開發(fā)比以往任何時(shí)候都更加重要。當(dāng)今客戶需要開箱即用的高度安全的產(chǎn)品和服務(wù)，如果沒有標(biāo)準(zhǔn)化的方法，幾乎不可能第一時(shí)間實(shí)現(xiàn)客戶對(duì)安全的期望和合規(guī)要求。目前，已經(jīng)有大量理論研究與最佳實(shí)踐來規(guī)范軟件開發(fā)流程中的安全問題。例如，Microsoft SDL[1]和OWASP CLASP[2]是一系列軟件開發(fā)安全實(shí)踐指南，在開發(fā)過程的所有階段均引入了安全和隱私；BSIMM[3]和OpenSAMM[4]是安全評(píng)估機(jī)構(gòu)評(píng)估企業(yè)軟件安全的成熟度模型，通過描述和量化實(shí)際運(yùn)行結(jié)果來不斷構(gòu)建和發(fā)展模型，從而形成指導(dǎo)；安全質(zhì)量需求工程（Security Quality Requirements Engineering，SQUARE）[5]是需求工程的安全升級(jí)版，可納入S-SDLC需求階段。

當(dāng)企業(yè)到達(dá)一定規(guī)模時(shí)，安全開發(fā)必不可少，國內(nèi)開始有大量中型互聯(lián)網(wǎng)創(chuàng)業(yè)企業(yè)初步實(shí)施S-SDLC。如果嚴(yán)重影響用戶使用或業(yè)務(wù)需求，高安全性將變得毫無價(jià)值。無論是高安全軟件的低可用性，還是敏捷開發(fā)的連續(xù)性受限，對(duì)于習(xí)慣快速開發(fā)的軟件公司都是無法接受的。因此，需要在安全性和可用性之間找到一個(gè)平衡點(diǎn)，它們不是直接負(fù)相關(guān)的，而是間接互相影響。

本文第1章介紹S-SDLC中SDL和SDL-Agile兩種模型；第2章描述S-SDLC執(zhí)行現(xiàn)狀、主要問題以及預(yù)期解決思路；第3章根據(jù)傳統(tǒng)安全屬性和產(chǎn)品開發(fā)的某些因素進(jìn)行評(píng)估，并使用層次分析法進(jìn)行分析，希望了解S-SDLC執(zhí)行困難背后的原因以及執(zhí)行配合過程中各個(gè)部門的不同視角；第4章將利用本文方法對(duì)某企業(yè)的S-SDLC落地實(shí)施進(jìn)行改進(jìn)。

1 安全軟件開發(fā)生命周期

1.1 SDL

Microsoft SDL[1]在軟件研發(fā)過程中的所有階段都加入了安全實(shí)踐，幫助開發(fā)人員構(gòu)建高安全性的軟件，減少開發(fā)成本，并解決安全合規(guī)需求。在大型數(shù)據(jù)泄露事件和安全漏洞利用事件之后，越來越多的開發(fā)人員開始意識(shí)到在整個(gè)開發(fā)過程中都需要解決安全問題。

在軟件開發(fā)生命周期中解決問題的時(shí)間越晚，修復(fù)所花費(fèi)的成本就越高，安全問題也不例外。在一次安全事件爆發(fā)時(shí)，所有業(yè)務(wù)的中斷會(huì)導(dǎo)致經(jīng)濟(jì)損失，追溯漏洞到軟件的每個(gè)版本時(shí)會(huì)導(dǎo)致人力成本和時(shí)間成本的增加，甚至需要重構(gòu)整個(gè)軟件架構(gòu)。例如，人們最關(guān)心的數(shù)據(jù)庫安全，可能涉及到數(shù)據(jù)編碼安全、數(shù)據(jù)加密安全、數(shù)據(jù)庫通信安全、數(shù)據(jù)來源認(rèn)證安全、數(shù)據(jù)庫訪問用戶身份認(rèn)證和權(quán)限問題、數(shù)據(jù)庫錯(cuò)誤處理和日志、數(shù)據(jù)備份、敏感信息脫敏處理及SQL注入漏洞等問題。如果能夠在軟件設(shè)計(jì)階段或者迭代開發(fā)的設(shè)計(jì)階段考慮以上問題，那么就可以把修復(fù)漏洞的人力成本、時(shí)間成本融入開發(fā)成本，安全人員的身份會(huì)從消防員變?yōu)榫?，將緊急安全事件的救火處理變?yōu)轭A(yù)防和指導(dǎo)性工作，做到防患于未然。

遵循安全軟件開發(fā)的最佳實(shí)踐是將安全性集成到軟件開發(fā)生命周期的每個(gè)階段，從需求分析到運(yùn)維，無需考慮開發(fā)模式是瀑布式、敏捷還是DevOps。Microsoft SDL階段分為培訓(xùn)、需求、設(shè)計(jì)、實(shí)踐、驗(yàn)證、發(fā)布和響應(yīng)，如圖1所示。

圖1 Microsoft SDL階段

1.2 SDL-Agile

敏捷開發(fā)的主要?jiǎng)恿κ荢print，為某一組功能設(shè)計(jì)、開發(fā)和測試，然后交付給客戶，通常為15～60 d。要添加到產(chǎn)品中的功能列表是產(chǎn)品待辦事項(xiàng)（Product Backlog），也可稱其為需求池。在開始Sprint之前，從產(chǎn)品待辦事項(xiàng)列表中選擇一部分功能列表加入到Sprint待辦事項(xiàng)列表中。SDL的實(shí)踐任務(wù)可以視為非功能性需求，積壓在產(chǎn)品和Sprint待辦事項(xiàng)列表中。

為了使重量級(jí)的SDL需求適合輕量的敏捷框架，SDL-Agile[6]將每個(gè)SDL需求和優(yōu)先級(jí)放置在按完成頻率定義的3個(gè)類別中，如圖2所示。

圖2 一次Sprint的SDL-Agile需求池

第一類Every-Sprint需求包括對(duì)安全至關(guān)重要的需求，是每次發(fā)布的前提，如合規(guī)、Web輸出使用過濾和轉(zhuǎn)義庫、自動(dòng)化靜態(tài)掃描等。

第二類Bucket需求包括必須在項(xiàng)目生命周期內(nèi)定期執(zhí)行的任務(wù)，但這些任務(wù)可以不必每個(gè)Sprint都執(zhí)行，可以作為主要發(fā)行版的前提，如滲透測試、模糊測試、攻擊面分析及二進(jìn)制分析等。

第三類One-Time需求包括一次性需求，在規(guī)定長達(dá)如一年的時(shí)間段內(nèi)完成，如創(chuàng)建基準(zhǔn)威脅模型、制定安全響應(yīng)計(jì)劃、確定團(tuán)隊(duì)安全專家及使用最新的編譯器版本等。

2 S-SDLC執(zhí)行現(xiàn)狀

2.1 S-SDLC模型的采用

許多軟件開發(fā)企業(yè)都使用敏捷開發(fā)和管理方法來構(gòu)建軟件。從歷史上看，單純使用敏捷方法開發(fā)軟件時(shí)，幾乎不包含安全性。這是由于敏捷方法專注于快速滿足客戶直接需求的功能，而安全性作為潛在需求并未得到應(yīng)有的重視。改變觀念和現(xiàn)狀的唯一方法是將安全要求集成到敏捷開發(fā)方法中。

但是，從敏捷的角度來看，SDL模型非常重要，會(huì)嚴(yán)重拖慢開發(fā)速度，成為敏捷的阻礙，因?yàn)镾DL模型設(shè)計(jì)之初是用于保護(hù)大型產(chǎn)品（例如Windows和Microsoft Office）的安全，而這兩個(gè)產(chǎn)品都有很長的開發(fā)周期。

使用SDL-Agile模型，將安全要求集成到敏捷開發(fā)方法中，必須將添加到敏捷流程中的SDL安全實(shí)踐進(jìn)行精簡。也就是說，僅對(duì)新增或升級(jí)的功能執(zhí)行足夠的SDL安全實(shí)踐。其次，將SDL安全實(shí)踐拆分成可快速執(zhí)行的輕量任務(wù)，因?yàn)榻?jīng)典的設(shè)計(jì)-實(shí)踐-驗(yàn)證-發(fā)布的瀑布式SDL開發(fā)過程不適用于敏捷開發(fā)。此外，安全合規(guī)是創(chuàng)業(yè)公司達(dá)到一定規(guī)模招聘安全團(tuán)隊(duì)關(guān)注的重點(diǎn)，也是公司產(chǎn)品可售賣的有利指標(biāo)。

目前，國內(nèi)如華為已經(jīng)進(jìn)行了9年的安全開發(fā)流程規(guī)范，而中小型互聯(lián)網(wǎng)企業(yè)大多剛剛起步，且全面推進(jìn)安全開發(fā)流程有來自方方面面的阻礙。針對(duì)后者，本文希望探討S-SDLC執(zhí)行的困難本質(zhì)。

2.2 推行S-SDLC的主要措施

通常企業(yè)會(huì)優(yōu)先聘請(qǐng)安全技術(shù)專家或顧問來應(yīng)急處理一些安全事件，以應(yīng)付可能出現(xiàn)網(wǎng)絡(luò)安全、操作系統(tǒng)安全等運(yùn)維問題，在形成一定的應(yīng)急響應(yīng)流程后，開始考慮S-SDLC。

對(duì)于產(chǎn)品發(fā)布、質(zhì)量管理及風(fēng)險(xiǎn)把控，S-SDLC中最有效的部分是安全測試。定義一份內(nèi)部的安全測試服務(wù)等級(jí)協(xié)議（Service-Level Agreement，SLA）是一種短期可行的方法，但是這只提供了一種服務(wù)，只是執(zhí)行了眾多安全實(shí)踐中的一種或兩種測試，沒有收集安全需求，也沒有形成安全策略，甚至是在產(chǎn)品上線售賣后做安全測試，以期形成文檔完成客戶或合作商的安全要求。在實(shí)際處理漏洞時(shí)，常采用主機(jī)層面一鍵升級(jí)和網(wǎng)絡(luò)層面關(guān)閉端口的方式繞過掃描器的掃描。

在考慮完整SDL模型或SDL-Agile的過程中，首先保留各種安全測試，如靜態(tài)掃描、滲透測試及模糊測試等，然后根據(jù)產(chǎn)品迭代周期和開發(fā)節(jié)奏，在主要發(fā)行版執(zhí)行安全測試。

2.3 主要問題及解決思路

當(dāng)安全測試的漏洞反饋到開發(fā)人員的時(shí)候，沒有預(yù)留出足夠的修復(fù)時(shí)間，導(dǎo)致無法在當(dāng)前版本修復(fù)漏洞。盡管已經(jīng)協(xié)商定義好時(shí)間和人力成本，但是安全測試相對(duì)于功能測試來說，漏洞數(shù)不定，修復(fù)技術(shù)方案可大可小，嚴(yán)重的甚至需要進(jìn)行應(yīng)用系統(tǒng)重構(gòu)，此為問題一。

從安全技術(shù)人員的角度看，能夠把握安全漏洞的嚴(yán)重程度和可利用性。但是，在業(yè)務(wù)方面，對(duì)于實(shí)際可能造成的財(cái)產(chǎn)損失以及客戶要求無法提出強(qiáng)有力的觀點(diǎn)，缺少業(yè)務(wù)上的反饋形成良性循環(huán)，此為問題二。

對(duì)于敏捷開發(fā)來說，敏捷是最重要的。所有會(huì)耽誤時(shí)間的緊急需求都可以推到下一次開發(fā)周期中，常見的產(chǎn)品版本排期人員是產(chǎn)品經(jīng)理，需要產(chǎn)品經(jīng)理的意見。

對(duì)于公司來說，業(yè)務(wù)利益相關(guān)者能夠推動(dòng)緊急需求，促成安全漏洞的修復(fù)和S-SDLC的落實(shí)，需要項(xiàng)目經(jīng)理的意見。

在此基礎(chǔ)上，希望了解S-SDLC中各個(gè)人員所關(guān)注的地方來進(jìn)行影響因素分析，得到一個(gè)較為立體的問題面來做針對(duì)性的修改流程。

3 S-SDLC影響因素分析

3.1 意見收集

本文向某家2 000人規(guī)模的試運(yùn)行半年S-SDLC的企業(yè)進(jìn)行調(diào)查，向各個(gè)部門的安全負(fù)責(zé)人進(jìn)行意見收集，包括產(chǎn)品經(jīng)理、發(fā)布經(jīng)理及項(xiàng)目經(jīng)理，問題如表1所示。

3.2 影響因素

根據(jù)意見內(nèi)容，提煉影響因素，如圖3所示。

3.3 影響因素分析

使用層次分析法（Analytic Hierarchy Process，AHP）[7]計(jì)算權(quán)重，結(jié)果如表2所示。

表1 意見收集的問題列表

圖3 影響因素

表2 影響因素分析

S-SDLC流程步驟是各類職能部門認(rèn)為最重要的。在執(zhí)行S-SDLC的過程中，對(duì)于各類職能部門的步驟培訓(xùn)可能更加有效和直接，減輕了工作重復(fù)性，避免了信息不同步帶來的問題。

此外，信息安全三要素之一的信息保密性。從數(shù)據(jù)安全層面來看，失去信息保密性比失去信息完整性和信息可用性性質(zhì)更嚴(yán)重。

除了信息安全方面，需要注意安全意識(shí)、安全技術(shù)知識(shí)排在前列，說明必須將安全賦能給其他職能。業(yè)務(wù)強(qiáng)制需求和安全功能都屬于需求類，在需求收集和產(chǎn)品設(shè)計(jì)中的占比不可忽視。

時(shí)間成本和安全技術(shù)方案的權(quán)重都很低，與設(shè)想有所不同，也許它們對(duì)于流程推動(dòng)可能造成影響的因素實(shí)際上遠(yuǎn)沒有信息安全的重要性更大，或者說真正影響決策的仍然是信息安全自身。

此外，如果缺乏對(duì)人員的S-SDLC相關(guān)知識(shí)的培訓(xùn)，無論是背景知識(shí)還是根據(jù)公司實(shí)際情況所做的細(xì)微流程調(diào)整，缺乏這些均會(huì)使得協(xié)同工作過程中出現(xiàn)目的不統(tǒng)一或任務(wù)質(zhì)量不達(dá)標(biāo)的情況。

4 改進(jìn)S-SDLC

盡管培訓(xùn)和信息安全在影響因素分析中占比最大，但是通過對(duì)意見的收集，能夠反映出相比于其他階段，需求收集和產(chǎn)品設(shè)計(jì)過程中考慮的因素的更多。所以，必須納入產(chǎn)品和業(yè)務(wù)的觀點(diǎn)和立場，并且在各個(gè)階段達(dá)到階段性目標(biāo)統(tǒng)一，借此來更加容易地落實(shí)S-SDLC。

改進(jìn)后的S-SDLC如圖4所示，這里省略其他階段，只展示與漏洞相關(guān)的產(chǎn)品漏洞管理流程。將產(chǎn)品版本分為主要發(fā)行版和非主要發(fā)行版兩種。主要發(fā)行版的周期通常是每一季度或每隔4～5個(gè)非主要發(fā)行版。在主要發(fā)行版實(shí)行完整安全測試，而在非主要發(fā)行版實(shí)行安全測試復(fù)測，達(dá)到敏捷的效果。主要發(fā)行版必須經(jīng)過安全把控后才能發(fā)布。主要發(fā)行版的安全測試報(bào)告會(huì)作為業(yè)務(wù)、安全和產(chǎn)品三方會(huì)議1的材料，用以對(duì)漏洞進(jìn)行優(yōu)先級(jí)判斷和大概的修復(fù)時(shí)間點(diǎn)確定。在每個(gè)版本產(chǎn)品設(shè)計(jì)前回顧之前已修復(fù)和未修復(fù)的漏洞，采用保守或根源修復(fù)方式，能夠盡可能在主要發(fā)行版完全修復(fù)。產(chǎn)品、工程和發(fā)布會(huì)使用checklist，在設(shè)計(jì)、開發(fā)和上線前檢查各個(gè)安全實(shí)踐的完成情況。

圖4 產(chǎn)品漏洞管理流程

5 結(jié) 語

本文通過層次分析法分析S-SDLC影響因素，并提出改進(jìn)版產(chǎn)品漏洞管理流程。安全開發(fā)勢在必行，但拘泥于傳統(tǒng)SDL模型會(huì)打亂產(chǎn)品開發(fā)的節(jié)奏，不能停留在紙面上。所以，使安全與敏捷開發(fā)目標(biāo)一致，能夠大幅提高相關(guān)職能人員的認(rèn)同度和配合度，是提高S-SDLC效率確實(shí)可行的實(shí)施理念。此外，本文采用的影響因素體系以及其權(quán)重分配并不是唯一固定的，應(yīng)當(dāng)根據(jù)企業(yè)實(shí)施S-SDLC的實(shí)際情況不斷調(diào)整并加以檢驗(yàn)。