2.1.3 SAFE Code

軟件保障卓越代碼論壇（SAFECode）是一個非營利性、全球性、行業(yè)主導(dǎo)的組織，致力于通過推進有效的軟件保障方法。SAFECode的使命是推廣開發(fā)和提供更安全、更可靠的軟件、硬件和服務(wù)的最佳實踐。SAFECode組織發(fā)布了“安全軟件開發(fā)的基本實踐：安全開發(fā)生命周期計劃的基本要素”指南，以促進整個行業(yè)的發(fā)展采用基本的安全開發(fā)實踐。基本實踐涉及保證-軟件抵御試圖利用設(shè)計或?qū)崿F(xiàn)錯誤的攻擊的能力。其指南中概述的八項基本做法如下所述：

1.    應(yīng)用程序安全控制定義。SAFECode使用術(shù)語應(yīng)用程序安全控制（ASC）來指代安全要求（請參閱第2.1.1節(jié)第2點）。同樣，NIST 800-53使用短語安全控制來指代安全功能和安全保證要求。

ASC的輸入包括以下內(nèi)容：安全設(shè)計原則（見第2.1.3節(jié)第3點）;安全編碼實踐;應(yīng)用程序需要遵守的法律和行業(yè)要求（例如HIPAA、PCI、GDPR或SCADA）;內(nèi)部政策和標(biāo)準(zhǔn);事件和其他反饋;威脅和風(fēng)險。ASC的開發(fā)在設(shè)計階段之前就開始了，并貫穿整個生命周期，以提供清晰和可操作的控制，并響應(yīng)不斷變化的業(yè)務(wù)需求和不斷變化的威脅環(huán)境。

2.    設(shè)計。軟件必須包含安全功能，以符合內(nèi)部安全實踐和外部法律或法規(guī)。此外，軟件必須根據(jù)操作環(huán)境抵御已知威脅。（請參閱第2.1.1節(jié)第5點。威脅建模（請參閱第2.1.1節(jié)第4點）、架構(gòu)評審和設(shè)計評審可用于在將設(shè)計缺陷實施到源代碼之前識別和解決設(shè)計缺陷。

系統(tǒng)設(shè)計應(yīng)包含加密策略（請參閱第2.1.1節(jié)第6點），以保護敏感數(shù)據(jù)在靜態(tài)或傳輸過程中免遭意外泄露或更改。

系統(tǒng)設(shè)計應(yīng)使用標(biāo)準(zhǔn)化的身份和訪問管理方法來執(zhí)行身份驗證和授權(quán)。標(biāo)準(zhǔn)化提供了組件之間的一致性，并就如何驗證是否存在適當(dāng)?shù)目刂铺峁┝嗣鞔_的指導(dǎo)。驗證主體（無論是人類用戶、其他服務(wù)還是邏輯組件）的身份并驗證執(zhí)行操作的授權(quán)是系統(tǒng)的基本控制。已經(jīng)開發(fā)了幾種訪問控制方案來支持授權(quán)：強制性、自由裁量權(quán)、基于角色或基于屬性。這些都有優(yōu)點和缺點，應(yīng)根據(jù)項目特征進行選擇。

日志文件在發(fā)生違規(guī)時提供取證分析所需的證據(jù)，以減輕否認(rèn)威脅。在設(shè)計良好的應(yīng)用程序中，系統(tǒng)和安全日志文件提供了了解應(yīng)用程序行為及其隨時使用方式的能力，并區(qū)分善意的用戶行為和惡意用戶行為。由于日志記錄會影響可用的系統(tǒng)資源，因此日志記錄系統(tǒng)應(yīng)設(shè)計為捕獲關(guān)鍵信息，同時不捕獲過多數(shù)據(jù)。需要圍繞存儲、防篡改和監(jiān)控日志文件建立策略和控制。OWASP為設(shè)計和實施日志記錄提供了寶貴的資源1415.

3.     安全編碼實踐。意外的代碼級漏洞是由程序錯誤引入的。這些類型的錯誤可以通過使用編碼標(biāo)準(zhǔn)來預(yù)防和檢測;選擇最合適（和安全）的語言、框架和庫，包括使用它們相關(guān)的安全功能（見第8節(jié)）;使用自動分析工具（見第2.1.1節(jié)項目符號9和10）;以及手動審查代碼。

組織為安全編碼提供標(biāo)準(zhǔn)和指南，例如：

(a)OWASP安全編碼實踐，快速參考指南

(b) OracleSecure Coding Guidelinesfor Java SE 

(c)軟件工程研究所（SEI）CERT安全編碼標(biāo)準(zhǔn)

還必須特別注意通過記錄事件的通用錯誤處理程序或異常處理程序以受控和優(yōu)雅的方式處理意外錯誤。如果調(diào)用泛型處理程序，則應(yīng)將應(yīng)用程序視為處于不安全狀態(tài)，以便不再將進一步執(zhí)行視為受信任。

4.     管理使用第三方組件時固有的安全風(fēng)險。見第2.1.1節(jié)第7點。

5.    測試和驗證。見第2.1.1節(jié)第9-11點和第2.1.2節(jié)第1、3和4點。

6.     管理安全發(fā)現(xiàn)。前五個實踐生成的工件包含或生成與產(chǎn)品安全性（或缺乏安全性）相關(guān)的發(fā)現(xiàn)。應(yīng)跟蹤這些工件中的發(fā)現(xiàn)，并采取措施修復(fù)漏洞，例如通用準(zhǔn)則（請參閱第4.3節(jié)）缺陷修復(fù)程序中列出的漏洞[36].或者，當(dāng)確定風(fēng)險可接受時，團隊可能會有意識地接受安全風(fēng)險。必須跟蹤風(fēng)險的接受情況，包括嚴(yán)重性等級;補救計劃、到期或重新審查截止日期;以及重新審查/驗證的區(qū)域。

明確嚴(yán)重性定義對于確保所有參與者對安全問題及其潛在影響有一致的理解非常重要。可能的起點是映射到通用漏洞評分系統(tǒng)（CVSS）19使用的嚴(yán)重性級別、屬性和閾值，例如10–8.5表示嚴(yán)重，8.4–7.0表示高等。嚴(yán)重性級別用于根據(jù)緩解措施的利用復(fù)雜性和對系統(tǒng)屬性的影響來確定緩解措施的優(yōu)先級。

7.     漏洞響應(yīng)和披露。即使遵循安全的軟件生命周期，由于不斷變化的威脅，沒有產(chǎn)品可以“完全安全”。漏洞將被利用，軟件最終將受到損害。組織必須制定漏洞響應(yīng)和披露流程，以幫助推動解決外部發(fā)現(xiàn)的漏洞，并讓所有利益相關(guān)者了解進度。ISO為漏洞消除和處理提供了經(jīng)過行業(yè)驗證的標(biāo)準(zhǔn)20。為了防止漏洞在新產(chǎn)品或更新的產(chǎn)品中再次出現(xiàn)，團隊?wèi)?yīng)執(zhí)行根本原因分析，并將經(jīng)驗教訓(xùn)反饋到安全軟件生命周期實踐中。有關(guān)進一步討論，請參閱第2.1.1節(jié)第12點和2.1.2項目符號7。

8.     規(guī)劃安全開發(fā)的實現(xiàn)和部署。一個健康和成熟的安全開發(fā)生命周期包括上述七種實踐，但也包括將這些實踐集成到業(yè)務(wù)流程和整個組織中，包括項目管理、利益相關(guān)者管理、部署規(guī)劃、氣象和指標(biāo)，以及持續(xù)改進的計劃。在規(guī)劃部署安全軟件生命周期時，需要考慮組織的文化、專業(yè)知識和技能水平。根據(jù)過去的歷史，組織可能會更好地響應(yīng)公司任務(wù)、自下而上的風(fēng)浪方法或一系列試點計劃。將需要培訓(xùn)（見第2.1.1節(jié)第1點）。應(yīng)記錄組織安全軟件生命周期的規(guī)范，包括角色和職責(zé)。應(yīng)制定合規(guī)性和過程運行狀況計劃（請參閱第4節(jié)）。

2.2 比較安全軟件生命周期模型

2009年，德溫等.比較了CLASP、Microsoft最初記錄的SDL[3]和接觸點（參見第2.1.2節(jié)），以便就它們的共性提供指導(dǎo)以及方法的具體性，并提出改進建議。作者將每個生命周期模型的153種可能活動映射到六個軟件開發(fā)階段：教育和意識;項目啟動;分析和需求;架構(gòu)和詳細(xì)設(shè)計;實施和測試;以及發(fā)布、部署和支持。這些活動將第2.1.1–2.1.3節(jié)中的做法提升到更精細(xì)的粒度。作者指出了每個模型是否包括153個活動中的每一個，并就每個模型的優(yōu)缺點提供了指導(dǎo)。作者發(fā)現(xiàn)模型中沒有明確的全面“贏家”，因此從業(yè)者可以考慮使用指南來獲得所有模型中所需的細(xì)粒度實踐。

表1將第2.1.1-2.1.3節(jié)的實踐分為DeWin等人使用的六個軟件開發(fā)階段。與之前的工作類似，這些模型在六個軟件開發(fā)階段的指導(dǎo)方面展示了優(yōu)勢和劣勢。沒有任何模型可以被認(rèn)為是適用于所有情況的完美模型。安全專家可以考慮六個軟件開發(fā)階段實踐的傳播情況，為其組織定制模型。