相依套件
可達性分析
可達性分析會檢查您的程式碼是否真的能呼叫相依套件中有漏洞的函式。一個套件可能含有您的應用程式從未觸及的缺陷，可達性分析會將這類發現排到後面，讓團隊專注處理可被利用的漏洞。
更新日期
為什麼需要它
SCA 掃描會將套件版本與資安公告比對。它知道某個版本含有缺陷，卻不知道您的應用程式是否使用到有缺陷的部分。一個擁有數百個函式、其中只有一個解析器有漏洞的函式庫，無論您是否呼叫該解析器，都會以相同方式被回報；在龐大的相依關係樹中，這些累積起來就成了沒人處理得完的待辦清單。
可達性分析如何運作
- 找出有漏洞的程式碼。工具必須知道漏洞位於哪個函式。資安公告往往沒有說明，因此廠商會自行維護相關資料。
- 建立呼叫圖。它會對應出哪些函式呼叫了哪些函式，從您的程式碼一路延伸到相依套件。
- 尋找路徑。如果有一條呼叫鏈從您的程式碼通往有漏洞的函式，該發現就是可達的；若沒有，則標記為不可達並降低排序。
可達性的層級
| 層級 | 回答的問題 | 取捨 |
|---|---|---|
| 相依套件 | 套件是否有被匯入？ | 成本低，但只能排除未使用的相依套件 |
| 函式 | 是否有呼叫路徑能抵達有漏洞的函式？ | 最常見的目標，需要呼叫圖以及以函式為單位的漏洞資料 |
| 執行階段 | 這段程式碼是否曾在正式環境中載入或執行？ | 佐證資料來自實際流量，但僅涵蓋觀察期間有執行的部分 |
實際的漏洞利用需要的不只是一條路徑。輸入必須以能觸發缺陷的形式抵達該函式，而很少有工具能判斷這一點。
可達性分析的不足之處
- 不可達不代表安全。它只表示工具沒有找到路徑。反射、動態匯入與外掛程式載入都可能產生靜態分析看不到的路徑。
- 語言支援程度不一。靜態編譯語言比動態語言更容易追蹤，而各工具對哪些生態系提供函式層級分析也不盡相同。
- 漏洞資料並不完整。如果沒有人將資安公告對應到函式，工具就無從找起。
- 結果會隨程式碼改變。今天不可達的發現，在下一次版本發布後可能就變得可達，因此需要重新檢查。
- 它只能為已識別的項目排序。掃描器從未找到的元件無法被分析。若沒有完整的資產清冊，可達性分析只能整理局部的樣貌。
如何安全地運用
- 用它來排定工作順序，而不是用來排除工作。先修正可達的發現，其餘的排入時程，而不是直接關閉。
- 不要讓它凌駕於遭積極利用的事實之上。列於 CISA 的 KEV 目錄或 EPSS 分數偏高的發現，即使被標記為不可達，也值得由人做出判斷。
- 對面向網際網路的服務格外謹慎。在攻擊者能直接觸及您的地方，判斷錯誤的代價最高。
- 記錄判斷理由。如果您判定某項發現不適用，VEX 聲明能保存這項決定，並向您的客戶說明原因。
關於可達性如何與嚴重程度、漏洞利用資料及業務脈絡搭配，請參閱 如何排定漏洞優先順序。
哪些工具提供可達性分析？
許多商用 SCA 工具都有提供，包括 Snyk、Endor Labs、Mend、Checkmarx、Semgrep 與 Aikido，且分析深度依語言而異。Go 的 govulncheck 是針對單一生態系的免費範例。各工具的涵蓋範圍請參閱
最佳 SCA 工具比較。
CRACI 的定位
CRACI 不提供可達性分析。它處理的是更前面的一步：先掌握建置中到底有哪些內容。CRACI 是 GitHub Actions 執行器，會記錄每個作業擷取的每一個套件，包括鎖定檔（lockfile）掃描器遺漏的隱藏相依套件，並在新漏洞公布時，持續重新評估已出貨版本的 SBOM。如果可達性是您的首要考量，請在 CRACI 之外搭配專門的工具。請參閱 CRACI 如何與您的 SCA 工具搭配。
可達性分析：常見問題
SCA 中的可達性分析是什麼？
它會檢查您的程式碼是否真的能呼叫相依套件中有漏洞的函式，讓無法從您的程式碼抵達的發現能降低排序。
可達性分析準確嗎？
它很有用，但不是證明。可達的發現代表確實存在路徑，而不可達只表示工具沒有找到路徑。反射、動態載入與漏洞資料的缺口，都可能讓路徑被隱藏。
可以忽略不可達的漏洞嗎？
不要直接忽略。將它們排在可達的發現之後，在程式碼變更後重新檢查，並特別留意任何遭積極利用或在面向網際網路的服務中執行的項目。
可達性與可利用性有什麼不同？
可達性問的是程式碼能否抵達有漏洞的函式；可利用性問的是攻擊者能否利用這條路徑造成危害。一個缺陷可能是可達的，但在您的環境中仍無法被利用。
可達性分析能減少警示嗎？
可以，這正是它的主要目的。減少多少則取決於語言、工具，以及您的程式碼使用了每個相依套件的多少部分。