cpg-analysis

cpg-analysis 技能概覽

cpg-analysis 是一種深度程式碼分析 skill，適合一般快速掃過 repository 不夠用的情境。它能幫你用 Joern CPG 和 CodeQL 推理控制流程、資料流、程式依賴、taint path，以及安全性問題。如果你在做安全審查、追蹤跨函式的 bug，或是要證明輸入如何一路到達 sink，cpg-analysis 就是該用的 skill。

最適合的情境：安全稽核與 flow 追蹤

cpg-analysis 最適合用在 Security Audit 工作，尤其是你需要回答像是「這個輸入能不能到達危險的 sink？」或「從 source 到 sink，跨多個檔案有哪些路徑？」這類問題時。它最有價值的場景，是需要有證據支撐的分析，而不是表層的程式碼說明。

與其他方法不同之處

和一般泛用型 prompt 不同，cpg-analysis 是圍繞圖形化推理設計的：AST 看結構、CFG 看執行順序、data-flow graph 看傳播路徑。實際差異在於，它對安全與正確性問題的可追溯性更好，尤其是在大型 codebase 裡，單靠 grep 或摘要很容易漏掉真正的路徑。

什麼情況下值得安裝

當你預期會反覆處理深度靜態分析、taint tracking，或漏洞挖掘時，就很值得安裝 cpg-analysis。若你只需要快速導覽程式碼，tier-1 記憶工具通常就夠了，而且執行成本更低。

如何使用 cpg-analysis 技能

安裝 cpg-analysis 並確認執行環境

先用 repo 的 skill manager 安裝 cpg-analysis skill，接著確認你要走的路徑所需 runtime 是否齊全。以 Joern 為主的流程通常需要 Docker 和 JVM；以 CodeQL 為主的流程則需要 CodeQL CLI。若你的本機或環境無法執行這些工具，不管 prompt 寫得多好，這個 skill 的能力都會受限。

先從正確的檔案開始

先讀 SKILL.md，再看描述 tier 選擇、何時使用 Joern，以及關鍵 MCP tools 的段落。這些內容會先告訴你該選哪條分析路徑，再去花時間產生 query。如果 skill 提到特定的 repository tree，請先照那張 map 走，不要只靠記憶猜。

把模糊需求改成可用的 prompt

cpg-analysis 最好的用法，是先有明確的分析目標，而不是只說「分析這個 repo」。請包含：

• repository 或子目錄
• 已知的語言或 framework
• 安全問題或 bug 假設
• 你關心的 source、sink 或功能
• 任何限制，例如「不要執行 runtime」或「聚焦 auth flow」

範例 prompt 形式：
Use cpg-analysis to trace whether user-controlled input from the API reaches command execution in src/ without sanitization. Focus on interprocedural paths and show the key nodes and files.

採用分階段工作流程

一份好的 cpg-analysis 指南，通常最適合分兩步：先把相關範圍畫出來，再深入追路徑。先把範圍開得夠大，找出 entry point 和候選 sink，接著再縮小到真正涉及的函式或檔案。這種做法可以降低錯誤自信，也能讓輸出更貼近實際 data flow。

cpg-analysis 技能 FAQ

cpg-analysis 只適合安全工作嗎？

不只。安全性是最明確的適用場景，但這個 skill 也很適合用來挖 bug、推理執行路徑，以及理解值如何在複雜 codebase 中流動。只要問題依賴 control flow 或 data flow，而不是單純字串比對，它就特別有用。

每次都需要 Joern 和 CodeQL 嗎？

不一定。Joern 通常是以 CPG 做探索時的較佳第一選擇，而當你想做 interprocedural security queries 或找漏洞樣式時，CodeQL 會更強。請依問題選工具，不要預設兩個都跑。

cpg-analysis 適合新手嗎？

可以用，但前提是任務要夠具體。模糊的需求只會得到模糊的分析。如果你能指出檔案、輸入來源，以及有風險的 sink，cpg-analysis skill 就會變得好用很多。

什麼時候不該用 cpg-analysis？

當你只是需要查文件、做基本重構建議，或快速總結單一檔案時，就不必用 cpg-analysis。這是一個安裝成本較高的 skill，只有在分析深度足以合理化 graph-based tooling 時，才真正划算。

如何改進 cpg-analysis 技能

把分析目標縮小

最重要的改進，就是縮小範圍。「找安全問題」太寬了；「追蹤 routes/ 裡的 request params 是否能到達 exec 或 SQL query construction」就明確得多。清楚定義 source 和 sink，能讓 cpg-analysis 的輸出更可行，也能減少無謂的 traversal。

把關鍵限制說清楚

如果你的環境不能用 Docker、codebase 是 polyglot，或你只想做 static analysis，請一開始就講明。限制條件會改變可行的工作流程，也能避免 skill 推出你根本不能執行的路徑。對 cpg-analysis 的安裝決策來說，這往往就是有用和沒用的差別。

要求證據，不要只要結論

在反覆調整時，請要求它把鏈條說清楚：entry point、中間函式、graph nodes，以及最終 sink。這樣才能逼出 cpg-analysis 用在 Security Audit 時真正重要的推理過程。如果第一輪太寬，就改用更精準的檔案範圍或下一步想看的 query 類型來收斂。

用更好的假設重新跑一次

如果第一次結果雜訊太多，不要只叫它再做一次泛泛的分析，而是先把假設修正得更好。例如，把「找 auth 問題」改成「追蹤從 router 到敏感 handler 的 unauthenticated access，排除 test code 和 mocks」。更強的假設，才是取得高訊噪比 cpg-analysis 使用結果的最快方法。