如何寫好一篇漏洞總結報告，這一直都是一些應用開發公司經常忽略的重要事情，一篇好的漏洞總結報告可以有效幫助開發人員，減少尋找和解決漏洞的時間。

接下來我就開始講述如何該寫好一篇漏洞總結報告，這樣你就可以在看完報告後短時間內解決漏洞問題，同時也可以避免在軟體專案過程中遭遇公關問題。那麼首先來對比一下錯誤和正確的漏洞總結報告。

一個錯誤的漏洞總結報告是什麼樣的？

在開始分析之後，先為大家介紹幾個漏洞基本概念，CVSS(Common Vulnerability Scoring System)即通用漏洞評分系統 是安全內容自動化協議(SCAP)的一部分，分值（0-100)，同時為行業公開標準,其被設計用來評測漏洞的嚴重程度 幫助確定所需反應的緊急度和重要度。CVSS同CVE一同由美國國家漏洞庫(NVD)釋出並保持資料的更新，CVE(Common Vulnerabilities and Exposures)為漏洞和暴露確定了唯一的名稱以及一個標準化的描述，同時實現更好的協同工作。

下面我們就來一起分析下錯誤漏洞總結報告，我們就先來看看錯誤漏洞總結報告是什麼樣的。請試著想象這樣一件事情，我們搭建了一個有關球迷的社交網站，在一次網站程序升級檢測之後，質量保證專員在JIRA上填寫漏洞總結報告。下面這張圖片就是例子

第一眼看過去這篇報告似乎一切沒有問題，不是嗎？那麼到底還缺少什麼內容呢？下面我們就一起來分析一下

漏洞編號（ID）：當你在JIRA網站上填寫漏洞總結報告時，網站會預設分配給你一個編號，這一塊沒有什麼問題。

漏洞摘要：該資訊往往位於編號資訊下面，但這篇報告卻沒有一語中的，報告中雖然提及了漏洞影響的使用者型別，但沒有具體說明是哪一種型別的漏洞。如果一個Web開發者看到這樣一篇報告，就會提出很多的問題並要求對方來澄清這些疑問。

漏洞詳述：很明顯測試人員沒有提供關於應用程式版本和測試環境的任何資料，我們在下面的文章將會詳細描述這一點，至於漏洞優先順序問題，測試人員通常會優先分配優先順序，以後可能會根據實際情況改變優先順序。對於目前國內提交漏洞優先順序，需要說明一下，如下：

1)高危安全問題：

1、直接獲取業務伺服器許可權的漏洞。包括但不限於任意命令執行、上傳獲取webshell、直接導致嚴重的資訊洩漏漏洞。 2、包括但不限於核心DB的SQL注入漏洞（涉及使用者資料、訂單資料、交易資料），直接導致嚴重影響的邏輯漏洞。 3、包括但不限於任意帳號密碼更改漏洞。 4、越權訪問，僅限於重要業務線批量獲取訂單類資訊的漏洞(敏感資料明文)、使用者資料資訊（明文）、繞過驗證直接訪問後臺、重要後臺登入弱口令。

2)中危安全問題：

1、需互動才能獲取使用者身份資訊的漏洞。 2、包括但不限於任意檔案讀、寫、刪除、下載等操作。 3、包括但不限於繞過限制修改使用者資料、執行使用者操作，較嚴重的資訊洩漏漏洞 4、包括但不限於批量獲取使用者類、訂單類資訊的漏洞。 5、非核心業務SQL注入，不涉及使用者資料、訂單資料、交易資料，按中風險處理

3)低危安全問題：

1、普通邏輯漏洞；普通訊息洩露；需互動才能獲取使用者身份資訊並且有一定利用難度的漏洞。 2、Discuz 漏洞問題均按低風險處理(discuz非qunar主要業務) 3、批量下訂單、發垃圾簡訊、加關注按低風險處理 4、越權訪問，包含敏感資訊且打碼，按低風險處理 5、代理商弱口令及密碼等資訊通過雲盤、筆記、QQ群備註等洩漏的按低風險處理 6、代理商及合作方後臺地址外洩導致暴力破解，按低風險處理。 7、猜測或遍歷網站註冊使用者，按低風險處理

4)通常忽略的問題：

1、不涉及安全問題的bug，包括但不限於網站產品功能缺陷、頁面亂碼、樣式混編等。 2、不會直接帶來安全問影響，包括但不限於繞過WAF對業務無影響的，Self-XSS，非登入相關的URL跳轉，非敏感操作的CSRF，非敏感資訊的JSON Hijacking，無意義的原始碼洩漏、程式出錯而暴露出來無安全影響的資訊、內網IP/域名洩漏，以及需藉助中間人攻擊才能實現的問題。 3、無法重現的漏洞、不能直接體現漏洞的其他問題。包括但不限於純屬使用者推測的問題（需要案例）。 4、廠商內部自行發現的，廠商SRC已知的，第三方漏洞平臺報告過的漏洞做忽略處理，且廠商提供相應截圖（其中：高危：4小時，中危：14天，低危：28天）。 5、第三方已披露的漏洞（基礎應用0day，開發框架0day等），距離公告期兩天以上且廠商已知曉的。 6、由於已經對關鍵位置實施HttpOnly限制，XSS漏洞暫不接收（後臺盲打類xss除外）。 7、無線訂單鏈接越權檢視（使用者等資訊打碼，不能遍歷）的按低風險處理

漏洞描述：這塊是出現問題最多的地方，在這一部分，測試人員應該按照重新配置、實際結果和預期結果的步驟提供漏洞相關資訊。漏洞總結報告就是應該提供有關漏洞的詳細資訊，如果質量保證專員不能有效的再現漏洞問題，那麼看到這篇漏洞報告的軟體開發人員就需要多花時間在尋找漏洞問題上。

在看完上面截圖資訊之後，Web開發人員將立即詢問負責編寫報告的人使用了哪些登入憑證，如管理員資訊、測試使用者資訊以及版主資訊（含BBS模板網站常見）。除此之外，還需要知道出現伺服器漏洞（本地環境）問題，簡單來說，這種情況一般出現在測試伺服器（https://testing-bugs.sprinklebit.com），或生產伺服器（https://sprinklebit.com）。還有一個概念大家需要了解，漏洞管理三要素，即準確性、時間以及資源。

測試人員應該提供預期結果，這些細節可以幫助開發人員（有些沒參與其軟體開發人員對於程式細節不清楚）快速解決這個問題，但我們在報告中沒有看到直觀的漏洞資料統計圖形，比如一些附加圖形影象。

如何將一篇糟糕的漏洞總結報告改進？

請看下面這篇報告的截圖，這篇漏洞總結報告就比之前的那篇好些。

第二篇和第一篇有什麼不同？主要是第二篇的報告對於細節描述更加詳細具體，Web開發人員可以根據報告內容對程式進行修改。下面就來說明一下第二篇報告改進的地方，測試人員在報告中描述了重要細節，“聊天功能——建立臨時會話的群主不能重新命名它”，當然這裡面還有其它一些有價值的資訊，諸如受影響軟體版本號、執行環境以及修復版本資訊。

測試人員提到了檢測出漏洞的應用程式版本，同時還指出當時測試環境，這樣就可以很清楚的瞭解網站當前執行環境版本。之前描述的步驟中重現是非常重要的，它

可以顯示必要的網站登入資料、網站相關軟體版本以及按鈕說明。實際結果雖然出現在截圖中，但測試人員並沒有忘記提及預期結果。

在這裡強調的一點是，所有漏洞總結報告都應該按照統一規則編寫，漏洞總結報告在追蹤漏洞方面是非常實用的。

下面我就來介紹一下如何寫好一篇高質量的漏洞總結報告，以方便開發人員更高效的解決漏洞問題，最後當漏洞總結報告上的問題迅速解決的時候，你設計的應用程式將會從中獲益。

寫好一篇高質量漏洞總結報告的訣竅

漏洞總結報告主要是向開發人員澄清一個明確的問題，同時有助於開發人員開發整個專案。在質量保證團隊開始編寫漏洞報告的時候，他們應該瞭解以下問題的答案

什麼?-應用程式發生了什麼事情？ 如何？-我們點選/執行程式不發生錯誤？ 在哪裡？-到底在應用程式哪個位置出現漏洞?網頁/伺服器?

下面就開始講解一種編寫漏洞總結報告的樣板，並拿一個網站舉個例子。

漏洞編號

測試人員可以在 Bugzilla、JIRA等平臺編寫報告，如果你選擇在這些平臺編寫報告，通常會得到一個編號。另外測試人員也可以手動編寫一個編號，這樣做比填寫完整標題的方案，很顯然前者可以節約開發人員開發時間。

在實際生活中，沒有人會手動編寫一個編號，如果你一定要選擇手動編寫，可以考慮利用應用程式名稱縮寫，SprinkleBit就可以用SB-WEB代替，SB-MOB則表示該應用移動端版本。另外，測試人員需要為漏洞加索引編號。

正確：sb-web-121或sb-mob-231（儘量將應用程式執行哪種環境表達出來）

錯誤：我的網站-#87123或簡單標記#112

開發人員有時需要同時處理多個專案，所以設定一個一目瞭然的漏洞編號，這樣可以清楚的表達是哪一個應用程式出現問題。

漏洞摘要

在JIRA網站平臺編寫報告，需要填寫一個標題，這就需要了解報告摘要內容之後才能做這件事情，摘要可以說是漏洞總結報告最核心的部分。對於初學者，我建議使用簡訊息來填寫標題，漏洞摘要通常是以簡短的語言描述問題的關鍵，JIRA 中的專案進展分級為Epic（史詩）->Story（故事）->Task（任務），Epic 可以說佔用你在JIRA平臺報告中大部分資訊，如之前聊天或使用者個人資料部分分析，你需要提示測試人員不能帶有自身情緒以及主觀意見，同時以簡短的方式來描述發生了什麼事情。

正確表達方式：關於公司螢幕出現問題，螢幕頂部出現紅色條紋，還有螢幕中的彩色佈局不協調問題。

錯誤表達方式：屏幕布局有問題/螢幕出現問題

漏洞詳細資訊

我作為經驗豐富的質量保證專員，強烈建議您的測試人員應在報告中，詳細說明應用程式版本以及測試環境，通常情況下，應用程式應每兩到三週更新一次，例如，我們可能每兩週釋出一個新版本的應用程式，同時修復老版本錯誤。

具體來說就是已經完成了2.21版本（假設新版本號），就沒有必要在2.01版本（假設舊版本號）建立一個相關漏洞資訊的報告。但這裡需要注意的是，你需要讓你的測試人員詳細更新報告，並在報告中指出是哪個應用程式版本出現問題。

根據漏洞型別的不同，測試環境可分為網站版本，作業系統或Web瀏覽器。例如，你有兩個網站www.my-website.com和testing.my-website.com用來測試，但測試環境很顯然是不同的（測試伺服器和生產伺服器），所以導致最終的結果也會不同。因此，測試人員需要在漏洞總結報告中指出詳細網址資訊。如果發現是執行環境問題，就需要記下瀏覽器名稱和版本。測試人員在報告中需詳細描述測試環境，同時可以為後來的網站開發人員節約時間，也可以幫助開發人員瞭解問題的關鍵所在。如果測試人員不在報告中新增這一項，那麼開發人員也會跳過這一個容易被忽略的地方。他們不負責檢測漏洞，並有可能導致任務失敗。

漏洞的嚴重性以及優先順序

這兩項可以單獨列出來，也可以合併為一個引數。而這取決於測試人員使用的漏洞分析平臺，漏洞的嚴重性是針對漏洞對於應用程式的影響，從臨界範圍（漏洞關鍵功能）降低（錯誤很難重現）再到主要功能正常，一些不常用功能很可能出現問題。一般情況下，測試人員會使用這種模式。

漏洞優先順序反過來是概述漏洞修復層次結構的工具，專案經理通常設定優先權，漏洞優先順序按漏洞嚴重程度排列，並使得範圍逐漸縮小。簡單來說，如果一個漏洞關鍵問題起作用時，那麼該漏洞優先順序和嚴重程度都會被評為“高危”漏洞。當然漏洞關鍵問題並沒有那麼重要時，我們會指定漏洞的優先順序和嚴重程度，舉個例子，在被測試網站登入頁面上的一級標題內容出現拼寫錯誤。像這種漏洞危害級別程度很低，而且不影響程式正常功能。網站使用者仍然可以登入網站，但我們也不應該忽視這樣的漏洞，登入網站的使用者第一個看的就是網頁內容，所以我們不應該出現這樣低階的錯誤。

在現實中，我們可以在JIRA中指定最初指定的優先順序，然後向Web開發人員和專案經理報告漏洞及其優先順序或嚴重程度。專案經理可以聯絡客戶並告訴他們發生了什麼事。最後，客戶決定是否必須儘快解決這個問題，或選擇等待客戶的意見可能與測試人員所想的不同，因此這些事項順序可以根據客戶意願很容易改變。

漏洞描述

測試人員應該向開發人員提供詳細的漏洞總結報告（重現漏洞問題）。

重現

這個步驟主要是描述漏洞是如何出現的，當然測試人員越多，越好。

產品

應用程式出現問題的詳細描述，測試人員應該提到瀏覽器、它的版本和執行環境系統狀態、使用者型別、使用者狀態、系統初始資料和使用者所在的頁面。

展示

測試人員展示如何出現漏洞

在看完上文後，我為大家總結一下安全檢查列表，主要分為軟體安全漏洞、配置錯誤、產品名稱以及影響度量。

實際結果與預期結果

實際結果是當測試人員重現漏洞時發生的事情，質量保證團隊提供實際結果的截圖，並與預期的結果進行比較。預期的結果是我們在給定條件下預計的正常功能。

下面這兩個資訊，一個是錯誤的報告，一個是正確的報告。

正確 錯誤

漏洞已經在 Chrome 47以及火狐瀏覽器（38）測試 開啟網站 http://www.hersheys.com

僅在火狐瀏覽器（38）有效 登入

登入https://www.hersheys.com/recipes/en_US/products/baking-pieces.html 退出賬戶

選擇Products選項 選擇Reese’s Mini Pieces選項

點選Baking Pieces 實際結果：從列表中刪除所選項

                                                                                                                              預期結果：應開啟Reese's Mini Pieces選項詳細說明頁

漏洞總結報告的附加資訊

這是漏洞總結報告最後的部分，如有必要，測試人員可附上任何相關的附加檔案。我們的目標是儘可能多地收集檔案，附件可以是，一張截圖、一個日誌檔案（log.txt）、詳細描述漏洞檔案、測試人員程式介面。在上文已經說明質量保證團隊如何寫報告，由於某些漏洞分析平臺不同細節就會有出入，但遵循這些準則應有助於編寫優秀的漏洞總結報告。