2.1.3 SAFE Code

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

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

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

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

系統設計應包含加密策略（請參閱第2.1.1節第6點），以保護敏感數據在靜態或傳輸過程中免遭意外泄露或更改。

系統設計應使用標準化的身份和訪問管理方法來執行身份驗證和授權。標準化提供了組件之間的一致性，并就如何驗證是否存在適當的控制提供了明確的指導。驗證主體（無論是人類用戶、其他服務還是邏輯組件）的身份并驗證執行操作的授權是系統的基本控制。已經開發了幾種訪問控制方案來支持授權：強制性、自由裁量權、基于角色或基于屬性。這些都有優點和缺點，應根據項目特征進行選擇。

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

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

組織為安全編碼提供標準和指南，例如：

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

(b) OracleSecure Coding Guidelinesfor Java SE 

(c)軟件工程研究所（SEI）CERT安全編碼標準

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

4.     管理使用第三方組件時固有的安全風險。見第2.1.1節第7點。

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

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

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

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

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

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

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

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