sonarqube掃描報告之中有一個“安全熱點”，按照自己的理解，安全熱點就是安全漏洞嘛，或者安全問題。 在准備sonar培訓的時候，自己特意去了解掃描報告的各種問題類型，看到下文解釋“安全熱點”非常透徹，於是收藏在此。
什么是安全熱點？
安全熱點突出顯示開發人員需要審查的安全敏感代碼段。經過審查，您要么會發現沒有威脅，要么需要應用修復程序來保護代碼。
查看熱點的另一種方式可能是深度防御的概念，其中在應用程序中放置了幾個冗余保護層，以便在發生攻擊時變得更有彈性。
漏洞還是熱點？
熱點和漏洞之間的主要區別在於在決定是否應用修復之前需要進行審查：
- 使用熱點，可以突出顯示安全敏感的一段代碼，但可能不會影響整體應用程序安全性。由開發人員審查代碼以確定是否需要修復以保護代碼。
- 對於漏洞，已發現需要立即修復的影響應用程序安全性的問題。
一個例子是RSPEC-2092，其中建議使用cookie 安全標志來防止通過非 HTTPS 連接發送 cookie，但需要進行審查，因為：
- HTTPS 是抵御 MITM 攻擊的主要保護措施，因此安全標志只是在網絡安全發生某些故障時的附加保護。
- cookie 可能被設計為隨處發送（包括非 HTTPS 網站），因為它是跟蹤 cookie 或類似的。
通過熱點，我們嘗試為用戶提供一些自由，並教育他們如何根據上下文（預算、威脅等）選擇最相關/最合適的保護措施。
為什么安全熱點很重要？
雖然修復單個熱點的需要取決於上下文，但您應該將安全熱點視為提高應用程序健壯性的重要部分。固定熱點越多，您的代碼在遭受攻擊時就越安全。查看安全熱點允許您：
- 了解風險——了解何時以及為何需要應用修復以降低信息安全風險（威脅和影響）。
- 確定保護措施– 在查看熱點時，您將了解如何避免編寫有風險的代碼、確定哪些修復已到位，並確定仍需要實施哪些修復以修復突出顯示的代碼。
- 識別影響– 通過熱點，您將學習如何根據對整體應用程序安全性的影響應用修復程序來保護您的代碼。熱點頁面中包含推薦的安全編碼實踐，以幫助您進行審核。
生命周期
安全熱點具有專用的生命周期。要更改狀態，用戶需要管理安全熱點權限。默認情況下啟用此權限。具有瀏覽權限的用戶可以評論或更改分配給安全熱點的用戶。
狀態
在整個生命周期中，安全熱點采用以下狀態之一：
- To Review – SonarQube 設置的新安全熱點的默認狀態。已報告安全熱點，需要檢查。
- 已審核– 開發人員已手動評估安全熱點並決定是否應用修復程序。
工作流程
按照此工作流程查看安全熱點並應用保護代碼所需的任何修復程序。
審核優先級
當 SonarQube 檢測到一個安全熱點時，它會根據其審查優先級從高到低添加到安全熱點列表中。具有高審查優先級的熱點最有可能包含需要保護並首先需要您注意的代碼。
審核優先級由每個安全規則的安全類別決定。在 OWASP 前 10 名和 CWE 前 25 名標准中排名靠前的類別中的規則被認為具有高審查優先級。排名不高或未在 OWASP 前 10 名或 CWE 前 25 名標准中提及的類別中的規則被評為中或低。
查看熱點
在查看熱點時，您應該：
- 查看什么是風險選項卡以了解為什么會引發安全熱點。
- 從“您是否有風險”選項卡中，閱讀“問自己是否存在”部分以確定您是否需要應用修復程序來保護熱點中突出顯示的代碼。
- 從“如何修復它”選項卡中，如果您確定代碼不安全，請按照推薦的安全編碼實踐來修復您的代碼。
完成這些步驟后，將安全熱點設置為以下之一：
- 已修復– 如果您已應用修復程序來保護熱點突出顯示的代碼。
- 安全- 如果代碼已經安全並且不需要修復。（例如，其他更相關的保護措施已經到位）。
- 審查- 如果您需要其他用戶的審查。
回顧歷史
“審查歷史記錄”選項卡顯示安全熱點的歷史記錄，包括分配的狀態以及審查者對熱點的任何評論。
在 IDE 中查看熱點
直接在 IDE 中查看安全熱點可以幫助您更好地了解其上下文並確定它是否安全。這是您將作為經過身份驗證的用戶看到的在 IDE 中打開按鈕的用途。
此功能可供以下用戶使用：
- 適用於 Visual Studio 4.29 及更高版本的SonarLint
- 適用於 IntelliJ 4.13 及更高版本的SonarLint
- VS Code 1.20 及更高版本的SonarLint
- Eclipse 5.7 及更高版本的SonarLint
項目需要在合適的IDE中打開，並通過SonarLint的連接方式綁定到服務器。
請記住，SonarQube 分析的修訂或分支可能與您在 IDE 中打開的不同。在這種情況下，SonarLint 將盡最大努力在您的本地代碼中定位安全熱點。
安全熱點和漏洞有什么區別？
安全熱點和漏洞的不同之處在於：
- 安全熱點是一段對安全敏感的代碼，突出顯示但不一定影響整體應用程序安全。由開發人員審查代碼以確定是否需要修復以保護代碼。
- 漏洞是影響應用程序安全的問題，需要立即修復。
有關更多詳細信息，請參閱安全熱點頁面。
為什么我看不到任何漏洞或安全熱點？
由於以下原因，您可能看不到任何漏洞或安全熱點：
- 您的代碼是在未使用任何安全敏感 API 的情況下編寫的。
- 漏洞或安全熱點規則可用，但未在您的質量配置文件中激活，因此不會引發安全熱點或漏洞。
- SonarQube 目前可能沒有很多適用於您的語言的規則，因此它不會引發任何或僅少數漏洞或安全熱點。
| 概念 | 定義 |
|---|---|
| 分析儀 | 分析源代碼以計算快照的客戶端應用程序。 |
| 數據庫 | 存儲配置和快照 |
| 服務器 | 用於瀏覽快照數據和進行配置更改的Web 界面 |
質量
| 概念 | 定義 |
|---|---|
| 漏洞 | 表示代碼中出現錯誤的問題。如果這還沒有打破，它會，而且可能是在最糟糕的時刻。這需要修復。昨天。 |
| 代碼氣味 | 代碼中與可維護性相關的問題。保持原樣意味着維護人員最多會比他們對代碼進行更改更難。最壞的情況是，他們會對代碼的狀態感到困惑，以至於在進行更改時會引入額外的錯誤。 |
| 成本 | 查看修復成本 |
| 債務 | 見技術債 |
| 問題 | 當一段代碼不符合規則時，快照上會記錄一個問題。問題可以記錄在源文件或單元測試文件中。有 3 種類型的問題：錯誤、代碼異味和漏洞 |
| 措施 | 給定時間給定文件或項目的度量值。例如，類 MyClass 上的 125 行代碼或項目 myProject 上 30.5% 的重復行密度 |
| 公制 | 一種測量。隨着時間的推移，指標可以具有不同的值或度量。示例：代碼行數、復雜性等。度量可以是定性的（給出組件的質量指示、重復行的 EG 密度、測試的行覆蓋率等）或定量的（不給出質量指示）在組件上，EG 代碼行數，復雜度等） |
| 新代碼定義 | 您密切關注代碼中引入新問題的變更集或時期。理想情況下，這是因為previous_version，但如果您不使用類似 Maven 的版本控制方案，您可能需要設置一個時間段，例如 21 天，從特定分析開始，或使用參考分支。 |
| 質量簡介 | 一套規則。每個快照都基於單個質量配置文件。另見質量概況 |
| 規則 | 應遵循的編碼標准或實踐。不遵守編碼規則會導致錯誤、漏洞、安全熱點和代碼異味。規則可以檢查代碼文件或單元測試的質量。 |
| 修復成本 | 修復漏洞和可靠性問題所需的估計時間。 |
| 快照 | 在給定時間針對給定項目的一組措施和問題。每次分析都會生成一個快照。 |
| 安全熱點 | 需要手動檢查的安全敏感代碼段。經過審查，您要么會發現不存在威脅，要么會發現存在需要修復的易受攻擊的代碼。 |
| 技術債 | 修復所有可維護性問題/代碼異味所需的估計時間 |
| 漏洞 | 一個與安全相關的問題，代表攻擊者的后門。另請參閱安全相關規則。 |
原文鏈接：https://www.cnblogs.com/cndevops/p/15389826.html