一、代碼審查(Code review)

軟體代碼是安全漏洞的最常見來源之一，開發人員每年要撰寫數百萬行的代碼，在這些復雜的代碼中埋藏著成千上萬的安全問題，正等待著被發現，手工代碼審查是發現這些漏洞的最重要的軟體測驗技術之一，在代碼審查程序中，開發人員讓其他開發人員審查他們的作業，他們檢查代碼以確保它不包含明顯或微小的安全問題，這個程序可能是完全非正式的，完全正式的，或介于兩者之間，最正式的代碼審查程序被稱為Fagan檢查，Fagan檢查遵循一個六步流程：

1. 計劃(planning)： 開發人員執行所需的前期作業，使代碼審查開始，這包括準備審查所需的材料，確定參與者，并安排審查本身，
2. 概述(overview)： 審查的領導者將角色分配給不同的參與者，并向團隊提供正在審查的軟體的概述，
3. 準備(preparation)： 參與者自己審查代碼和任何支持材料，為審查會議做好準備，他們尋找任何潛在的問題，并做筆記，以便以后可以參考，
4. 會議(meeting)： 在會議上，開發人員提出他們在準備階段發現的任何問題，并與團隊討論，在這個會議上，團隊正式確定了軟體中需要修正的任何缺陷，
5. 返工(rework)： 檢查會議結束后，創建代碼的開發人員在返工階段糾正審查中發現的任何缺陷，如果沒有缺陷，開發人員就可以進入下一個階段，如果缺陷很嚴重，這個程序就會回傳到計劃階段，進行另一次審查，
6. 后續(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)測驗，

1. 在靜態代碼測驗中，開發人員使用專門的測驗軟體來檢查代碼中的常見缺陷，代碼實際上并沒有被執行，但它被檢查出常見的錯誤，這些錯誤被報告為需要糾正的缺陷，我們可以把靜態代碼測驗看作是代碼審查的自動等價物，
2. 在動態測驗中，測驗軟體實際執行代碼，向它提供輸入，并讀取輸出以驗證它是否正常運行，這是最接近真實世界操作的測驗，它是準備將代碼轉移到生產中的一個有價值的步驟，為開發者和管理者提供了軟體正常運行的信心，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