解譯掃描儀工具的警示

11 分鐘

軟體組合分析工具會產生大量有關依賴項中的漏洞、授權問題和程式碼品質問題的警報。有效解譯這些警示需要瞭解嚴重性分數、評估可利用性、管理誤判，以及根據應用程式的實際風險排定補救工作的優先順序。如果沒有正確的解釋和優先順序，團隊將面臨警報疲勞，並將時間浪費在低影響問題上，同時錯過關鍵漏洞。

了解漏洞嚴重性

弱點嚴重性分數提供標準化的風險評估：

CVSS評分系統

通用漏洞評分系統（CVSS） 提供標準化的數字分數，指示漏洞嚴重性。

CVSS 度量值類別：

基本指標： 獨立於特定環境的內在漏洞特徵。
時間指標： 隨時間變化的漏洞特徵（漏洞可用性、修補程式可用性、置信度）。
環境指標： 特定環境和部署特有的弱點特性。

CVSS v3 基本分數計算： 基本分數結合了多個指標：

可利用性指標：

攻擊向量（AV）： 網路（N）、相鄰（A）、本機（L）或實體（P）。
攻擊複雜度（AC）： 利用漏洞的難度為低（L）或高（H）。
所需權限（PR）： 不需要（N）、低（L）或高（H）權限才能利用。
使用者互動(UI)：無 (N) 或必要 (R) 以成功惡意探索。

影響指標：

保密性影響（C）： 無（N）、低（L）或高（H）資訊揭露。
完整性影響（I）： 無（N）、低（L）或高（H）資料修改能力。
可用性影響（A）： 無（N）、低（L）或高（H）服務中斷。

CVSS 向量範例：

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

這代表了一個可利用網路的漏洞，具有低攻擊複雜性、無需權限、無需使用者交互，並且對機密性、完整性和可用性影響很大。

嚴重性分類

CVSS 分數對應至嚴重性評級：

Severity	CVSS 分數	說明	優先順序
重要	9.0 - 10.0	容易被利用的漏洞導致廣泛的系統入侵。	需要立即補救。
High	7.0 - 8.9	導致重大資訊洩漏或服務中斷的嚴重漏洞。	需要在幾天內進行補救。
Medium	4.0 - 6.9	可利用性或影響有限的中度漏洞。	需要在幾週內進行補救。
Low	0.1 - 3.9	安全影響最小的次要漏洞。	方便時進行修復。
沒有	0.0	沒有實際安全影響的資訊發現項目。	選擇性補救。

嚴重性詮釋範例：

嚴重漏洞（CVSS 10.0）：

CVE-2021-44228 (Log4Shell)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Description: Remote code execution in Apache Log4j 2
Impact: Unauthenticated attacker can execute arbitrary code remotely
Exploitability: Actively exploited in the wild with publicly available exploits

高漏洞（CVSS 8.1）：

CVE-2022-23648
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Description: Path traversal in container runtime
Impact: Authenticated users can access files outside container boundaries
Exploitability: Requires authentication but easily exploitable

中等漏洞（CVSS 5.9）：

CVE-2023-12345
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description: Information disclosure through timing attack
Impact: Sensitive information disclosure possible with sophisticated attack
Exploitability: Requires specific timing conditions, difficult to exploit

評估可利用性

CVSS 分數並不能說明完整的情況——可利用性評估決定了實際風險：

漏洞成熟度

漏洞利用階段：

未經證實：

地位： 理論上的漏洞，沒有已知的漏洞。
風險等級： 降低風險 — 利用需要攻擊者付出巨大的努力。
動作： 監控漏洞開發;計劃補救，但不緊急。

概念驗證：

狀態：已發佈但未武器化的概念驗證惡意探索程式碼。
風險等級： 中等風險 — 老練的攻擊者可能會將漏洞利用武器化。
動作： 優先考慮補救;制定緩解策略。

功能：

狀態： 公開可用的有效的攻擊代碼。
風險等級： 高風險 — 中等技能的攻擊者可以利用這種漏洞。
動作： 加快補救;如果修補延遲，則實作暫時緩解措施。

積極利用：

狀態： 漏洞在實際環境中被積極利用。
風險等級： 嚴重風險——剝削正在發生。
動作：緊急補救；立即實作緩解措施；監視是否有遭入侵。

可利用性評估範例：

CVE-2021-44228 (Log4Shell)
Severity: Critical (CVSS 10.0)
Exploit Maturity: Active exploitation

Analysis:
- Public exploit code available within hours of disclosure
- Automated scanning and exploitation observed globally
- Multiple malware families incorporating the exploit
- Trivial to exploit with single HTTP request

Priority: EMERGENCY - Immediate patching required

受攻擊面分析

判斷弱點是否可被攻擊：

可達性因素：

程式碼用法： 易受攻擊的程式碼路徑是否實際由您的應用程式執行？
網路曝光： 易受攻擊的元件是否暴露於網路存取？
身份驗證要求： 利用是否需要經過身份驗證的存取？
組態相依性： 此弱點是否需要特定設定才能被利用？

連線能力範例：

Vulnerability: SQL injection in unused admin feature
Severity: High (CVSS 8.5)
Reachability: NOT REACHABLE

Analysis:
- Vulnerable code exists in imported library
- Admin features are disabled in production configuration
- Vulnerable code paths never executed
- Network access to admin interface blocked by firewall

Priority: LOW - Update during regular maintenance window

環境背景

考慮您的特定環境：

網路分段：

面向互聯網：網際網路對向元件中的弱點具有最高優先順序。
內部網路： 如果網路是分段的，那麼僅限內部漏洞的優先順序較低。
隔離系統： 氣隙或隔離系統因網路漏洞而產生的風險最小。

資料敏感度：

敏感資料： 處理敏感資料的系統中的漏洞需要緊急修復。
公開資訊： 如果資料已經公開，則資訊洩漏漏洞的優先順序較低。
測試環境： 非生產環境中的弱點通常優先順序較低。

補償控制：

Web 應用程式防火牆： WAF 規則可能會減少惡意探索嘗試。
入侵偵測： IDS/IPS 可以偵測並阻止利用嘗試。
網路分段： 網路隔離限制了利用的影響。
最低權限： 受限的權限可減少惡意探索的影響。

管理誤判為真

並非所有報告的漏洞實際上都會影響您的應用程式：

常見的誤報原因

錯誤識別的組件：

命名衝突： 具有相似名稱的不同元件不正確匹配。
版本偵測錯誤： 版本識別不正確，導致漏洞匹配錯誤。
套件命名空間混淆： 不同生態系統中的套件被錯誤地識別為相同的套件。

誤報範例：

Alert: CVE-2022-12345 in "parser" package (npm)
Severity: High

Investigation:
- Application uses "xml-parser" package
- Scanner incorrectly identified "xml-parser" as vulnerable "parser" package
- Different packages with similar names
- Vulnerability does not affect application

Resolution: Suppress false positive with documented justification

未使用的程式碼路徑：

死代碼： 導入易受攻擊的代碼，但從未執行。
可選功能： 您的應用程式無法啟用的選擇性功能中的弱點。
開發依賴： 套件中的漏洞僅在開發期間使用，而不是在生產環境中使用。

版本範圍錯誤：

固定版本報告： 掃描器會報告已修補版本中的漏洞。
向後移植修補程式： 廠商會將安全性修正程式向後移植至舊版本，而不變更版本號碼。
自訂修補程式： 漏洞已通過自訂修改獲得修補。

偽陽性驗證

調查過程：

驗證元件身分： 確認掃描器正確識別元件。
檢查版本準確性： 確認偵測到的版本與實際部署的版本相符。
檢閱弱點詳細資料： 瞭解弱點的影響。
分析程式碼使用情況： 判斷是否實際使用易受攻擊的程式碼路徑。
查閱供應商建議： 檢查供應商是否提供其他內容。
測試利用： 嘗試在測試環境中重現弱點。

文件要求： 抑制誤報時，請記錄：

理由： 為什麼這個發現是誤報。
調查詳情： 驗證誤報所採取的步驟。
審批人： 核准封鎖的安全小組成員。
檢閱日期：重新評估歸併的日期。

範例抑制檔案（OWASP Dependency-Check）：

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes>
            False positive: CVE-2022-12345 affects "parser" package but we use "xml-parser".
            Scanner incorrectly matched based on partial name match.
            Investigated by security team on 2025-10-21.
            Review annually.
        </notes>
        <packageUrl regex="true">^pkg:npm/xml-parser@.*$</packageUrl>
        <cve>CVE-2022-12345</cve>
    </suppress>
</suppressions>

優先順序架構

有效的漏洞管理需要系統性的優先順序：

以風險為基礎的優先順序

優先順序因素：

嚴重性評分（25% 權重）：

CVSS 基本分數為風險評估提供了基礎。
分數越高表示潛在影響越嚴重。

可利用性（35% 重量）：

活躍的利用狀態是最關鍵的因素。
公開漏洞利用的可用性顯著增加了風險。
概念驗證攻擊表明了漏洞利用的可行性。

資產關鍵性（20% 權重）：

網際網路對向應用程式具有較高的優先順序。
處理敏感資料的系統需要緊急修補。
關鍵業務應用程式無法容忍長時間的停機時間。

環境因素（20% 重量）：

現有的補償控制降低了有效風險。
網路分段限制了爆炸半徑。
監控功能可啟用威脅偵測。

優先級矩陣：

可利用性	嚴重嚴重性	高嚴重性	中等嚴重性	低嚴重性
積極利用	P0（緊急）	P0（緊急）	P1 （嚴重）	P2（高）
功能漏洞	P0（緊急）	P1 （嚴重）	P2（高）	P3 （中等）
概念驗證	P1 （嚴重）	P2（高）	P3 （中）	P4（低）
未經證實	P2 (高)	P3 （中等）	P4（低）	P5 （選配）

補救措施服務水平協議

定義補救的服務等級協定：

緊急情況（P0）：

時間範圍： 立即（24 小時內）。
標準： 在面向互聯網的系統中被積極利用的嚴重漏洞。
過程： 帶有行政通知的緊急變更流程。
例： Log4Shell （CVE-2021-44228）在面向公眾的應用程式中。

關鍵 (P1)：

時間範圍： 7天。
標準： 具有功能性漏洞或暴露於互聯網的高/重大嚴重性。
過程： 通過安全團隊協調加快變更流程。
例：在已驗證的管理介面中進行 SQL 注入。

高（P2）：

時間範圍： 30天。
標準： 具有概念驗證漏洞或內部暴露的中/高嚴重性。
過程： 具有計劃性維護時段的標準變更程序。
例：內部儀表板中的跨網站指令碼(XSS)。

中型（P3）：

時間範圍： 90天。
標準： 低/中嚴重性，沒有已知的漏洞。
過程： 定期更新週期，每季修補一次。
例：開發工具依賴中的資訊揭露。

低（P4）：

時間範圍： 下一個主要版本。
標準： 低嚴重性的問題或誤報需要記錄在案。
過程： 納入定期維護活動。
例：未使用選用功能中的拒絕服務攻擊。

建立安全錯誤欄

安全錯誤列定義 了必須滿足的最低安全標準：

完成準則的定義

安全性錯誤列範例：

Security Bug Bar:
  Blocking Issues (Must Fix Before Release):
    - No critical severity vulnerabilities
    - No high severity vulnerabilities with public exploits
    - No vulnerabilities actively exploited in the wild
    - No strong copyleft licenses (GPL, AGPL) in proprietary code
    - No secrets in source code or container images

  Non-Blocking Issues (Track and Plan):
    - High severity without public exploits (90-day remediation plan)
    - Medium severity vulnerabilities (next minor release)
    - License issues requiring legal review (document plan)

  Informational (Monitor):
    - Low severity vulnerabilities
    - Informational security findings
    - Code quality issues

實施原則

Azure Pipelines 品質閘道：

- task: WhiteSource@21
  inputs:
    cwd: "$(System.DefaultWorkingDirectory)"
    projectName: "$(Build.Repository.Name)"
    checkPolicies: true
    failBuildOnPolicyViolation: true
  displayName: "Enforce security bug bar"

- script: |
    # Custom policy check script
    if [ $(jq '.vulnerabilities.critical' scan-results.json) -gt 0 ]; then
      echo "##vso[task.logissue type=error]Critical vulnerabilities detected"
      echo "##vso[task.complete result=Failed;]Failed security bug bar"
      exit 1
    fi
  displayName: "Validate security bug bar compliance"

弱點分類工作流程

系統分類確保高效的漏洞管理：

分類程序

第 1 步：自動過濾：

掃描器工具： 按嚴重性自動過濾漏洞。
可達性分析： 從分級佇列中移除無法連線的弱點。
已知的誤報： 自動抑制先前識別的誤報。

第 2 步：初步評估：

嚴重性審查： 驗證您環境的 CVSS 分數準確性。
可利用性檢查： 判斷漏洞利用可用性和正在被利用。
資產識別： 識別哪些應用程式和系統受到影響。

第三步：風險評估：

業務影響： 評估成功利用的潛在業務影響。
曝光分析： 判斷網路暴露和受攻擊面。
補償控制： 識別現有的緩解措施，降低風險。

第 4 步：優先級：

指派優先順序： 使用優先順序矩陣來指派補救優先順序。
設定截止日期： 根據 SLA 指派補救期限。
指派擁有者： 指定負責補救的團隊。

第 5 步：修復追蹤：

建立票證：在追蹤系統中產生工作項目 (Jira、Azure Boards)。
進度監控： 根據截止日期追蹤補救進度。
驗證： 透過重新掃描來驗證修復成功。

分級會議步調

每週安全檢視：

參與者： 安全團隊、開發主管、營運代表。
議程： 檢閱新的高/關鍵發現、追蹤補救進度、調整優先順序。
所需時間： 30-60 分鐘。

每月漏洞審查：

參與者： 安全領導、工程管理、合規團隊。
議程： 審查趨勢、調整政策、評估整體安全狀況。
所需時間： 60-90 分鐘。

指標和報告

追蹤漏洞管理有效性：

重要計量

弱點指標：

平均檢測時間（MTTD）： 從漏洞披露到系統檢測的時間。
平均補救時間（MTTR）： 從偵測到成功補救的時間。
漏洞密度： 每個應用程式或程式碼行的弱點數目。
補救率： 在 SLA 內修復的弱點百分比。

趨勢指標：

開啟弱點計數： 依嚴重性劃分的未解決弱點趨勢計數。
新的與已解決的： 比較新偵測到和修復的弱點。
SLA 合規性： 在定義的 SLA 內修復的弱點百分比。
誤報率： 確定為誤報的發現百分比。

儀表板範例

漏洞管理儀表板：

Critical Vulnerabilities: 0 (Target: 0)
High Vulnerabilities: 3 (Target: < 10)
Medium Vulnerabilities: 47 (Target: < 100)
Low Vulnerabilities: 132 (Tracking only)

Mean Time to Remediate:
- Critical: 18 hours ✓
- High: 6 days ✓
- Medium: 21 days ✓

Remediation Progress:
- P0 (Emergency): 0 overdue
- P1 (Critical): 1 due in 3 days
- P2 (High): 5 due in next 30 days
- P3 (Medium): 12 due in next 90 days

Trends (Last 90 Days):
- New vulnerabilities: 127
- Remediated: 138
- Net reduction: -11 ✓

備註

如需服務等級協定（SLA）和補救時間表的詳細資訊，請參閱 Azure 服務等級協定。

有效的漏洞警報解釋和優先級排序將壓倒性的掃描器輸出轉化為可操作的安全改進。透過了解嚴重性分數、評估可利用性、管理誤報以及實施系統優先順序，團隊將修復工作重點放在構成實際風險的漏洞上，而不是追蹤每個警報。這種基於風險的方法可實現可持續的安全計劃，保護應用程序，而不會讓開發團隊因噪音而不堪重負。

意見反應

此頁面對您有幫助嗎？