security-review

Security Review

一個 AI 驅動的安全掃描器，能像人類安全研究人員一樣推理你的程式碼庫——追蹤資料流、理解元件互動，並捕捉模式比對工具遺漏的漏洞。

何時使用此技能

當請求涉及以下情況時，使用此技能：

• 掃描程式碼庫或檔案以尋找安全漏洞
• 執行安全審查或漏洞檢查
• 檢查 SQL 注入、XSS、命令注入或其他注入缺陷
• 尋找程式碼中暴露的 API 金鑰、硬編碼密碼或憑證
• 稽核依賴項目以找出已知 CVE
• 審查驗證、授權或存取控制邏輯
• 偵測不安全的加密或弱隨機性
• 執行資料流分析，追蹤使用者輸入到危險接收點
• 任何像是「我的程式碼安全嗎？」、「掃描此檔案」或「檢查我的儲存庫是否有漏洞」的請求措辭
• 執行 /security-review 或 /security-review <path>

此技能的運作方式

與傳統的靜態分析工具不同，此技能：

1. 像安全研究人員一樣閱讀程式碼——理解上下文、意圖和資料流
2. 跨檔案追蹤——追蹤使用者輸入如何在你的應用程式中移動
3. 自我驗證發現——重新檢查每個結果以過濾誤報
4. 分配嚴重性等級——CRITICAL / HIGH / MEDIUM / LOW / INFO
5. 提出針對性的修補程式——每個發現都包含具體的修復方案
6. 需要人工批准——不會自動套用任何內容，你總是先審查

執行工作流程

每次依序執行以下步驟：

步驟 1 — 範圍界定

決定要掃描的範圍：

• 如果提供了路徑（/security-review src/auth/），僅掃描該範圍
• 如果未提供路徑，從根目錄開始掃描整個專案
• 識別使用的語言和框架（檢查 package.json、requirements.txt、go.mod、Cargo.toml、pom.xml、Gemfile、composer.json 等）
• 讀取 references/language-patterns.md 以載入語言特定的漏洞模式

步驟 2 — 依賴稽核

在掃描原始碼之前，先稽核依賴項目（快速取得成果）：

• Node.js：檢查 package.json + package-lock.json 以找出已知的易受攻擊套件
• Python：檢查 requirements.txt / pyproject.toml / Pipfile
• Java：檢查 pom.xml / build.gradle
• Ruby：檢查 Gemfile.lock
• Rust：檢查 Cargo.toml
• Go：檢查 go.sum
• 標記具有已知 CVE、已棄用的加密庫或可疑的舊固定版本的套件
• 讀取 references/vulnerable-packages.md 以取得精選監控清單

步驟 3 — 密碼與暴露掃描

掃描所有檔案（包括設定檔、環境變數檔、CI/CD、Dockerfile、IaC）以找出：

• 硬編碼的 API 金鑰、令牌、密碼、私鑰
• 意外提交的 .env 檔案
• 註解或除錯日誌中的密碼
• 雲端憑證（AWS、GCP、Azure、Stripe、Twilio 等）
• 內嵌憑證的資料庫連線字串
• 讀取 references/secret-patterns.md 以取得要套用的正則表達式模式和熵啟發式規則

步驟 4 — 漏洞深度掃描

這是核心掃描。推理程式碼——不要只是模式比對。
讀取 references/vuln-categories.md 以取得每個類別的完整詳細資訊。

注入缺陷

• SQL 注入：使用字串插值的原始查詢、ORM 誤用、二階 SQLi
• XSS：未跳脫的輸出、dangerouslySetInnerHTML、innerHTML、模板注入
• 命令注入：使用使用者輸入的 exec/spawn/system
• LDAP、XPath、Header、Log 注入

驗證與存取控制

• 敏感端點缺少驗證
• 損壞的物件層級授權（BOLA/IDOR）
• JWT 弱點（alg:none、弱密碼、無過期驗證）
• Session 固定、缺少 CSRF 保護
• 權限提升路徑
• Mass assignment / 參數污染

資料處理

• 日誌、錯誤訊息或 API 回應中的敏感資料
• 缺少靜態或傳輸中加密
• 不安全的反序列化
• 路徑遍歷 / 目錄遍歷
• XXE（XML 外部實體）處理
• SSRF（伺服器端請求偽造）

加密

• 使用 MD5、SHA1、DES 進行安全目的
• 硬編碼的 IV 或鹽值
• 弱隨機數生成（使用 Math.random() 生成令牌）
• 缺少 TLS 憑證驗證

業務邏輯

• 競爭條件（TOCTOU）
• 財務計算中的整數溢位
• 敏感端點缺少速率限制
• 可預測的資源識別碼

步驟 5 — 跨檔案資料流分析

在逐檔案掃描之後，執行整體審查：

• 從入口點（HTTP 參數、標頭、請求主體、檔案上傳）追蹤使用者控制的輸入，一直到接收點（資料庫查詢、exec 呼叫、HTML 輸出、檔案寫入）
• 識別僅在同時查看多個檔案時才會出現的漏洞
• 檢查服務或模組之間不安全的信任邊界

步驟 6 — 自我驗證階段

對於每個發現：

1. 以全新的視角重新閱讀相關程式碼
2. 問：「這真的可以被利用嗎？還是我遺漏了某個消毒處理？」
3. 檢查框架或中介軟體是否已在上游處理此問題
4. 降級或丟棄非真正漏洞的發現
5. 分配最終嚴重性：CRITICAL / HIGH / MEDIUM / LOW / INFO

步驟 7 — 產生安全報告

以 references/report-format.md 中定義的格式輸出完整報告。

步驟 8 — 提出修補程式

對於每個 CRITICAL 和 HIGH 的發現，產生具體的修補程式：

• 顯示易受攻擊的程式碼（之前）
• 顯示修復後的程式碼（之後）
• 解釋變更的內容和原因
• 保留原始程式碼風格、變數名稱和結構
• 在行內添加註解說明修復原因

明確說明：「在套用每個修補程式前請先審查。尚未有任何變更。」

嚴重性指南

嚴重性	意義	範例
🔴 CRITICAL	立即利用風險，很可能導致資料外洩	SQLi、RCE、驗證繞過
🟠 HIGH	嚴重漏洞，存在利用路徑	XSS、IDOR、硬編碼密碼
🟡 MEDIUM	在特定條件或鏈結下可被利用	CSRF、開放重定向、弱加密
🔵 LOW	違反最佳實踐，直接風險低	詳細錯誤訊息、缺少標頭
⚪ INFO	值得注意的觀察，非漏洞	過時的依賴（無 CVE）

輸出規則

• 始終先產生發現摘要表格（按嚴重性計數）
• 絕不自動套用任何修補程式——僅提供修補程式供人工審查
• 始終為每個發現包含信心評級（高 / 中 / 低）
• 按類別分組發現，而非按檔案
• 具體說明——包含檔案路徑、行號和確切的易受攻擊程式碼片段
• 用白話文解釋風險——攻擊者可以利用這個做什麼？
• 如果程式碼庫是乾淨的，清楚說明：「未發現漏洞」以及掃描了哪些內容

參考檔案

如需詳細的偵測指南，請視需要載入以下參考檔案：

• references/vuln-categories.md — 每個漏洞類別的深度參考，包含偵測訊號、安全模式和權限提升檢查器
  • 搜尋模式：SQL injection、XSS、command injection、SSRF、BOLA、IDOR、JWT、CSRF、secrets、cryptography、race condition、path traversal
• references/secret-patterns.md — 正則表達式模式、基於熵的偵測和 CI/CD 密碼風險
  • 搜尋模式：API key、token、private key、connection string、entropy、.env、GitHub Actions、Docker、Terraform
• references/language-patterns.md — JavaScript、Python、Java、PHP、Go、Ruby 和 Rust 的框架特定漏洞模式
  • 搜尋模式：Express、React、Next.js、Django、Flask、FastAPI、Spring Boot、PHP、Go、Rails、Rust
• references/vulnerable-packages.md — npm、pip、Maven、Rubygems、Cargo 和 Go 模組的精選 CVE 監控清單
  • 搜尋模式：lodash、axios、jsonwebtoken、Pillow、log4j、nokogiri、CVE
• references/report-format.md — 安全報告的結構化輸出模板，包含發現卡片、依賴稽核、密碼掃描和修補程式提案格式
  • 搜尋模式：report、format、template、finding、patch、summary、confidence