當今競爭激烈的商業環境要求企業快速行動并保持創新。因此，80%或更多的企業采用了敏捷開發方法。不幸的是，這種更高的開發速度為網絡犯罪分子帶來了幾個利用的機會，特別是在軟件生命周期過程不安全的情況下。

那么，企業如何使敏捷開發實踐更具安全性呢?以下是信息安全論壇推薦的10條原則：

定義角色和職責

負責指導敏捷項目的高級領導必須明確定義安全活動的角色和責任，這包括建立正式和非正式的報告渠道，以及項目管理行動，如上報協議、強制性會議和向安保團隊報告項目狀態。這將有助于將安全嵌入到靈活的應用程序開發中，同時促進承諾、責任以及業務IT和安全代表之間的建設性關系。

投資于技能和培訓

安全是一項團隊職責，每個開發人員都需要在確保代碼沒有安全漏洞方面發揮自己的作用。開發人員通常缺乏對安全問題的知識和理解，他們傾向于將軟件交付置于安全問題之上。為了增強開發人員的能力，企業必須在指導和提高技能方面投入資源，這包括安全培訓和認知課程、高級開發人員的指導、專門的敏捷安全培訓活動，以及訪問免費可用的資源，如OWASP、CWE、BSIMM(構建成熟模型中的安全)、SAFECode和CERT。

應用信息風險管理流程

從一開始就確保安全措施成本更低，效率更高，而不是事后事項。領導層必須建立有助于在整個開發生命周期中管理信息風險的流程。

這包括從安全角度商定高級別應用程序架構、確定“安全關鍵”應用程序和功能的列表、執行業務影響評估、在早期階段進行信息風險和脆弱性評估，以及報告新確定的風險的流程。領導層應該就誰擁有信息風險提供指導，定義審查風險的流程，并確定如何做出風險管理決策。

使用開發人員的格式指定安全要求

使用開發人員的格式(用戶故事、軟件需求規范、故事映射、線框、角色和用例)來闡明安全需求，以便開發人員能夠更好地理解、定義和實現安全規范。

這使得安全需求可以被視為產品待辦事項中的功能需求，并將其轉換為任務(也稱為分解)，將它們合并到需求管理工具中，并將它們包括在項目的生產力度量中。

進行威脅建模

定期進行威脅建模練習，以了解應用程序的安全環境，發現設計中不安全的方面，識別、分析威脅并確定威脅的優先順序，發現用于攻擊應用程序的最常見技術和方法(欺騙、篡改、拒絕服務、權限提升)，確定哪些威脅需要額外的安全測試，最重要的是，制定策略和解決方案以主動緩解每個威脅。

采用安全編程技術

要求開發人員利用已建立的安全編程技術，例如重構、持續改進/持續開發(CI/CD)、同行評審、安全迭代和測試驅動開發。

這改進了應用程序代碼的非功能質量，并有助于消除允許利用安全漏洞的編程缺陷。安全編程技術還有助于指導在安全方法方面缺乏經驗的開發人員，使用AI或低代碼/無代碼等新技術，開發復雜應用程序的一個方面，集成第三方應用程序，或滿足合規性要求。

執行獨立的安全審查

讓獨立的審查者執行靜態代碼分析(審閱源代碼，以分析應用程序代碼中的錯誤、錯誤和漏洞)和動態分析(檢查執行期間的應用程序行為，以確定異常或意外行為)。這為利益相關者提供了應用程序滿足安全要求且不包含任何安全漏洞的保證。

自動執行安全測試

對于安全團隊來說，手動測試和評估每個敏捷迭代通常是不可行的，這就是有必要采用某種類型的自動化來持續檢查應用程序代碼的安全性以發現缺陷和漏洞的原因，確保安全相關任務一致且有條不紊地完成，分析安全事件，并減輕安全團隊和開發人員的負擔。然而，一切都不可能是自動化的，自動化也不能完全取代人工測試，例如，一個人需要手動檢查以確定邏輯缺陷。

在驗收標準中包括安全性

創建、溝通和維護一套標準的安全驗收標準，以確認已經執行了對應用程序代碼的獨立審查，已經完成了安全測試，合并到應用程序中的代碼部分是可維護的、可跟蹤的，并且來自經過驗證的、信譽良好的來源，已經成功地滿足了迭代積壓的要求，已經解決了所有缺陷，包括安全漏洞，并且已經識別和批準了任何可能影響安全性的設計變更。

這有助于減少技術債務，向利益相關者提供保證，并在應用程序代碼交付之前驗證安全驗收標準已完全滿足。

評估安全性能

敏捷項目通常包括有限的安全性能評估，這使得企業很難確定其應用程序的安全性是否符合業務要求。因此，企業必須根據一組商定的KPI來監控和評估適當的安全指標。

安全指標可以包括安全漏洞的類型、數量和嚴重程度、獨立測試的結果、已批準和未批準的安全策略偏差的數量、未違反安全措施的時間長度以及其他缺陷消除指標。

如果你的開發是敏捷的，那么信息安全就必須效仿，這就是建議所有企業遵循上述安全原則和最佳做法的原因。安全的成功取決于各方(開發人員、項目經理、執行團隊等)之間的協作和承諾程度。如果安全流程可以像編碼一樣進行快速迭代和改進，那么只有這樣才能在當地提供更好的應用程序安全性和有效的更改。