OWASP Web 安全測試指南 WSTG

Eoin Keary的前言

軟件不安全的問題可能是我們這個時代最重要的技術挑戰。支持業務、社交網絡等的 Web 應用程序的急劇興起只會加劇建立一種強大的方法來編寫和保護我們的 Internet、Web 應用程序和數據的要求。

在開放 Web 應用程序安全項目? （OWASP?）中，我們試圖讓世界成為一個不安全軟件是異常而不是常態的地方。OWASP測試指南在解決這一嚴重問題方面發揮著重要作用。至關重要的是，我們測試軟件安全問題的方法必須基于工程和科學原理。我們需要一種一致、可重復和定義的方法來測試 Web 應用程序。一個在工程和技術方面沒有最低標準的世界是一個混亂的世界。

不言而喻，如果不對應用程序執行安全測試，就無法構建安全應用程序。測試是構建安全系統的更廣泛方法的一部分。許多軟件開發組織沒有將安全測試作為其標準軟件開發過程的一部分。更糟糕的是，許多安全供應商提供的測試具有不同程度的質量和嚴格性。

安全測試本身并不是衡量應用程序安全性的一個特別好的獨立指標，因為攻擊者可以通過無數種方式使應用程序崩潰，而且根本不可能測試所有方法。我們無法安全地入侵自己，因為我們只有有限的時間來測試和防御攻擊者沒有這種限制。

結合其他 OWASP 項目，如代碼審查指南、開發指南和工具，如?OWASP ZAP，這是構建和維護安全應用程序的良好開端。本測試指南將向您展示如何驗證正在運行的應用程序的安全性。我強烈建議將這些指南用作應用程序安全計劃的一部分。

2.1為什么選擇OWASP？

創建這樣的指南是一項艱巨的任務，需要全球數百人的專業知識。有許多不同的方法可以測試安全漏洞，本指南收集了領先專家關于如何快速、準確和高效地執行此測試的共識。OWASP使志同道合的安全人員能夠一起工作，并形成解決安全問題的領先實踐方法。

以完全免費和開放的方式提供本指南對于基金會的使命非常重要。它使任何人都能夠理解用于測試常見安全問題的技術。安全不應該是只有少數人才能實踐的黑魔法或封閉的秘密。它應該向所有人開放，不僅對安全從業人員開放，還對 QA、開發人員和技術經理開放。構建本指南的項目將這些專業知識掌握在需要它的人手中 - 你、我和任何參與構建軟件的人。

本指南必須交到開發人員和軟件測試人員手中。世界上沒有足夠的應用程序安全專家來對整個問題產生任何重大影響。應用程序安全的初始責任必須落在開發人員的肩上，因為他們編寫代碼。如果開發人員沒有對其進行測試或考慮引入漏洞的錯誤類型，那么他們就不會生成安全代碼，這并不奇怪。

使這些信息保持最新是本指南項目的關鍵方面。通過采用 wiki 方法，OWASP 社區可以發展和擴展本指南中的信息，以跟上快速變化的應用程序安全威脅形勢。

本指南很好地證明了我們的成員和項目志愿者對這一主題的熱情和精力。它肯定有助于一次改變世界一行代碼。

定制和優先排序

您應該在組織中采用本指南。您可能需要定制信息以匹配組織的技術、流程和組織結構。

通常，組織中有幾種不同的角色可以使用本指南：

開發人員應使用本指南來確保他們正在生成安全代碼。這些測試應該是正常代碼和單元測試過程的一部分。
軟件測試人員和 QA 應使用本指南來擴展他們應用于應用程序的測試用例集。及早發現這些漏洞可以節省大量時間和精力。
安全專家應將本指南與其他技術結合使用，以驗證應用程序中是否遺漏了任何安全漏洞。
項目經理應該考慮本指南存在的原因，以及安全問題通過代碼和設計中的錯誤表現出來。

執行安全測試時要記住的最重要的事情是不斷重新確定優先級。應用程序失敗的可能方式有無數種，而且組織的測試時間和資源總是有限的。確保明智地使用時間和資源。盡量關注對您的業務構成真正風險的安全漏洞。嘗試根據應用程序及其用例將風險置于上下文中。

本指南最好被視為一組可用于查找不同類型的安全漏洞的技術。但并非所有技術都同樣重要。盡量避免將指南用作清單，新的漏洞總是會顯現出來，沒有指南可以詳盡地列出“要測試的事情”，而是一個很好的起點。

自動化工具的作用

有許多公司銷售自動化安全分析和測試工具。記住這些工具的局限性，以便您可以將它們用于它們擅長的事情。正如 Michael Howard 在 2006 年西雅圖舉行的 OWASP AppSec 大會上所說，“工具并不能使軟件安全！他們幫助擴展流程并幫助執行政策。

最重要的是，這些工具是通用的，這意味著它們不是為自定義代碼設計的，而是為一般應用程序設計的。這意味著，雖然他們可以找到一些通用問題，但他們對您的應用程序沒有足夠的了解，無法檢測到大多數缺陷。根據我的經驗，最嚴重的安全問題不是通用的，而是在業務邏輯和自定義應用程序設計中緊密交織在一起的。

這些工具也非常有用，因為它們確實發現了許多潛在問題。雖然運行這些工具不會花費太多時間，但每個潛在問題都需要時間來調查和驗證。如果目標是盡快發現并消除最嚴重的缺陷，請考慮您的時間最好花在自動化工具上還是使用本指南中描述的技術上。盡管如此，這些工具肯定是平衡的應用程序安全計劃的一部分。如果使用得當，它們可以支持您的整個流程，以生成更安全的代碼。

號召性用語

如果您正在構建、設計或測試軟件，我強烈建議您熟悉本文檔中的安全測試指南。這是一個很好的路線圖，用于測試應用程序目前面臨的最常見問題，但并不詳盡。如果您發現錯誤，請在討論頁面添加注釋或自行進行更改。您將幫助成千上萬使用本指南的人。

web 安全測試指南（WSTG）項目為 Web 應用程序開發人員和安全專業人員提供了首屈一指的網絡安全測試資源。

WSTG 是測試 Web 應用程序和 Web 服務安全性的綜合指南。WSTG 由網絡安全專業人員和敬業的志愿者共同努力創建，為世界各地的滲透測試人員和組織提供了一個最佳實踐框架。

WSTG - Stable | OWASP Foundation

該指南用來指導進行安全測試、滲透測試，如何快速、準確和高效地執行安全測試。《測試指南》詳細描述了通用測試框架和在實踐中實現該框架所需的技術。

本指南的其余部分組織如下：本簡介涵蓋了測試 Web 應用程序的先決條件和測試范圍。它還涵蓋了成功測試和測試技術的原則、報告的最佳實踐以及安全測試的業務案例。第 3 章介紹了 OWASP 測試框架，并解釋了它與軟件開發生命周期各個階段相關的技術和任務。第 4 章介紹了如何通過代碼檢查和滲透測試來測試特定漏洞（例如，SQL 注入）。

什么是測試？

在 Web 應用程序的開發生命周期中，許多事情都需要測試，但測試實際上意味著什么？《牛津英語詞典》將“測試”定義為：

測試（名詞）：旨在確定某物的質量、性能或可靠性的程序，尤其是在它被廣泛使用之前。

就本文檔而言，測試是將系統或應用程序的狀態與一組標準進行比較的過程。在安全行業，人們經常根據一套既不明確也不完整的心理標準進行測試。因此，許多局外人將安全測試視為一門黑色藝術。本文檔的目的是改變這種看法，并使沒有深入安全知識的人更容易在測試中有所作為

何時測試？

如今，大多數人在軟件已經創建并處于其生命周期的部署階段（即，代碼已創建并實例化為一個有效的 Web 應用程序）之前不會對其進行測試。這通常是一種非常無效且成本高昂的做法。防止生產應用程序中出現安全漏洞的最佳方法之一是通過在每個階段中包含安全性來改進軟件開發生命周期（SDLC）。SDLC 是強加于軟件工件開發的一種結構。如果您的環境中當前未使用 SDLC，那么是時候選擇一個了！下圖顯示了一個通用的 SDLC 模型，以及（估計的）在此類模型中修復安全漏洞的成本增加。

define design develop deploy maintain 修改安全漏洞的成本隨著這個流程階段逐漸增加。

圖 2-1：通用 SDLC 模型

公司應檢查其整體 SDLC，以確保安全性是開發過程中不可或缺的一部分。SDLC 應包括安全測試，以確保在整個開發過程中充分覆蓋安全性和有效控制。

2.2 測試原則

沒有靈丹妙藥??There is No Silver Bullet

雖然人們很容易認為安全掃描程序或應用程序防火墻將提供許多防御攻擊或識別大量問題，但實際上，不安全軟件的問題沒有靈丹妙藥。應用程序安全評估軟件雖然可以作為發現唾手可得的果實的第一道關口，但在深入評估或提供足夠的測試覆蓋率方面通常不成熟且無效。請記住，安全是一個過程，而不是一個產品。

SDLC為王?

將安全性集成到 SDLC 的每個階段??目前有幾個安全的 SDLC 框架提供描述性和規范性建議。是選擇描述性建議還是規范性建議取決于 SDLC 流程的成熟度。從本質上講，規范性建議顯示了安全 SDLC 應該如何工作，而描述性建議顯示了它在現實世界中的使用方式。兩者都有自己的位置。例如，如果您不知道從哪里開始，規范性框架可以提供可在 SDLC 中應用的潛在安全控制菜單。然后，描述性建議可以通過展示對其他組織有效的方法來幫助推動決策過程。描述性安全 SDLC 包括 BSIMM;規范性安全 SDLC 包括 OWASP?的開放軟件保障成熟度模型?（OpenSAMM）和?ISO/IEC 27034?第 1-7 部分，均已發布（第 4 部分除外）

盡早測試并經常測試??

當在 SDLC 中及早檢測到錯誤時，可以更快地以更低的成本解決該錯誤。在這方面，安全錯誤與功能或基于性能的錯誤沒有什么不同。實現這一目標的一個關鍵步驟是教育開發和 QA 團隊了解常見的安全問題以及檢測和預防這些問題的方法。盡管新的庫、工具或語言可以幫助設計具有更少安全漏洞的程序，但新的威脅不斷出現，開發人員必須意識到影響他們正在開發的軟件的威脅。安全測試方面的教育還有助于開發人員獲得適當的思維方式，從攻擊者的角度測試應用程序。這允許每個組織將安全問題視為其現有職責的一部分。

測試自動化

在現代開發方法中，例如（但不限于）：敏捷、DevOps/Devsecops 或快速應用程序開發（RAD），在將安全測試集成到持續集成/持續部署（CI/CD）工作流中時，應考慮將安全測試集成到持續集成/持續部署（CI/CD）工作流中，以維護基線安全信息/分析并識別“唾手可得”類型的弱點。這可以通過在標準自動發布工作流期間或定期計劃利用動態應用程序安全測試（DAST）、靜態應用程序安全測試（SAST）和軟件組件分析（SCA）或依賴項跟蹤工具來實現。

了解安全范圍

重要的是要知道給定項目需要多少安全性。應對要保護的資產進行分類，說明如何處理這些資產（例如，機密、秘密、絕密）。應與法律委員會進行討論，以確保滿足任何特定的安全要求。在美國，要求可能來自聯邦法規，例如《格雷姆-里奇-比利雷法案》，或來自州法律，例如加利福尼亞州 SB-1386。對于位于歐盟國家/地區的組織，特定國家/地區的法規和歐盟指令都可能適用。例如，指令 96/46/EC4?和法規（EU） 2016/679（通用數據保護條例）規定，無論何種應用，都必須以應有的謹慎態度處理應用程序中的個人數據。

培養正確的心態

成功測試應用程序的安全漏洞需要“跳出框框”進行思考。正常用例將測試用戶以預期方式使用應用程序時的正常行為。良好的安全測試需要超越預期，并像試圖破壞應用程序的攻擊者一樣思考。創造性思維可以幫助確定哪些意外數據可能導致應用程序以不安全的方式失敗。它還可以幫助發現 Web 開發人員做出的任何并不總是正確的假設，以及這些假設如何被顛覆。自動化工具在漏洞測試方面做得很差的一個原因是自動化工具沒有創造性地思考。創造性思維必須根據具體情況進行，因為大多數 Web 應用程序都是以獨特的方式開發的（即使使用通用框架）。

Understand the Subject?

在任何良好的安全計劃中，首要的主要舉措之一應該是要求對應用程序進行準確的文檔記錄。架構、數據流圖、用例等應記錄在正式文檔中，并可供審查。技術規范和應用文檔應包括的信息，不僅列出所需的用例，還列出任何明確不允許的用例。最后，最好至少有一個基本的安全基礎設施，允許監控和趨勢分析針對組織應用程序和網絡（例如入侵檢測系統）的攻擊。

使用正確的工具

雖然我們已經說過沒有銀彈工具，但工具確實在整個安全計劃中起著關鍵作用。有一系列開源和商業工具可以自動執行許多日常安全任務。這些工具可以通過協助安全人員完成任務來簡化和加快安全流程。但是，重要的是要準確了解這些工具可以做什么和不能做什么，以免它們被過度銷售或不正確使用。

The Devil is in the Details??

至關重要的是，不要對應用程序進行膚淺的安全審查并認為它是完整的。這將灌輸一種虛假的信心，這種信心可能與一開始就沒有進行安全審查一樣危險。仔細審查調查結果并清除報告中可能殘留的任何誤報至關重要。報告不正確的安全發現通常會破壞安全報告其余部分的有效信息。應注意驗證應用程序邏輯的每個可能部分是否都經過測試，并且每個用例場景都已探索可能的漏洞。（這條很重要，甚至有的測評機構都是隨便拉人膚淺的測一下就出測試報告，未對報告進行審查，誤報）

Use Source Code When Available

雖然黑盒滲透測試結果令人印象深刻，并且可用于演示漏洞在生產環境中的暴露方式，但它們并不是保護應用程序的最有效或高效的方法。動態測試很難測試整個代碼庫，尤其是在存在許多嵌套條件語句的情況下。如果應用程序的源代碼可用，則應將其提供給安全人員，以便在執行審查時為他們提供幫助。可以發現應用程序源中的漏洞，這些漏洞在黑盒參與期間會被遺漏。

開發指標

一個好的安全計劃的一個重要部分是能夠確定情況是否正在好轉。跟蹤測試活動的結果，并制定指標以揭示組織內的應用程序安全趨勢非常重要。

好的指標將顯示：如果需要更多的教育和培訓;如果存在開發團隊不清楚的特定安全機制;如果發現的安全相關問題的總數正在減少。

可以從可用源代碼中以自動方式生成的一致指標也將有助于組織評估為減少軟件開發中的安全錯誤而引入的機制的有效性。指標不容易制定，因此使用IEEE提供的標準是一個很好的起點。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

記錄測試結果

為了結束測試過程，重要的是要制作一份正式的記錄，說明采取了哪些測試措施，由誰執行，何時執行，以及測試結果的詳細信息。明智的做法是就報告的可接受格式達成一致，該格式對所有相關方都有用，其中可能包括開發人員、項目管理、業務所有者、IT 部門、審計和合規性。

報告應向企業主明確指出存在重大風險的地方，并以足以獲得他們支持后續緩解措施的方式進行。報告還應明確開發人員，以開發人員能夠理解的語言查明受漏洞影響的確切功能以及解決問題的相關建議。該報告還應允許其他安全測試人員重現結果。編寫報告不應給安全測試人員本身帶來過重的負擔。安全測試人員通常并不以其創造性的寫作技巧而聞名，就復雜的報告達成一致可能會導致測試結果未正確記錄的情況。使用安全測試報告模板可以節省時間，并確保準確、一致地記錄結果，并且采用適合受眾的格式。

2.3 測試技術解釋

2.4人工審查?

Manual inspections are human reviews that typically test the security implications of people, policies, and processes. Manual inspections can also include inspection of technology decisions such as architectural designs. They are usually conducted by analyzing documentation or performing interviews with the designers or system owners.

人工檢查是人工審核，通常測試人員、策略和流程的安全影響。人工檢查還可以包括對技術決策（如設計）的檢查。它們通常通過分析文檔或與設計人員或系統所有者進行訪談來進行。

?其他活動，包括手動審查文檔、安全編碼策略、安全要求和架構設計，都應使用手動檢查來完成。

2.5威脅建模 Threat Modeling

威脅建模已成為一種流行的技術，可幫助系統設計人員考慮其系統和應用程序可能面臨的安全威脅。因此，威脅建模可以看作是應用程序的風險評估。它使設計人員能夠針對潛在漏洞制定緩解策略，并幫助他們將不可避免的有限資源和注意力集中在系統中最需要它的部分。建議所有應用程序都開發并記錄威脅模型。應盡早在 SDLC 中創建威脅模型，并應隨著應用程序的發展和開發的進展而重新審視。

若要開發威脅模型，我們建議采用遵循?NIST 800-30?風險評估標準的簡單方法。這種方法包括：

分解應用程序 – 使用手動檢查過程來了解應用程序的工作方式、其資產、功能和連接性。
對資產進行定義和分類 – 將資產分為有形資產和無形資產，并根據業務重要性對其進行排名。
探索潛在的漏洞 - 無論是技術、運營還是管理漏洞。
探索潛在威脅 – 通過使用威脅場景或攻擊樹，從攻擊者的角度對潛在攻擊媒介進行現實的了解。
制定緩解策略 – 針對每個被認為現實的威脅制定緩解控制措施。

威脅模型本身的輸出可能會有所不同，但通常是列表和圖表的集合。各種開源項目和商業產品都支持應用程序威脅建模方法，這些方法可用作測試應用程序設計中潛在安全漏洞的參考。開發威脅模型和對應用程序執行信息風險評估的方法沒有對錯之分。

優勢

系統的實際攻擊者視圖
靈活
在 SDLC 的早期

劣勢

好的威脅模型并不意味著好的軟件

2.6 源代碼審查?Source Code Review

源代碼審查是手動檢查 Web 應用程序源代碼是否存在安全問題的過程。

優勢

完整性和有效性
準確性
快速（適用于稱職的審稿人）

弊

需要具有高技能安全意識的開發人員
可能會錯過已編譯庫中的問題
無法輕松檢測運行時錯誤
實際部署的源代碼可能與正在分析的源代碼不同

有關代碼審查的詳細信息，請參閱?OWASP 代碼審查項目

2.7 滲透測試?Penetration Testing

幾十年來，滲透測試一直是用于測試網絡安全的常用技術。它通常也被稱為黑盒測試或道德黑客。滲透測試本質上是遠程測試系統或應用程序以查找安全漏洞的“藝術”，而無需了解目標本身的內部工作原理。通常，滲透測試團隊能夠像用戶一樣訪問應用程序。測試人員的行為類似于攻擊者，并試圖查找和利用漏洞。在許多情況下，測試人員將在系統上獲得一個或多個有效帳戶。

雖然滲透測試已被證明在網絡安全方面是有效的，但該技術并不能自然地轉化為應用程序。在網絡和操作系統上執行滲透測試時，所涉及的大部分工作是查找然后利用特定技術中的已知漏洞。由于 Web 應用程序幾乎完全是定制的，因此 Web 應用程序領域的滲透測試更類似于純粹的研究。已經開發了一些自動化滲透測試工具，但考慮到 Web 應用程序的定制性質，僅憑它們的有效性可能很差。

許多人使用 Web 應用程序滲透測試作為他們的主要安全測試技術。雖然它在測試程序中肯定有一席之地，但我們認為不應將其視為主要或唯一的測試技術。正如 Gary McGraw 在《軟件滲透測試》一書中所寫的那樣，“在實踐中，滲透測試只能識別系統中所有可能的安全風險的一小部分代表性樣本。但是，有針對性的滲透測試（即嘗試利用先前審查中檢測到的已知漏洞的測試）可用于檢測某些特定漏洞是否在部署的源代碼中實際得到修復。

優勢

可以快速（因此便宜）
與源代碼審查相比，需要相對較低的技能
測試實際公開的代碼

弊

在 SDLC 中為時已晚
僅正面碰撞試驗

2.8 需要采取兼顧各方利益的測試辦法

由于有如此多的技術和方法來測試 Web 應用程序的安全性，因此很難理解使用哪些技術或何時使用它們。經驗表明，對于究竟應該使用哪種技術來構建測試框架的問題，沒有正確或錯誤的答案。事實上，所有技術都應該用于測試所有需要測試的區域。

盡管很明顯，沒有一種技術可以有效地涵蓋所有安全測試并確保所有問題都得到解決，但許多公司只采用一種方法。過去使用的單一方法是滲透測試。滲透測試雖然有用，但不能有效地解決許多需要測試的問題。在SDLC中，它只是“太少太晚”。

正確的方法是平衡的方法，包括多種技術，從手動審查到技術測試，再到 CI/CD 集成測試。平衡的方法應涵蓋 SDLC 所有階段的測試。此方法利用了最合適的可用技術，具體取決于當前的 SDLC 階段。

當然，有時和情況下只有一種技術是可能的。例如，考慮對已創建的 Web 應用程序進行測試，但測試方無權訪問源代碼。在這種情況下，滲透測試顯然比完全沒有測試要好。但是，應鼓勵測試方挑戰假設，例如無法訪問源代碼，并探索進行更完整測試的可能性。

平衡的方法取決于許多因素，例如測試過程的成熟度和企業文化。建議平衡測試框架應類似于圖 3 和圖 4 中所示的表示形式。下圖顯示了疊加到 SLDC 上的典型比例表示。根據研究和經驗，公司必須更加重視開發的早期階段。

Proportion of Test Effort in SDLC

圖 2-3：SDLC 中測試工作的比例

Proportion of Test Effort According to Test Technique

圖 2-4：根據測試技術的測試工作量比例

在定義和設計階段，使用50%的安全測試，方法為過程審查和人工審查

開發階段，采用code review方法

部署和生產階段，采用security testing 安全測試方法（這里應該是指的滲透測試）

關于web掃描工具

自動的黑盒測試可能是無效的，但是也不應阻止使用 Web 應用程序掃描程序。相反，目的是確保理解這些限制并適當地規劃測試框架。

了解自動漏洞檢測工具的有效性和局限性很有幫助。為此，OWASP Benchmark Project?是一個測試套件，旨在評估自動化軟件漏洞檢測工具和服務的速度、覆蓋范圍和準確性。基準測試可以幫助測試這些自動化工具的功能，并有助于明確其有用性。?

有的安全漏洞，可能通過手動檢查（例如審查或代碼檢查）快速發現，而自動化黑盒測試則無法發現。可以用工具，但工具不是銀彈

關于靜態源代碼審查工具的說明

許多組織已經開始使用靜態源代碼掃描程序。雖然它們無疑在綜合測試計劃中占有一席之地，但有必要強調一些基本問題，即為什么這種方法在單獨使用時無效。僅靠靜態源代碼分析無法識別由于設計缺陷而導致的問題，因為它無法理解構建代碼的上下文。源代碼分析工具在確定由于編碼錯誤引起的安全問題方面很有用，但是需要大量的手動工作來驗證結果。

2.9派生安全測試要求

要有一個成功的測試程序，必須知道測試目標是什么。這些目標由安全要求指定。本節詳細討論如何通過從適用的標準和法規、正面應用程序要求（指定應用程序應該做什么）和負面應用程序要求（指定應用程序不應執行的操作）派生安全測試要求來記錄這些要求。它還討論了安全要求如何在 SDLC 期間有效地推動安全測試，以及如何使用安全測試數據來有效管理軟件安全風險。

測試目標

安全測試的目標之一是驗證安全控制是否按預期運行。這是通過描述安全控制的功能來記錄的。在高層次上，這意味著證明數據和服務的機密性、完整性和可用性。另一個目標是驗證實施的安全控制是否具有很少或沒有漏洞。這些是常見的漏洞，例如?OWASP Top Ten，以及之前在 SDLC 期間通過安全評估確定的漏洞，例如威脅建模、源代碼分析和滲透測試。security requirements

安全需求文檔

記錄安全要求的第一步是了解業務需求文檔 .業務需求文檔可以提供有關應用程序預期功能的初始高級信息。例如，應用程序的主要目的可能是向客戶提供金融服務或允許從在線目錄中購買商品。業務需求的安全部分應強調保護客戶數據以及遵守適用的安全文檔（如法規、標準和策略）的必要性。

適用法規、標準和策略的一般清單是 Web 應用程序的良好初步安全合規性分析。例如，可以通過檢查有關業務部門以及應用程序將運行的國家或州的信息來識別合規性法規。其中一些合規性準則和法規可能會轉化為安全控制的特定技術要求。例如，就金融應用程序而言，遵守聯邦金融機構檢查委員會（FFIEC）?網絡安全評估工具和文檔要求金融機構實施應用程序，通過多層安全控制和多因素身份驗證來降低弱身份驗證風險。

通用安全要求清單還必須涵蓋適用的安全行業標準。例如，對于處理客戶信用卡數據的應用程序，遵守?PCI 安全標準委員會數據安全標準?（DSS）禁止存儲 PIN 和 CVV2 數據，并要求商家通過加密保護存儲和傳輸中的磁條數據，并通過屏蔽來保護顯示中的磁條數據。這種PCI DSS安全要求可以通過源代碼分析來驗證。

清單的另一部分需要強制執行遵守組織信息安全標準和策略的一般要求。從功能需求的角度來看，安全控制要求需要映射到信息安全標準的特定部分。此類要求的一個示例可以是：“應用程序使用的身份驗證控件必須強制執行 10 個字母數字字符的密碼復雜性。當安全要求映射到合規性規則時，安全測試可以驗證合規性風險的暴露。如果發現違反信息安全標準和政策，這些將導致可以記錄的風險，并且企業必須管理或解決。由于這些安全合規性要求是可強制執行的，因此需要通過安全測試對其進行充分的記錄和驗證。

（意思是安全需求可以來自需求文檔、法律法規、行業法規、組織的一般規定）

安全要求驗證

信息安全評估的主要目標是識別安全控制中的差距，例如缺乏基本的身份驗證、授權或加密控制。進一步來說，安全評估的目標是風險分析，例如識別安全控制中的潛在弱點，以確保數據的機密性、完整性和可用性。例如，當應用程序處理個人身份信息（PII）和敏感數據時，要驗證的安全要求是是否符合公司信息安全策略，該策略要求對傳輸和存儲中的此類數據進行加密。假設使用加密來保護數據，則加密算法和密鑰長度需要符合組織的加密標準。這些可能要求僅使用某些算法和密鑰長度。例如，可以進行安全測試的安全要求是驗證是否僅使用允許的密碼（例如，SHA-256、RSA、AES）和允許的最小密鑰長度（例如，對稱加密超過 128 位，非對稱加密超過 1024 位）。

從安全評估的角度來看，可以通過使用不同的工件和測試方法在 SDLC 的不同階段驗證安全要求。例如，威脅建模側重于在設計過程中識別安全漏洞;安全代碼分析和審查側重于在開發過程中識別源代碼中的安全問題;滲透測試側重于在測試或驗證期間識別應用程序中的漏洞。

在 SDLC 早期發現的安全問題可以記錄在測試計劃中，以便以后可以通過安全測試進行驗證。通過結合不同測試技術的結果，可以得出更好的安全測試用例，并提高安全要求的保證水平。例如，當滲透測試和源代碼分析的結果結合起來時，可以將真正的漏洞與不可利用的漏洞區分開來。例如，考慮到 SQL 注入漏洞的安全測試，黑盒測試可能首先涉及對應用程序進行掃描以識別漏洞。可以驗證的潛在 SQL 注入漏洞的第一個證據是 SQL 異常的生成。對 SQL 漏洞的進一步驗證可能涉及手動注入攻擊媒介，以修改 SQL 查詢的語法，以利用信息泄露漏洞。在執行惡意查詢之前，這可能涉及大量的試錯分析。假設測試人員擁有源代碼，他們可能會直接從源代碼分析中學習如何構建能夠成功利用漏洞的 SQL 攻擊媒介（例如，執行惡意查詢，將機密數據返回給未經授權的用戶）。這可以加快對 SQL 漏洞的驗證。

威脅和對策分類法

對于 Web 應用程序，將安全控制暴露于常見漏洞（如 OWASP Top Ten）可以成為推導一般安全要求的良好起點。OWASP 測試指南清單是指導測試人員完成特定漏洞和驗證測試的有用資源。

wstg/checklists/checklist.md at master · OWASP/wstg · GitHub

威脅和對策分類的重點是根據威脅和漏洞的根本原因定義安全要求。可以使用 STRIDE 對威脅進行分類，STRIDE?是欺騙、篡改、否認、信息泄露、拒絕服務和特權提升的首字母縮寫詞。根本原因可以歸類為設計中的安全漏洞、編碼中的安全錯誤或由于不安全的配置導致的問題。例如，弱身份驗證漏洞的根本原因可能是當數據跨越應用程序的客戶端和服務器層之間的信任邊界時缺少相互身份驗證。在架構設計審查期間捕獲不可否認性威脅的安全要求允許記錄對策（例如，相互身份驗證）的要求，這些要求可以在以后通過安全測試進行驗證。

漏洞的威脅和對策分類還可用于記錄安全編碼的安全要求，例如安全編碼標準。身份驗證控件中常見編碼錯誤的一個示例包括應用哈希函數來加密密碼，而不對值應用種子。從安全編碼的角度來看，這是一個漏洞，它會影響用于身份驗證的加密，其根本原因在于編碼錯誤。由于根本原因是不安全的編碼，因此可以在安全編碼標準中記錄安全要求，并在 SDLC 的開發階段通過安全代碼審查進行驗證。

（意思是要對威脅進行分類，可以參考OWASP top10，）

安全測試與風險分析

安全需求需要考慮漏洞的嚴重性，以支持風險緩解策略 .假設組織維護在應用程序中發現的漏洞存儲庫（即漏洞知識庫），則可以按類型、問題、緩解措施、根本原因報告安全問題，并將其映射到發現這些問題的應用程序。這樣的漏洞知識庫還可用于建立指標，以分析整個 SDLC 中安全測試的有效性。

例如，考慮輸入驗證問題，例如 SQL 注入，該問題通過源代碼分析進行識別，并報告編碼錯誤根本原因和輸入驗證漏洞類型。可以通過滲透測試來評估此類漏洞的暴露程度，方法是探測具有多個 SQL 注入攻擊媒介的輸入字段。此測試可能會驗證在訪問數據庫之前是否篩選了特殊字符，并緩解了漏洞。通過結合源代碼分析和滲透測試的結果，可以確定漏洞的可能性和暴露程度，并計算漏洞的風險等級。通過在調查結果（例如測試報告）中報告漏洞風險評級，可以決定緩解策略。例如，可以優先修復高風險和中風險漏洞，而低風險漏洞可以在將來的版本中修復。

通過考慮利用常見漏洞的威脅場景，可以識別應用程序安全控制需要進行安全測試的潛在風險。例如，OWASP 十大漏洞可以映射到網絡釣魚、侵犯隱私、身份盜竊、系統泄露、數據更改或數據破壞、經濟損失和聲譽損失等攻擊。此類問題應作為威脅方案的一部分進行記錄。通過考慮威脅和漏洞，可以設計一系列測試來模擬此類攻擊場景。理想情況下，組織的漏洞知識庫可用于派生安全風險驅動的測試用例，以驗證最可能的攻擊場景。例如，如果標識盜竊被視為高風險，則負面測試方案應驗證因利用身份驗證、加密控制、輸入驗證和授權控制中的漏洞而產生的影響的緩解措施。

推導功能和非功能測試要求

功能安全要求

從功能安全要求的角度來看，適用的標準、策略和法規既需要一種安全控制，也需要控制功能。這些要求也稱為“積極要求”，因為它們說明了可以通過安全測試驗證的預期功能。正面要求的示例包括：“應用程序將在六次登錄嘗試失敗后鎖定用戶”或“密碼至少需要包含 10 個字母數字字符”。對積極需求的驗證包括斷言預期的功能，可以通過重新創建測試條件并根據預定義的輸入運行測試來測試。然后，結果顯示為失敗或通過條件。

為了通過安全測試驗證安全要求，安全要求需要由功能驅動。他們需要突出預期的功能（什么）并暗示實現（如何實現）。身份驗證的高級安全設計要求示例可以是：

在傳輸和存儲中保護用戶憑據或共享機密。
屏蔽顯示中的任何機密數據（例如密碼、帳戶）。
在一定次數的登錄嘗試失敗后鎖定用戶帳戶。
不要由于登錄失敗而向用戶顯示特定的驗證錯誤。
僅允許字母數字密碼、包含特殊字符且長度至少為 10 個字符的密碼，以限制攻擊面。
通過驗證舊密碼、新密碼和用戶對質詢問題的回答，僅允許經過身份驗證的用戶使用密碼更改功能，以防止通過密碼更改暴力破解密碼。
密碼重置表單應驗證用戶的用戶名和用戶注冊的電子郵件，然后再通過電子郵件向用戶發送臨時密碼。頒發的臨時密碼應為一次性密碼。密碼重置網頁的鏈接將發送給用戶。密碼重置網頁應驗證用戶的臨時密碼、新密碼以及用戶對質詢問題的回答。

風險驅動的安全要求

安全測試也必須以風險為導向。他們需要驗證應用程序是否存在意外行為或負面要求。

負面要求的示例包括：

應用程序不應允許更改或銷毀數據。
惡意用戶不應破壞或濫用該應用程序進行未經授權的金融交易。

負面需求更難測試，因為沒有預期的行為要查找。尋找符合上述要求的預期行為可能需要威脅分析師不切實際地提出不可預見的輸入條件、原因和影響。因此，安全測試需要由風險分析和威脅建模驅動。關鍵是記錄威脅場景，以及作為緩解威脅的因素的對策的功能。

例如，在身份驗證控制的情況下，可以從威脅和對策的角度記錄以下安全要求：

對存儲和傳輸中的身份驗證數據進行加密，以降低信息泄露和身份驗證協議攻擊的風險。
使用不可逆加密（例如使用摘要（例如 HASH）和種子）來加密密碼，以防止字典攻擊。
在達到登錄失敗閾值后鎖定帳戶，并強制實施密碼復雜性，以降低暴力破解密碼攻擊的風險。
在驗證憑據時顯示一般錯誤消息，以降低帳戶收集或枚舉的風險。
對客戶端和服務器進行相互身份驗證，以防止不可否認性和中間操縱器（MiTM）攻擊。

威脅建模工具（如威脅樹和攻擊庫）可用于派生負面測試方案。威脅樹將假設根攻擊（例如，攻擊者可能能夠讀取其他用戶的消息）并識別安全控制的不同漏洞（例如，由于 SQL 注入漏洞導致數據驗證失敗）和必要的對策（例如，實施數據驗證和參數化查詢），這些措施可以被驗證為有效緩解此類攻擊。

通過使用和誤用案例推導出安全測試要求

描述應用程序功能的先決條件是了解應用程序應該做什么以及如何做。這可以通過描述用例來完成。用例，以軟件工程中常用的圖形形式，顯示參與者的交互及其關系。它們有助于識別應用程序中的參與者、它們的關系、每個方案的預期操作順序、替代操作、特殊要求、前提條件和后置條件。

與用例類似，誤用或濫用案例描述了應用程序的意外和惡意使用場景。這些誤用案例提供了一種方法來描述攻擊者如何誤用和濫用應用程序的方案。通過瀏覽使用場景中的各個步驟并考慮如何惡意利用它，可以發現應用程序的潛在缺陷或未明確定義的方面。關鍵是要描述所有可能的，或者至少是最關鍵的使用和誤用場景。

濫用場景允許從攻擊者的角度分析應用程序，并有助于識別潛在的漏洞和需要實施的對策，以減輕潛在暴露于此類漏洞所造成的影響。鑒于所有使用和濫用案例，重要的是要分析它們以確定哪些是最關鍵的，需要記錄在安全要求中。識別最嚴重的誤用和濫用案例會推動安全要求的記錄，以及應減輕安全風險的必要控制措施。

為了從使用和誤用案例中得出安全需求，定義功能場景和負面場景并以圖形形式放置它們非常重要。以下示例是派生身份驗證安全要求的分步方法。

步驟 1：描述功能方案

用戶通過提供用戶名和密碼進行身份驗證。應用程序根據應用程序對用戶憑據的身份驗證向用戶授予訪問權限，并在驗證失敗時向用戶提供特定錯誤。

第 2 步：描述負面場景

攻擊者通過對應用程序中的密碼和帳戶收集漏洞進行暴力破解或字典攻擊來破壞身份驗證。驗證錯誤向攻擊者提供特定信息，用于猜測哪些帳戶是有效的注冊帳戶（用戶名）。然后，攻擊者嘗試暴力破解有效帳戶的密碼。對最小長度為四位數的密碼的暴力攻擊可以在有限的嘗試次數（即 10\^4）下成功。

第 3 步：使用和誤用案例描述功能和負面場景

下面的圖形示例描述了通過使用和誤用案例推導安全要求的過程。功能方案由用戶操作（輸入用戶名和密碼）和應用程序操作（對用戶進行身份驗證并在驗證失敗時提供錯誤消息）組成。誤用案例包括攻擊者的行為，即試圖通過字典攻擊暴力破解密碼和從錯誤消息中猜測有效用戶名來破壞身份驗證。通過以圖形方式表示對用戶操作（誤用）的威脅，可以將對策推導出為緩解此類威脅的應用程序操作。

圖 2-5：使用和誤用案例

第 4 步：引出安全要求

在這種情況下，將派生以下身份驗證的安全要求：

密碼要求必須與當前標準保持一致，才能達到足夠的復雜性。
帳戶必須在五次登錄嘗試失敗后鎖定。
登錄錯誤消息必須是通用的。

這些安全要求需要記錄和測試。

?2.10?安全測試集成在開發和測試工作流程中

開發工作流程中的安全測試

SDLC 開發階段的安全測試是開發人員確保他們開發的各個軟件組件在與其他組件集成或內置到應用程序中之前進行安全測試的第一個機會。軟件組件可能由軟件工件（如函數、方法和類）以及應用程序編程接口、庫和可執行文件組成。對于安全測試，開發人員可以依靠源代碼分析的結果來靜態驗證開發的源代碼是否包含潛在漏洞，并且符合安全編碼標準。安全單元測試可以進一步動態（即在運行時）驗證組件是否按預期運行。在應用程序構建中集成新的和現有的代碼更改之前，應查看和驗證靜態和動態分析的結果。

在集成到應用程序構建中之前驗證源代碼通常是高級開發人員的責任。高級開發人員通常是軟件安全方面的主題專家，他們的角色是領導安全代碼審查。他們必須決定是接受要在應用程序構建中發布的代碼，還是要求進一步的更改和測試。這種安全的代碼審查工作流可以通過正式驗收以及工作流管理工具中的檢查來強制執行。例如，假設用于功能錯誤的典型缺陷管理工作流，則可以在缺陷或變更管理系統上報告開發人員已修復的安全錯誤。然后，生成主機可以查看開發人員在工具中報告的測試結果，并授予將代碼更改簽入應用程序生成的批準。

測試工作流中的安全測試

在開發人員測試組件和代碼更改并簽入應用程序構建后，軟件開發過程工作流中最有可能的下一步是對應用程序作為一個整體實體執行測試。這種級別的測試通常稱為集成測試和系統級測試。當安全測試成為這些測試活動的一部分時，它們可用于驗證整個應用程序的安全功能，以及應用程序級漏洞的暴露情況。應用程序上的這些安全測試包括白盒測試（如源代碼分析）和黑盒測試（如滲透測試）。測試還可以包括灰盒測試，在灰盒測試中，假設測試人員對應用程序有一定的了解。例如，通過對應用程序的會話管理有一定的了解，測試人員可以更好地了解注銷和超時函數是否得到適當的保護。

安全測試的目標是易受攻擊的完整系統。在此階段，安全測試人員可以確定漏洞是否可以被利用。其中包括常見的 Web 應用程序漏洞，以及 SDLC 中早些時候通過威脅建模、源代碼分析和安全代碼審查等其他活動確定的安全問題。

通常，當應用程序在集成系統測試范圍內時，測試工程師（而不是軟件開發人員）會執行安全測試。測試工程師具有 Web 應用程序漏洞、黑盒和白盒測試技術的安全知識，并負責此階段安全需求的驗證。為了執行安全測試，安全測試用例必須記錄在安全測試指南和程序中。

在集成系統環境中驗證應用程序安全性的測試工程師可能會發布應用程序以在操作環境中進行測試（例如，用戶驗收測試）。在 SDLC（即驗證）的這個階段，應用程序的功能測試通常由 QA 測試人員負責，而白帽黑客或安全顧問通常負責安全測試。一些組織依靠自己的專業道德黑客團隊在不需要第三方評估時（例如用于審計目的）進行此類測試。

由于這些測試有時可能是在應用程序發布到生產環境之前修復漏洞的最后一道防線，因此按照測試團隊的建議解決問題非常重要。這些建議可以包括代碼、設計或配置更改。在這個級別，安全審計員和信息安全官根據信息風險管理程序討論報告的安全問題并分析潛在風險。此類過程可能要求開發團隊在部署應用程序之前修復所有高風險漏洞，除非此類風險得到承認和接受。

開發人員的安全測試

編碼階段的安全測試：單元測試

從開發人員的角度來看，安全測試的主要目標是驗證代碼的開發是否符合安全編碼標準要求。開發人員自己的編碼工件（例如函數、方法、類、API 和庫）在集成到應用程序構建之前需要進行功能驗證。

開發人員必須遵循的安全要求應記錄在安全編碼標準中，并通過靜態和動態分析進行驗證。如果單元測試活動遵循安全代碼評審，則單元測試可以驗證安全代碼評審所需的代碼更改是否已正確實現。通過源代碼分析工具進行安全代碼審查和源代碼分析都可以幫助開發人員在開發源代碼時識別源代碼中的安全問題。通過使用單元測試和動態分析（例如調試），開發人員可以驗證組件的安全功能，并驗證正在開發的對策是否減輕了以前通過威脅建模和源代碼分析確定的任何安全風險。

對于開發人員來說，一個好的做法是將安全測試用例構建為通用安全測試套件，該套件是現有單元測試框架的一部分。通用安全測試套件可以從先前定義的使用和誤用案例派生到安全測試功能、方法和類。通用安全測試套件可能包括安全測試用例，以驗證安全控制的正面和負面要求，例如：

身份、身份驗證和訪問控制
輸入驗證和編碼
加密
用戶和會話管理
錯誤和異常處理
審核和日志記錄

開發人員可以通過集成到其 IDE 中的源代碼分析工具、安全編碼標準和安全單元測試框架來評估和驗證正在開發的軟件組件的安全性。可以運行安全測試用例來識別源代碼中具有根本原因的潛在安全問題：除了進入和退出組件的參數的輸入和輸出驗證外，這些問題還包括組件完成的身份驗證和授權檢查、組件內數據的保護、安全異常和錯誤處理以及安全審計和日志記錄。可以調整單元測試框架（如 JUnit、NUnit 和 CUnit）來驗證安全測試要求。對于安全功能測試，單元級測試可以在軟件組件級別測試安全控件的功能，例如函數、方法或類。例如，測試用例可以通過斷言組件的預期功能來驗證輸入和輸出驗證（例如，變量衛生）和變量的邊界檢查。

使用和誤用案例標識的威脅場景可用于記錄測試軟件組件的過程。例如，在身份驗證組件的情況下，安全單元測試可以斷言設置帳戶鎖定的功能，以及不能濫用用戶輸入參數來繞過帳戶鎖定的事實（例如，通過將帳戶鎖定計數器設置為負數）。

在組件級別，安全單元測試可以驗證正面斷言和負面斷言，例如錯誤和異常處理。捕獲異常時，應不使系統處于不安全狀態，例如，由于未取消分配資源（例如，連接句柄未在最終語句塊中關閉）導致的潛在拒絕服務，以及潛在的權限提升（例如，在引發異常之前獲得的更高權限，并且在退出函數之前未重新設置為上一級）。安全錯誤處理可以通過信息豐富的錯誤消息和堆棧跟蹤來驗證潛在的信息泄露。

單元級安全測試用例可以由安全工程師開發，安全工程師是軟件安全領域的主題專家，還負責驗證源代碼中的安全問題是否已修復，是否可以簽入集成系統構建。通常，應用程序構建的管理器還會確保在將第三方庫和可執行文件集成到應用程序構建中之前，對潛在漏洞進行安全評估。

開發人員的安全測試指南中還記錄了常見漏洞的威脅場景，這些漏洞的根本原因在于不安全的編碼。例如，當對通過源代碼分析識別的編碼缺陷實施修復時，安全測試用例可以驗證代碼更改的實現是否遵循安全編碼標準中記錄的安全編碼要求。

源代碼分析和單元測試可以驗證代碼更改是否緩解了以前發現的編碼缺陷所暴露的漏洞。自動安全代碼分析的結果還可以用作版本控制的自動簽入入口，例如，軟件工件無法簽入具有高或中等嚴重性編碼問題的生成。

功能測試人員的安全測試

集成和驗證階段的安全測試：集成系統測試和操作測試

集成系統測試的主要目標是驗證“縱深防御”概念，即安全控制的實施在不同層提供安全性。例如，在調用與應用程序集成的組件時缺少輸入驗證通常是可以通過集成測試進行測試的一個因素。

集成系統測試環境也是測試人員可以模擬真實攻擊場景的第一個環境，這些場景可能由應用程序的惡意外部或內部用戶執行。此級別的安全測試可以驗證漏洞是否真實，是否可被攻擊者利用。例如，在源代碼中發現的潛在漏洞可能被評定為高風險，因為暴露于潛在的惡意用戶，以及潛在的影響（例如，訪問機密信息）。

可以使用手動測試技術和滲透測試工具來測試真實的攻擊場景。這種類型的安全測試也稱為道德黑客測試。從安全測試的角度來看，這些是風險驅動的測試，目的是在操作環境中測試應用程序。目標是代表要部署到生產中的應用程序版本的應用程序版本的應用程序內部版本。

在集成和驗證階段包括安全測試對于識別由于組件集成而導致的漏洞以及驗證此類漏洞的暴露至關重要。應用程序安全測試需要一套專門的技能，包括軟件和安全知識，這些技能不是安全工程師所具備的。因此，組織通常需要對其軟件開發人員進行道德黑客技術以及安全評估程序和工具的安全培訓。一個現實的方案是在內部開發此類資源，并將它們記錄在安全測試指南和程序中，這些指南和程序考慮到了開發人員的安全測試知識。例如，所謂的“安全測試用例備忘單或清單”可以提供簡單的測試用例和攻擊向量，測試人員可以使用這些測試用例和攻擊向量來驗證暴露于常見漏洞，例如欺騙、信息泄露、緩沖區溢出、格式字符串、SQL 注入和 XSS 注入、XML、SOAP、規范化問題、拒絕服務以及托管代碼和 ActiveX 控件（例如 .NET）。這些測試的第一組可以手動執行，并具有非常基本的軟件安全知識。

安全測試的第一個目標可能是驗證一組最低安全要求。這些安全測試用例可能包括手動強制應用程序進入錯誤和異常狀態，以及從應用程序行為中收集知識。例如，可以通過用戶輸入注入攻擊媒介，并檢查是否將 SQL 異常拋回給用戶來手動測試 SQL 注入漏洞。SQL 異常錯誤的證據可能是可被利用的漏洞的表現形式。

更深入的安全測試可能需要測試人員了解專門的測試技術和工具。除了源代碼分析和滲透測試外，這些技術還包括：源代碼和二進制故障注入、故障傳播分析和代碼覆蓋率、模糊測試和逆向工程。安全測試指南應提供安全測試人員可用于執行此類深入安全評估的過程和推薦工具。

集成系統測試之后的下一個安全測試級別是在用戶驗收環境中執行安全測試。在操作環境中執行安全測試具有獨特的優勢。用戶驗收測試（UAT）環境是最能代表發布配置的環境，但數據除外（例如，使用測試數據代替真實數據）。UAT中安全測試的一個特點是測試安全配置問題。在某些情況下，這些漏洞可能代表高風險。例如，托管 Web 應用程序的服務器可能未配置最低權限、有效的 SSL 證書和安全配置、禁用基本服務以及清除測試和管理網頁的 Web 根目錄。

2.11安全測試數據分析和報告

安全測試指標和度量的目標

定義安全測試指標和度量的目標將安全測試數據用于風險分析和管理流程的先決條件。例如，度量值（例如通過安全測試發現的漏洞總數）可以量化應用程序的安全狀況。這些度量還有助于確定軟件安全測試的安全目標，例如，在將應用程序部署到生產環境之前，將漏洞數量減少到可接受的最小數量。

另一個可管理的目標可能是將應用程序安全態勢與基線進行比較，以評估應用程序安全流程的改進。例如，安全指標基線可能包含僅通過滲透測試進行測試的應用程序。與基線相比，從在編碼期間也經過安全測試的應用程序獲得的安全數據應顯示出改進（例如，更少的漏洞）。

在傳統的軟件測試中，軟件缺陷的數量，例如在應用程序中發現的錯誤，可以提供軟件質量的衡量標準。同樣，安全測試可以提供軟件安全性的衡量標準。從缺陷管理和報告的角度來看，軟件質量和安全測試可以使用類似的分類來處理根本原因和缺陷補救工作。從根本原因的角度來看，安全缺陷可能是由于設計錯誤（例如安全漏洞）或編碼錯誤（例如安全錯誤）造成的。從修復缺陷所需的工作量的角度來看，安全和質量缺陷都可以根據開發人員實施修復的時間、所需的工具和資源以及實施修復的成本來衡量。

與質量數據相比，安全測試數據的一個特征是根據威脅、漏洞暴露程度以及漏洞帶來的潛在影響進行分類，以確定風險。測試應用程序的安全性包括管理技術風險，以確保應用程序對策滿足可接受的級別。因此，在 SDLC 期間，安全測試數據需要支持關鍵檢查點的安全風險策略。例如，通過源代碼分析在源代碼中發現的漏洞代表了風險的初始度量。漏洞的風險度量（例如，高、中、低）可以通過確定暴露和可能性因素，并通過滲透測試驗證漏洞來計算。與安全測試中發現的漏洞相關的風險指標使業務管理層能夠做出風險管理決策，例如決定是否可以在組織內的不同級別接受、減輕或轉移風險（例如，業務風險和技術風險）。

在評估應用程序的安全狀況時，必須考慮某些因素，例如正在開發的應用程序的大小。應用程序大小已通過統計證明與測試期間在應用程序中發現的問題數量有關。由于測試可以減少問題，因此比較小尺寸的應用程序更頻繁地測試較大尺寸的應用程序是合乎邏輯的。

當安全測試分幾個階段進行時，測試數據可以證明安全測試在引入漏洞后立即檢測漏洞的能力。測試數據還可以證明通過在SDLC的不同檢查點實施對策來消除漏洞的有效性。這種類型的度量也被定義為“遏制指標”，并提供在開發過程的每個階段執行的安全評估的度量，以維護每個階段的安全性。這些遏制指標也是降低修復漏洞成本的關鍵因素。在發現漏洞的同一階段處理漏洞的成本較低，而不是在以后的另一個階段修復它們。

當安全測試指標與有形和定時目標相關聯時，它們可以支持安全風險、成本和缺陷管理分析，例如：

將漏洞總數減少 30%。
在特定截止日期之前修復安全問題（例如，在測試版發布之前）。

安全測試數據可以是絕對的，例如在手動代碼審查期間檢測到的漏洞數量，也可以是比較的，例如與滲透測試相比，在代碼審查中檢測到的漏洞數量。要回答有關安全過程質量的問題，重要的是要確定可以被認為是可接受和良好的基線。

安全測試數據還可以支持安全分析的特定目標。這些目標可以是遵守安全法規和信息安全標準、管理安全流程、確定安全根本原因和流程改進以及安全成本效益分析。

當報告安全測試數據時，它必須提供指標來支持分析。分析的范圍是對測試數據的解釋，以找到有關所生產軟件安全性以及過程有效性的線索。

安全測試數據支持的線索的一些示例可以是：

漏洞是否減少到可接受的發布級別？
本產品的安全質量與同類軟件產品相比如何？
是否滿足所有安全測試要求？
安全問題的主要根本原因是什么？
與安全漏洞相比，安全漏洞有多少？
哪種安全活動在查找漏洞方面最有效？
哪個團隊在修復安全缺陷和漏洞方面更有效率？
高風險漏洞占總體漏洞的百分比是多少？
哪些工具在檢測安全漏洞方面最有效？
什么樣的安全測試在發現漏洞（例如，白盒與黑盒）測試方面最有效？
在安全代碼審查期間發現了多少安全問題？
在安全設計評審期間發現了多少安全問題？

為了使用測試數據做出合理的判斷，對測試過程和測試工具有很好的了解是很重要的。應采用工具分類法來決定使用哪些安全工具。當針對不同的工件時，安全工具可以被定性為善于發現常見的已知漏洞。

需要注意的是，未知的安全問題不會被測試。安全測試沒有問題的事實并不意味著軟件或應用程序是好的。

即使是最復雜的自動化工具也無法與經驗豐富的安全測試人員相提并論。僅僅依靠自動化工具的成功測試結果會給安全從業者帶來一種虛假的安全感。通常，安全測試人員對安全測試方法和測試工具越有經驗，安全測試和分析的結果就越好。重要的是，對安全測試工具進行投資的管理人員還要考慮在雇用熟練的人力資源以及安全測試培訓方面進行投資。