自20世紀70年代軟體開發生命週期獲得突出地位以來，經歷了許多修改和調整。隨著時間的推移，終端使用者的開發需求與挑戰的演變性質結合在一起。最顯著的是安全性方面——導致了不同的軟體開發方法和方法的形成。其中一種方法是安全軟體開發生命週期(SSDLC)。

SSDLC的出現是為了應對應用程式安全性面臨的日益嚴峻的安全挑戰。涉及資料洩露、侵犯隱私和其他網路威脅的事件在當今社會非常常見，任何沒有將安全性放在首要位置的軟體開發模型很可能導致開發公司的財務和聲譽損失。

在瞭解SSDLC之前，讓我們先看看SDLC方法。

什麼是軟體開發生命週期?

軟體開發生命週期(SDLC)是一種用於開發軟體應用程式的系統而又標準化的方法。SDLC大量借鑑了一般專案管理生命週期方法中的元素，從所涉及的步驟和階段的相似性中可以明顯看出這一點。

雖然不太可能找到兩個公司應用完全相同的SDLC過程，但主要階段在大多陣列織中是常見的。

SDLC流程的主要階段

一般來說，典型的SDLC過程包含五個階段：

需求收集：開發每個應用程式是為了解決某些問題，併為使用者提供實用性。在收集需求時，開發團隊的目標是理解客戶的需求和目標，並定義以最佳方式完成專案所需的資源。

設計：在這個階段，為整個專案打下了基礎。這裡確定的一些主要細節包括程式語言、體系結構、平臺、使用者介面、通訊協議和安全性。

開發/構建：這是透過開發應用程式原始碼將所有計劃付諸實施的部分，並實現應用程式的所有功能，包括使用者介面和安全性。

測試：任何SDLC過程中最重要的組成部分之一是測試軟體的漏洞、錯誤、效能和功能。在此階段發現的任何應用程式效能問題通常會在部署之前得到糾正。

部署和維護：釋出應用程式以供預期客戶端使用。它通常包括讓應用程式得到app Store的批准，並提供下載。當然，高度專業化的企業應用通常不會在應用商店中釋出，而是直接提供給客戶。

常見軟體開發生命週期模型

SDLC流程在大部分組織中保持不變。但是，軟體開發規則手冊中沒有任何內容可以強制任何開發人員始終以一維順序遵循SDLC階段。

多年來，組織和戰略家已經嘗試了不同的SDLC模型，以更好地滿足客戶不斷變化的需求。最受歡迎的例子如下:

瀑布型

所有模型中最直接的是SDLC的瀑布式方法。在瀑布式開發中，整個開發生命週期的各個階段以固定的順序出現，從需求收集到最終部署。

V-模型

V 模型是一個線性模型。

這個模型的主要特點是它非常強調測試。這就是為什麼v模型的每個階段都有自己的測試活動，以便測試在開發的所有階段中進行，直到完成。

v模型中嵌入的廣泛測試和質量控制使它成為最昂貴和要求最高的軟體開發方法之一。因此，它只在高度專門化的情況下使用，例如對失敗和錯誤的風險容忍度很低的專案。

迭代模型

隨著組織探索非傳統和非線性的工作方法，迭代和增量模型獲得了更多的關注。開發人員可以以順序或並行的方式實現該模型。

從本質上講，迭代模型是累加的，新的軟體模組和功能被新增到每個迭代中。

迭代模型的好處在於，它們允許在任何開發階段進行調整，只要需求的變更在專案的範圍內。

迭代模型證明最有效的情況是應用程式的功能只是鬆散依賴的大型專案。

敏捷開發

在今天，敏捷開發是使用最廣泛的SDLC模型。本質上，敏捷遵循迭代式的開發風格，並且更加強調溝通和早期的客戶反饋。

敏捷模型中的每次迭代都旨在開發一個完整的模組或功能，以在應用程式的最終版本中體現出來。這意味著傳統SDLC過程中的相同步驟順序會重複多次，直到專案完成，從而導致重複測試和質量保證。

敏捷保證的軟體版本的頻繁釋出以及與客戶的溝通和反饋使其成為大多陣列織的流行選擇。

敏捷開發在以下情況下經常被採用：

需要早期客戶反饋的啟動計劃。
可以輕鬆拆分為較小部分的大型專案，每個部分都是增量開發的。
需要在SLDC中增加一個“S”

SSDLC是SDLC的一個自然發展，是為了響應現代應用程式開發環境中安全性日益上升的重要性而出現的。

簡單地說，SSDLC為旨在加強安全性的應用程式開發提供了一個結構化的框架，將安全性元素整合到SDLC的所有階段中。

在一個裝置、小玩意和電子產品氾濫的世界裡，安全漏洞可能會給個人和組織帶來災難。如果是一家公司，忽視安全可能會導致巨大的經濟損失。只需利用一個單一的漏洞就可以對一個組織的系統造成嚴重破壞。

在Facebook-Cambridge Analytica、iCloud洩露、NSA的PRISM監視計劃等嚴重資料洩露和隱私醜聞之後，歐盟GDPR和美國的CCPA 等立法框架要求組織採取資料保護措施所有相關方的安全。

在這種情況下，任何軟體開發人員都需要將安全性作為開發生命週期的每個階段的關鍵考慮因素。

SSLDC為此類安全災難提供瞭解決方案，使組織能夠最大限度地降低風險，並顯著更有效地控制其聲譽和財務安全。這是公司採用SSDLC的主要原因。

SSDLC最佳實踐

讓我們看看在將安全性整合到每個階段時如何修改經典的SDLC的這些步驟。

1.需求收集

這個階段現在的重點是準備一個安全和監管要求的列表，以及專案的其他一般細節。一般會制定詳細的計劃，為所有不同階段制定相應的安全保障活動。

這一階段的一個關鍵部分是安全意識培訓。培訓課程旨在為專案參與者提供安全知識，使他們能夠採取措施進行安全設計和開發，並從一開始就為整個團隊建立安全觀念。

2. 設計

設計階段是決定所有細節的階段，比如程式語言、軟體架構、功能和使用者介面。這個階段的SSDLC實踐涉及確定應用程式的大部分安全功能和防禦機制。

此階段的一些以安全為重點的安全活動包括：

威脅建模：模擬攻擊場景，並將有效的對策整合到能夠危及應用程式的已識別威脅列表中，從而為後續採取的所有安全措施奠定基礎。對可能的威脅的早期檢測不僅降低了成功攻擊的可能性，而且還降低了與整個專案的安全整合相關的成本。

設計文件和審查：建模結果幫助團隊準備設計文件，確定安全性需求和需要解決的應用程式安全性的關鍵漏洞。

識別第三方風險:如果關聯的第三方元件是脆弱的，那麼即使是最安全的應用程式也容易受到攻擊，從而使整個系統變得脆弱。因此，檢查和監控第三方應用可能存在的安全漏洞，並在必要時進行補丁，保證整個應用系統的完整性是至關重要的。

3. 開發/構建

在SSDLC上下文中，該階段涉及安全編碼和掃描等活動。

安全編碼：在這個階段，將考慮應用程式編碼的安全最佳實踐，如身份驗證和加密。通常，團隊的目標是遵循安全的編碼實踐，這成功地消除了許多基本的漏洞，最大限度地減少了回溯相同步驟來修復和修補專案中稍後發現的漏洞的需求。

SAST： 靜態應用程式掃描工具 (SAST) 可以幫助應用程式完成之前測試及審查程式碼。靜態掃描有助於在開發的各個階段發現安全問題，使得專案的發展更容易檢測和修復問題。

手動程式碼審查：SAST提供自動掃描功能。在發現程式碼缺陷和漏洞上幫助開發人員節省很多時間和精力，但仍然需要人工審查來識別惡意攻擊者可能利用的程式碼中的潛在問題。

4. 測試

測試階段是安全測試全面展開的階段。在此階段執行的常見做法包括:

動態掃描：與 SAST不同，動態應用程式掃描工具 (DAST) 在執行時模擬駭客攻擊嘗試和威脅以暴露應用程式漏洞。結合前一階段的 SAST，DAST 新增了一個額外的測試層，以消除大多數安全錯誤。

模糊測試：在模糊測試中，開發人員生成模擬自定義模式的隨機輸入，並檢查應用程式是否能夠處理這些輸入。這有助於為SQL隱碼攻擊等問題構建保護，SQL隱碼攻擊本質上是一種惡意輸入。

滲透測試：透過邀請第三方安全專業團隊來模擬攻擊，是暴露任何系統中隱藏漏洞的最佳方法之一。開發團隊總是可能忽略第三方專家的經驗和知識可能透過滲透測試重現的某些攻擊場景。

5. 部署和維護

當應用程式上線時，開發人員的工作並沒有結束。應用程式有自己的生態系統，必須對其進行管理、維護和照顧。

此階段的一些SSDLC實踐包括：

環境響應：應用程式本身可能是萬無一失的，但每個應用程式只有在與更大的生態系統相關時才有用。一旦應用程式啟動，監控環境及其對應用程式的行為和完整性的影響是維護的一個關鍵方面。

事件響應計劃：在現實世界中，沒有任何應用程式能夠真正免受安全漏洞的影響。事故響應計劃規定了發生事故時團隊必須遵循的計劃、行動和程式。

安全檢查：威脅和攻擊總是在發展，為了保證安全，應用程式必須發展得更快。頻繁的安全檢查有助於保護應用程式免受新形式的攻擊和漏洞。

在傳統的SLDC模型中，敏捷開發已經在大多陣列織中取代了開發生命週期的傳統方法。然而，敏捷環境與面向安全的實踐和工具並不一致。這主要源於敏捷開發方法需要廣泛的安全性測試。由於在敏捷開發中每個階段都是迭代執行的，而且SSDLC的每個階段都嵌入了安全元件，敏捷團隊可能會發現大量的重複測試。

這也意味著，將SSDLC整合到敏捷環境中，企業需要經歷很大的轉變。在敏捷開發過程中，安全不再是事後的想法，而是需要貫穿到每天的工作習慣中。

每個企業的最終目的都很明確，透過在開發的不同階段和部分實現整合來擁抱更大的安全性。

參讀連結：

https://resources.infosecinstitute.com/topic/introduction-to-secure-software-development-life-cycle/

安全軟體開發生命週期簡介