一、代碼審查(Code review)
軟體代碼是安全漏洞的最常見來源之一。開發人員每年要編寫數百萬行的代碼，在這些複雜的代碼中埋藏着成千上萬的安全問題，正等待着被發現。手工代碼審查是發現這些漏洞的最重要的軟體測試技術之一。在代碼審查過程中，開發人員讓其他開發人員審查他們的工作，他們檢查代碼以確定它不包含明顯或微小的安全問題。這個過程可能是完全非正式的，完全正式的，或介于兩者之間。最正式的代碼審查過程被稱為Fagan檢查。Fagan檢查遵循一個六步流程：
- 計劃(planning)： 開發人員執行所需的前期工作，使代碼審查開始。這包括準備審查所需的材料，确定參與者，并安排審查本身。
- 概述(overview)： 審查的上司者将角色配置設定給不同的參與者，并向團隊提供正在審查的軟體的概述。
- 準備(preparation)： 參與者自己審查代碼和任何支援材料，為審查會議做好準備。他們尋找任何潛在的問題，并做筆記，以便以後可以參考。
- 會議(meeting)： 在會議上，開發人員提出他們在準備階段發現的任何問題，并與團隊讨論。在這個會議上，團隊正式确定了軟體中需要修正的任何缺陷。
- 返工(rework)： 檢查會議結束後，建立代碼的開發人員在返工階段糾正審查中發現的任何缺陷。如果沒有缺陷，開發人員就可以進入下一個階段。如果缺陷很嚴重，這個過程就會傳回到計劃階段，進行另一次審查。
- 後續(Follow-up)： 一旦代碼不再需要返工，Fagan檢查就以後續階段結束。在這個階段，審查的上司者确認所有的缺陷都被成功地糾正了，并完成審查的檔案。
Fagan檢查模型是一個高度正規化的代碼審查過程，由于其繁瑣的性質，它不常被遵循。然而，大多數軟體開發組織确實在進行某種類型的手工代碼審查，而且很容易看到Fagan檢查過程的修改版本。無論組織以哪種方式進行代碼審查，它們對軟體開發的安全性都是至關重要的。
二、軟體測試
1.模型确認(Verification)和驗證(Validation)：
在整個軟體開發過程中，開發人員和産品經理必須經常進行測試，以確定最終産品能夠正常運作并滿足業務需求。在軟體測試過程中，有兩個主要的活動，即模型确認和驗證。
軟體模型确認(verification)：發生在整個開發過程中，它包括測試，以驗證軟體功能是否正常。目的是回答我們是否正在建構正确的産品這個問題，也就是檢查規格是否被系統正确執行。
軟體模型驗證(validation)：確定由開發工作産生的軟體滿足最初的業務需求。軟體模型驗證回答了這樣一個問題：我們建構的産品是否正确，也就是使用者的需求是否被滿足。
2.壓力測試(Stress Test)：
當開發人員準備将代碼釋出到生産中時，他們必須確定他們的代碼能夠在真實的生産負載下工作。這是通過一個被稱為壓力測試或負載測試的過程來完成的。在負載測試期間，開發人員使用自動化腳本，無論是内部還是通過第三方負載測試服務，來模拟系統上的真實活動。這些測試應驗證系統能夠處理它将經曆的最大預期負荷。他們還經常繼續增加負載，直到系統實際失效，以确定系統的最大容量。
3.使用者驗收測試(User Aacceptance Testing)：
使用者驗收測試，或稱UAT，通常是軟體測試的最後階段。一旦開發人員确信軟體是正确的并準備好投入生産，他們就會把它交給最終使用者，讓他們在真實世界的環境下進行評估。這通常是在一個測試環境中進行的，使用者被要求模拟真實世界的交易，而不實際改變生産資料。使用者驗收測試的目标是關注可用性，確定軟體對終端使用者是直覺的。許多組織在提到使用者驗收測試時，都會使用beta測試這個術語。
4.回歸測試(Regression Testing)：
在釋出代碼後，開發人員經常對代碼進行小的和大的修複，以修複釋出後發現的錯誤，并為系統添加新功能。在釋出這些修複之前，他們會進行回歸測試，以驗證這些對代碼的修改不會産生意想不到的副作用。回歸測試的過程使用了幾組輸入，并将它們提供給原始系統和修改後的代碼。然後，測試包驗證軟體在修改前後的行為是否相同，當然，作為軟體修改的一部分的變化除外。
三、代碼安全測試
代碼安全測試超越了對功能需求的測試，檢查代碼是否有安全缺陷(security flaws)。雖然代碼審查在軟體安全方面發揮着重要作用，但它們涉及到開發人員檢查代碼和檢查它的缺陷。代碼測試(tests)超越了代碼審查(reviews)，它們使用技術來協助代碼檢查過程。對于組織來說，在同一個軟體上同時使用代碼安全測試和代碼審查是很常見的，以獲得對軟體品質的不同觀點。
有兩種主要的代碼測試類型，靜态(Static)測試和動态(Dynamic)測試。
- 在靜态代碼測試中，開發人員使用專門的測試軟體來檢查代碼中的常見缺陷。代碼實際上并沒有被執行，但它被檢查出常見的錯誤，這些錯誤被報告為需要糾正的缺陷。我們可以把靜态代碼測試看作是代碼審查的自動等價物。
- 在動态測試中，測試軟體實際執行代碼，向它提供輸入，并讀取輸出以驗證它是否正常運作。這是最接近真實世界操作的測試，它是準備将代碼轉移到生産中的一個有價值的步驟，為開發者和管理者提供了軟體正常運作的信心。Synthetic transactions是動态代碼測試的一個重要部分，其實是一組腳本化的輸入和指令，測試人員知道代碼對每個輸入應該産生什麼輸出。測試軟體可以自動循環這些Synthetic transactions，進行回歸測試，以驗證代碼在各種測試中是否正常運作。
重要的是要認識到這不是一個測試比另一個更好的情況。靜态測試經常識别出動态測試所使用的合成事務中沒有包括的缺陷。動态測試經常會發現靜态測試無法預見的缺陷和功能。
四、模糊測試(Fuzz testing)
模糊測試是一種非常重要的軟體測試技術。模糊測試向軟體提供許多不同類型的有效和無效輸入，試圖使該軟體進入不可預測的狀态，或披露機密資訊。 模糊測試的工作原理是自動生成輸入值(可以來自不同輸入源)，并将其輸入到軟體包中。
運作測試的開發者可以提供一個長或短的輸入值清單，或者他們可以寫一個腳本來生成這些輸入值。模糊測試包(fuzz testing package)也可以随機生成輸入值，也可以使用稱為 "生成模糊(generation fuzzing)"的技術從規範中生成輸入值。或者模糊測試包可以分析真實的輸入，然後用一種被稱為突變模糊(mutation fuzzing)的方法修改這些真實的數值。
我們可以使用Zed Application Proxy或ZAP作為測試工具，可以從開放網絡應用安全項目（OWASP）免費獲得。
具體步驟可以參考：https://www.bilibili.com/video/BV1HD4y1d7KC?p=9
需要注意的是，模糊測試是一種潛在的危險工具，可以被看作是一種進攻性的黑客技術。我們應該隻在得到應用程式所有者的許可時才進行模糊測試。
五、代碼倉庫(Code repositories)
代碼倉庫在現代軟體開發中發揮着重要的作用，它既能為代碼提供安全存儲，又能進行版本控制(Version control)。代碼庫的主要目的是将軟體開發中使用的源檔案存儲在一個集中的位置，以便于安全存儲，并在多個開發人員之間協調更改。代碼庫還可以進行版本控制，允許跟蹤變化，并在需要時将代碼復原到早期版本。基本上，代碼庫執行軟體開發的内務工作，使許多人有可能以有組織的方式在一個大型軟體項目上分享工作。代碼庫也滿足了安全和審計專家的需求，他們希望確定軟體開發包括自動審計和記錄的變化。通過将代碼暴露給組織中的所有開發人員，代碼庫也促進了代碼的重複使用。開發人員在尋找執行特定功能的代碼時，可以在代碼庫中搜尋現有的代碼，然後重新使用這些代碼，而不是從頭開始。代碼庫也有助于避免死代碼的問題，即代碼在組織中被使用，但沒有人負責維護這些代碼。也許甚至沒有人知道那些原始的源檔案在哪裡。
Git是最流行的版本控制機制之一，可以與代碼倉庫結合使用，例如(Github,Gitlab等)。Git的操作可以參考如下的連結:
https://www.runoob.com/git/git-basic-operations.html
確定代碼倉庫的安全是軟體開發人員和網絡安全專家工作的一個重要部分。代碼庫是應用安全的一個重要部分，但它隻是代碼管理的一個方面。網絡安全團隊還應該與開發人員和營運團隊合作，確定通過組織準許的釋出管理流程，以安全的方式提供和取消應用程式。該流程應包括代碼完整性測量。代碼完整性測量使用加密的哈希函數來驗證正在釋出到生産中的代碼是否與先前準許的代碼一緻。哈希值的任何偏差都表明代碼被有意或無意地修改過，需要在釋出前做進一步調查。
六、應用軟體控制
1.應用管理政策
防範惡意軟體的最好方法之一是用一種叫做應用控制的技術防止使用者運作不需要的應用程式。應用控制将系統上運作的軟體限制在符合組織安全政策的程式上。有兩種主要的應用控制方法，白名單(whitelisting)和黑名單(blacklisting)。在白名單方法中，管理者建立一個使用者可以在其系統上運作的所有應用程式的清單。這在一個非常嚴格控制的環境中效果很好，但如果組織中有許多不同的應用程式和角色，它就很難管理。黑名單的方法為使用者提供了更大的靈活性。管理者不是列出允許使用者運作的應用程式，而是列出禁止的應用程式。這對使用者來說要容易得多，但它确實降低了應用控制的有效性。
Windows提供了AppLocker功能來實作應用控制。通過建立一個組政策對象來建立一個AppLocker應用程式控制政策，編寫黑白名單，放行或者組織通路某個檔案夾或者程式。
2.應用更新
我們可能能作業系統打安全更新檔以防止新的漏洞的重要性。給應用程式打更新檔也很重要，因為它們也可能有安全漏洞。不同的軟體供應商提供不同的更新檔機制。讓我們來看看其中的一個。
我們将看看Adobe用來更新其Acrobat Reader産品的過程。如果我們繼續前進并打開Acrobat Reader，在幫助菜單下，我們看到一個檢查更新的選項。當我們點選該選項時，Adobe Acrobat會聯系其更新伺服器，并尋找是否有任何更新可用。我們可以看到在這種情況下，我們使用的版本是最新的，不需要更新。現在，這種更新機制是手動的，需要使用者的幹預。這并不是我們想在我們的組織中應用安全控制的真正方式，是以，我們使用自動化流程來管理整個組織中使用的所有軟體的更新是非常重要的。
最後，應用控制技術，無論使用白名單還是黑名單，都能為網絡安全分析人員提供重要的資訊。是以，我們應該把應用控制日志連接配接到安全資訊和事件管理系統或你的其他中央日志存儲庫。一旦把這些日志放在一個安全的、集中的位置，我們就可以觀察它們是否有惡意活動的迹象。
七、第三方代碼(Third-party code)
軟體開發人員經常依賴别人建立的代碼來提高他們的效率。除了在組織内部重複使用代碼外，開發人員還經常利用第三方的代碼。第三方軟體庫(Libraries)是開發人員之間共享代碼的一種非常常見的方式。庫由執行相關功能的共享代碼對象組成。例如，一個軟體庫可能包含一系列與生物學研究、金融分析或社交媒體有關的功能。
為了讓開發者更容易獲得庫，相關組織經常釋出軟體開發工具包(Software Development kits)或SDK。SDK是我們的軟體庫集合，與文檔、示例和其他資源相結合，旨在幫助程式員在開發環境中快速啟動和運作。SDK還經常包括專門的實用程式，旨在幫助開發人員設計和測試代碼。例如，這裡是Facebook為iOS開發者提供的軟體開發工具包。它提供了不同的元件，使開發者能夠通過iOS應用程式處理分析、廣告、身份和通路管理、Facebook圖和Facebook平台的其他元素。
應用程式設計接口(Application Programming Interfaces)，或API，是組織向開發者提供服務的另一種方式。API不是提供開發者自己運作的代碼，而是通過網際網路向開發者提供在其他地方運作的服務。例如，Twitter提供了一個API，允許開發者與Twitter服務互動，閱讀、釋出和執行其他Twitter動作。當組織将代碼開發外包給其他組織時，也可能将第三方代碼引入他們的環境。
安全團隊應確定外包代碼接受與内部開發的代碼相同水準的測試。安全專家應該熟悉第三方代碼在其組織中的各種使用方式，以及其組織向他人提供服務的方式。在共享代碼中出現安全缺陷是相當常見的，是以了解這些依賴關系并對安全更新保持警惕是極其重要的。
參考資料來源：
https://www.linkedin.com/learning/paths/become-a-comptia-security-plus-certified-security-professional-sy0-601