應用程序安全方法論和最佳實踐已經有十多年的歷史，其中“安全開發成熟度模型”（BSIMM）是被企業采用多年，用來跟蹤安全開發成熟度進度的重要模型。上周，Synopsys發布了基于BSIMM11模型的報告，對基于金融服務、軟件、云計算和醫療等9個垂直行業的130家公司的軟件安全實踐進行了分析，揭示了以下四個應用安全趨勢：

　　·工程導向的軟件安全性工作正在成功地推動DevOps價值流追求彈性；

　　·軟件定義的安全治理不再只是抱負；

　　·安全性正在成為質量實踐的一部分，而質量實踐則被視為可靠性的一部分，而這一切都是為了追求彈性；

　　·“左移”正變成“無處不在”。

　　BSIMM11模型將121種不同的軟件安全性指標歸納為四個主要領域：治理、情報、安全軟件開發生命周期（SSDL）接觸點和部署，企業可通過模型的專有標準對軟件安全實踐進行衡量。上述每個領域都可進一步細分為三個實踐類別，其中包含從簡單到非常成熟的眾多活動。

　　與先前的報告類似，BSIMM11分析顯示，大多數企業都達到了基本要求，包括執行外部滲透測試以及在整個開發過程中進行基本軟件安全培訓之類的活動。

　　以下，是BSIMM11報告中企業安全開發實踐中最常見的十二項活動（上圖），可以作為企業保持行業安全同步的最低參照基準：

　　治理：策略和指標

　　活動：實施生命周期治理

　　組織中最常見的基礎活動之一是實施生命周期治理，其中包括發布條件，例如入口、檢查點、圍欄和里程碑。根據BSIMM11，有90％的組織已實施生命周期治理。而且許多組織正走得更遠，并且也執行治理策略。例如，47％的組織還通過度量和跟蹤異常來驗證發布條件。

　　治理：合規與政策

　　活動：確定PII（個人身份信息）義務

　　大約86％的組織可通過明確其對個人身份信息（PII）的義務來滿足法規要求。這是最常見的合規性活動，同時，有72％的組織能在所有監管標準中統一其觀點和實踐。BSIMM11表明，隨著時間的推移，組織也將通過履行其義務來逐步提高其合規能力。在過去兩年中，積極在其應用程序組合中建立受保護的PII存儲庫的企業的數量已增加了10個百分點，達到42％。同樣，在同一時間范圍內，實施和跟蹤合規控制措施的組織所占比例從36％上升到47％。

　　治理：培訓

　　活動：進行安全意識培訓

　　在組織范圍內進行某種形式的安全意識培訓已成為企業應用開發組織的行業規范，但即便如此仍然有很多企業未能遵守。據BSIMM11稱，只有大約64％的企業對其軟件相關人員進行了至少一個安全意識入門課程的培訓，即使這些課程是針對特定受眾量身定制。同時，針對特定角色的安全意識培訓已經很常見，但還尚未成為主流，只有29％的組織從事此活動。

　　情報：攻擊模型

　　活動：創建數據分類方案和清單

　　當今，大多數軟件組織在威脅建模、開發濫用案例以及攻擊者思維方面的成熟度還很低。據BSIMM11報告，只有63％以上的組織能夠做到這方面的最低要求，即通過創建數據分類方案和清單，根據存儲的數據和對攻擊者的吸引力來優先考慮應用程序的重要性或風險級別。同時，只有8％的組織建立了與潛在攻擊者相關的攻擊模式和濫用案例，在過去幾年中，這一比例一直保持穩定。

　　情報：安全功能和設計

　　活動：集成并提供安全功能

　　為了滿足安全性可重復的需求，許多組織接受了提供主動指導和代碼以提供預先批準的安全性功能的實踐，這些安全性功能包括以模塊方式提供的功能，例如身份驗證、角色管理和加密。這樣，開發人員不必每次在項目中添加這些標準功能時重新發明車輪。根據BSIMM11，大約78％的組織參與了此應用安全活動。在安全功能和設計方面，仍有很大的發展空間。例如，盡管許多組織向開發團隊提供這些功能資源，但只有11％強制要求使用規定列表或存儲庫中的批準的安全功能和框架。

　　情報：標準和要求

　　活動：將合規性約束轉換為需求

　　認識到開發人員不是法規遵從專家（這也不是他們的本職工作），當今許多安全組織正在承擔將諸如PCI DSS標準之類的內容解釋為軟件需求的重任。根據BSIMM11，今天大約有72％的組織在這樣做。將近72％的組織創建了安全標準，以解釋從基于身份的身份驗證到如何配置開發人員基礎結構的所有事務遵守企業策略的必需方法。

　　SSDL接觸點：架構分析

　　活動：執行安全功能審查

　　根據BSIMM11，現在大約88％的組織會對所開發的軟件執行某種安全功能審查。通常，這仍然是大多數組織分析其軟件體系結構安全性的唯一方法，但是業界正在此基礎上發展。在過去的兩年中，對高風險應用程序進行設計審查的組織所占的比例已提高了5個百分點，達到32％。

　　SSDL接觸點：代碼審查

　　活動：使用自動化工具以及手動審核

　　DevSecOps運動和安全擁護者的多年倡導，提高了業界對代碼審查過程自動化的重視。據BSIMM11稱，出于效率和一致性的考慮，現在將近77％的組織將靜態分析合并到代碼審查過程中。對自動化的使用更是五花八門，有些組織將自動化審查構建到代碼管理或交付管道工作流程中。但是，這些代碼審查工具并不是始終如一地強制執行。只有38％的組織要求所有項目都必須進行代碼審查。

　　SSDL接觸點：安全性測試

　　活動：確保質量檢查支持邊緣/邊界值條件測試

　　代碼審查只是對已部署軟件的安全性進行可靠審查的第一步。其他安全性測試（例如黑盒測試）可檢測軟件構建過程中的漏洞。據BSIMM11稱，至少有八成組織的質量檢查團隊超出了功能測試范圍，可以執行基本的對抗性測試，并探查簡單的邊緣情況和邊界條件。但是在其他許多方面仍然有很大的發展空間。例如，只有32％的組織將黑盒安全工具集成到質量檢查流程中。

　　部署：滲透測試

　　活動：使用外部滲透測試人員來發現問題

　　使用外部滲透測試人員是大多數軟件團隊進行滲透測試的必選項。根據BSIMM11，近88％的人使用外部滲透測試人員來提供代碼和配置中可利用漏洞的證據。此外，有77％的企業將這些測試的結果用于漏洞管理和緩解系統，并有68％的人通過紅隊測試和其他內部引導的滲透測試來作為外部滲透測試結果的備份。

　　部署：軟件環境

　　活動：確保主機和基礎網絡安全措施到位

　　BSIMM11發現，主機和網絡安全基礎安全措施是所有組織中最常見的軟件安全措施。大約93％的組織表示首先要確保的是運行軟件的數據中心和網絡資產的安全性，因為該報告指出：“在主機和網絡的安全性沒有確保之前，談論應用安全性就像先穿鞋后穿襪子。”

　　部署：配置管理和漏洞管理

　　活動：創建事件響應或與事件響應交互

　　盡管許多組織在跟蹤和修復軟件錯誤方面非常掙扎，但至少83％的企業已在開發人員和安全事件響應人員之間建立了某種形式的接口。此外，有78％的受訪者還報告說，他們通過運行監控發現了軟件缺陷，并將其反饋給開發人員。但是，更高級的活動（例如使用運營中識別的錯誤信息來運行軟件事件響應模擬，以改善安全軟件開發生命周期）仍然難以實現，只有8％的人從事這項活動。