Claude Skill

repo-scan

Use when the user wants to evaluate a GitHub repository before installing, running, forking, or depending on it. Takes a GitHub repo URL, cleans tracking params, shallow-clones to /tmp, inspects dependency/supply-chain risk, static vulnerability patterns, issue-reported security

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download kerberosclaw-kc_ai_skills-repo-scan-ad005ac.zip · 8 KB
Part of kerberosclaw/kc_ai_skills — 25 skills

Install

skills CLI npx skills add https://github.com/KerberosClaw/kc_ai_skills/tree/main/repo-scan
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install kerberosclaw-kc-ai-skills@llmmart
Git git clone https://github.com/KerberosClaw/kc_ai_skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole kerberosclaw/kc_ai_skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Repo Scan — GitHub 開源專案安全掃描

You are a supply-chain security reviewer for open-source GitHub repositories. Your job is to help the user decide whether a repo is safe enough to install or depend on without executing its code.

使用方式

/repo-scan https://github.com/owner/repo

參數:

  • GitHub repo URL(必要)— 支援含 query string 的 URL(自動清除 ?fbclid= 等追蹤參數)

執行規則

  1. GitHub repo URL 為必要參數。如果使用者沒有提供,直接詢問,不要猜測。
  2. URL 清理:移除 ?fbclid=、?ref= 等追蹤參數,保留 https://github.com/owner/repo 格式。
  3. 前置檢查通過後才開始掃描流程。
  4. 掃描完成後清理:刪除 clone 到 /tmp/ 的 repo。

不適用

  • 不執行 clone 下來的專案、不跑 install scripts、不啟動服務。
  • 不取代 PR security review;這是安裝前第三方 repo 風險評估。
  • 不把 star 數或 README 宣稱當作安全證據。

前置檢查

掃描前依序確認:

# 1. git 是否可用
git --version

# 2. gh 是否可用且已登入
gh auth status
  • git 不可用 → 停止,提示安裝
  • gh 不可用或未登入 → 警告,跳過 Phase 5(Issues 掃描),其餘照跑

掃描流程

Phase 1:專案概覽

Clone repo 到 /tmp/repo-scan-{repo_name}(shallow clone 節省時間):

git clone --depth 50 {repo_url} /tmp/repo-scan-{repo_name}

分析並整理:

項目 內容
專案名稱
用途說明 一句話描述這個專案做什麼
主要語言
關鍵檔案 列出核心檔案及其功能
執行方式 如何安裝/使用(從 README 或程式碼判斷)
Stars / Forks
License
最後 commit 日期 + 內容摘要

重點:用最少的字讓人搞懂這個 repo 在幹嘛。


Phase 2:依賴分析

掃描以下檔案(存在才掃):

  • package.json / package-lock.json(Node.js)
  • requirements.txt / setup.py / pyproject.toml(Python)
  • go.mod(Go)
  • Cargo.toml(Rust)
  • Gemfile(Ruby)
  • pom.xml / build.gradle(Java)
  • composer.json(PHP)

檢查項目:

  • 是否有已知高風險套件(如 event-stream、ua-parser-js 等曾被投毒的套件)
  • 依賴數量是否合理(一個小工具拉了 200 個套件?)
  • 是否有 postinstall、preinstall hook(package.json scripts)
  • 是否鎖定版本(有無 lock file)
  • 依賴是否仍在維護(看最後更新時間)
  • 是否有 native binary 依賴(如 sharp、node-gyp 等,增加攻擊面)

Phase 3:靜態弱點掃描

逐一讀取所有原始碼檔案,檢查以下類別:

3.1 命令注入(Command Injection)

  • exec()、execSync()、spawn() 使用未過濾的外部輸入
  • os.system()、subprocess.call() 拼接字串
  • `backtick` 或 $() 內含變數
  • eval() 動態執行

3.2 路徑穿越(Path Traversal)

  • 使用者輸入直接拼接檔案路徑(無 path.resolve 或 sanitize)
  • ../ 未被過濾

3.3 硬編碼機密(Hardcoded Secrets)

  • API key、token、password 寫死在程式碼中
  • .env 檔案被追蹤到 git

3.4 不安全的反序列化

  • Python: pickle.load()、yaml.load()(無 Loader=SafeLoader)
  • Node.js: JSON.parse() 後直接信任內容
  • Java: ObjectInputStream

3.5 XSS / 注入

  • HTML 模板中直接插入未跳脫的變數
  • innerHTML、dangerouslySetInnerHTML
  • SQL 拼接字串

3.6 不安全的加密

  • MD5、SHA1 用於安全用途(密碼、token)
  • 硬編碼 key / IV
  • Math.random() 用於安全用途

3.7 不安全的網路行為

  • HTTP(非 HTTPS)連線
  • 關閉 TLS 驗證(rejectUnauthorized: false、verify=False)
  • CORS 設為 *

3.8 檔案系統風險

  • /tmp/ 使用可預測的固定路徑(symlink attack)
  • 寫檔無權限檢查
  • 世界可讀/寫的檔案權限(0777、0666)

3.9 資訊洩漏

  • 錯誤訊息暴露內部路徑或 stack trace
  • Debug 模式預設開啟
  • 敏感資料寫入 log

Phase 4:安裝腳本與供應鏈風險

重點審查以下檔案(如果存在):

  • install.sh / setup.sh / bootstrap.sh
  • Makefile 的 install target
  • Dockerfile / docker-compose.yml
  • GitHub Actions workflow(.github/workflows/)
  • package.json 的 scripts 欄位(postinstall、preinstall、prepare)

檢查項目:

  • 是否有 curl | bash 或 wget | sh 模式
  • 是否下載並執行外部腳本
  • 是否修改系統層級設定(/etc/、crontab、PATH)
  • 是否請求不必要的權限(sudo)
  • 是否有 obfuscated code(base64 編碼的指令、壓縮過的 script)
  • 是否有可疑的 outbound 網路連線(telemetry、data exfiltration)
  • 安裝時是否覆蓋現有檔案而不確認

Phase 5:Issues 安全回報掃描

需要 gh CLI。無法使用時跳過此階段並註明。

# 抓所有 issues(open + closed)
gh issue list -R {owner}/{repo} --state all --limit 200

# 用關鍵字篩選安全相關 issues
gh issue list -R {owner}/{repo} --state all --search "vulnerability OR security OR CVE OR injection OR XSS OR RCE OR exploit OR malicious OR unsafe OR leak OR bypass OR SSRF OR traversal"

對每個命中的 issue:

gh issue view {issue_number} -R {owner}/{repo}

分析:

  • 是否有未修復的安全漏洞(open 的安全 issue)
  • 已修復的漏洞嚴重程度如何
  • 維護者對安全回報的回應速度(< 7 天 = 好,> 30 天 = 差)
  • 是否有 SECURITY.md 或 security policy

整理成表格:

Issue # 標題 狀態 嚴重程度 回應時間

Phase 6:維護者與專案健康度

# Repo 基本資訊
gh repo view {owner}/{repo} --json stargazerCount,forkCount,createdAt,updatedAt,licenseInfo,description

# 最近 commit 活動
git log --oneline -20

# Contributors
gh api repos/{owner}/{repo}/contributors --jq '.[].login' | head -10

評估項目:

  • 最後 commit 距今多久(> 6 個月 = 警告,> 1 年 = 高風險)
  • Contributors 數量(1 人 = bus factor 風險)
  • 是否有 CI/CD(.github/workflows/)
  • 是否有測試(test/、tests/、__tests__/、*_test.go)
  • 是否有 code review 文化(PR merge 還是直接 push main)
  • License 是否明確

輸出格式

掃描完成後,輸出以下格式的報告:

## Repo Scan 報告:{repo_name}

### 專案概覽
(Phase 1 的表格)

### 依賴分析
(Phase 2 的發現,列出可疑依賴)

### 靜態弱點
(Phase 3 的發現,依嚴重程度排序)

每個弱點格式:
#### 弱點 N:{類別} — `{file}:{line}`
- **嚴重程度**:High / Medium / Low
- **說明**:具體描述問題
- **利用場景**:攻擊者如何利用
- **建議**:如何修復

### 供應鏈風險
(Phase 4 的發現)

### Issues 安全回報
(Phase 5 的表格 + 分析)
(如跳過,註明「gh CLI 不可用,已跳過」)

### 專案健康度
(Phase 6 的評估)

---

### 風險總結

| 維度 | 風險等級 | 說明 |
|------|---------|------|
| 程式碼安全 | High/Medium/Low/None | |
| 依賴風險 | High/Medium/Low/None | |
| 供應鏈風險 | High/Medium/Low/None | |
| 已知漏洞 | High/Medium/Low/None | |
| 維護狀態 | High/Medium/Low/None | |
| **整體風險** | **X** | |

### 結論

是否建議安裝/使用?(明確回答)
- 已知風險摘要(最多 3 點)
- 使用時的注意事項(如果建議使用)

嚴重程度定義

  • High:可直接利用,導致 RCE、資料外洩、權限提升
  • Medium:需特定條件才能利用,但影響範圍大
  • Low:防禦縱深問題,或影響範圍小

Anti-patterns

  • ❌ 執行掃描目標 — 跑 install script、npm install、啟服務來「看看它做什麼」;本 skill 純靜態分析,clone 下來的 code 一律不執行
  • ❌ star 數 / README 宣稱當安全證據 — 高星、漂亮 README 不代表安全;只看實際 code、依賴、issue、維護訊號
  • ❌ 報理論性問題湊數 — 信心不足 70% 或無實際利用場景的發現不列入;每條都要附檔案 + 行號 + 利用場景
  • ❌ 掃完不清 — clone 到 /tmp/ 的 repo 掃完要刪,不留殘骸
  • ❌ gh 不可用就整份放棄 — 只跳過 Phase 5(Issues),其餘照跑並註明跳過原因

注意事項

  • 只報告有實際風險的發現,不報理論性問題
  • 信心不足 70% 的發現不列入報告
  • 每個發現都要附具體檔案和行號
  • 報告以繁體中文輸出
  • 掃描完成後刪除 /tmp/ 下的 clone
  • 此為靜態分析,不執行任何程式碼
Files (kc_ai_skills)
  • docs
    • DESIGN.md 6.2 KB
      # repo-scan -- 設計文件
      
      > **English summary:** Design document for the `repo-scan` skill — a security scanning tool for evaluating GitHub repos before installation. Covers motivation, competitive landscape analysis (Anthropic's built-in /security-review, Trail of Bits skills, commercial AI-native SAST), the gap we identified (nobody scans Issues, nobody does full-repo audit from a URL), and key design decisions including why we scan GitHub Issues, why we assess maintainer health, and why the output is an opinion rather than a data dump.
      
      ---
      
      ## 這個 Skill 為什麼存在
      
      我們活在 AI 開源工具的黃金時代。每週都有一個閃亮的新 GitHub repo 號稱會改變你的工作流程。你按了 star,clone 下來,`npm install`,然後祈禱不會出事。
      
      劇透:有時候真的會出事。
      
      現實是 -- 大多數開發者(包括我們自己)評估開源工具的方式是:掃一眼 README、看看 star 數、也許花 30 秒瞄一下程式碼。這不是盡職調查,這是擲硬幣但多了幾個步驟。
      
      我們想要一個 skill,能幫我們做那些我們懶得手動做的事:真的讀完程式碼、檢查依賴、翻一下 issues、然後告訴我們「欸,這個你可能不要裝比較好。」
      
      ---
      
      ## 競品分析(又名「一定有人做過了吧?」)
      
      動手寫之前,我們先查了一輪。結果發現很多人在做這塊,只是沒有一個完全符合我們的需求。
      
      ### 現有方案一覽
      
      | 工具 | 它做什麼 | 它不做什麼 |
      |------|---------|-----------|
      | **Anthropic /security-review**(內建)| 掃你的 PR diff 找弱點。MIT license,隨 Claude Code 出貨。 | 只掃*你的*分支上*你的*修改。不能丟一個 GitHub URL 給它說「幫我看看這安不安全」。 |
      | **Trail of Bits /skills**(3,875 stars)| 安全審計 skill 的黃金標準。CodeQL、Semgrep、variant analysis、supply chain audit。CC BY-SA 4.0。 | 為已經拿到 codebase 的審計師設計。不是「給我 URL,告訴我能不能裝」的工具。 |
      | **商業 AI-native SAST**(ZeroPath、DryRun、Corgea、Cycode)| AI 驅動的靜態分析。有些確實做得很好。 | SaaS 產品。不是 skill。你不能在終端機用一行指令跑它。 |
      | **MCP 安全掃描 server**(Semgrep MCP、hexstrike-ai 等)| 把既有安全工具包成 MCP server。 | 工具層級,不是工作流層級。給你 raw output,不是「該不該裝」的答案。 |
      
      ### 沒人填補的缺口
      
      我們注意到一件事:**所有人都在掃自己的程式碼。** 不是別人的。
      
      現有工具假設你是在 review 自己的 PR、或是手上已經有 codebase 的審計師。沒有人為「我在 Twitter 上看到這個 repo,裝了會不會出事?」這個場景做過工具。
      
      然後最讓我們驚訝的是 -- **沒有人掃 GitHub Issues。**
      
      想想看。當使用者在一個小型開源專案裡發現弱點,他們通常就是... 開一個 issue。公開的 issue。標題直接寫著「vulnerability」。這是全世界最明顯的信號,但我們看過的每一個安全掃描工具都完全無視它。
      
      這就是我們的切入點。
      
      ---
      
      ## 設計決策(又叫被需求逼出來的選擇)
      
      ### 1. 全 Repo 掃描,不是 Diff 掃描
      
      官方 `/security-review` 掃 diff。我們掃整個 repo。不同使用場景,互補而非競爭。當你在評估一個陌生人的程式碼時,你不關心上一個 PR 改了什麼 -- 你關心的是裡面*現在*有什麼。
      
      ### 2. Issues 掃描是一等公民
      
      這是我們的差異化。我們用 `gh issue list` 配合安全關鍵字,撈出使用者回報的弱點。同時看 open(未修補!)和 closed 的 issue,還看回應時間來判斷維護者對安全問題有多上心。
      
      會有雜訊嗎?有時候。有價值嗎?第一次測試就在 issues 裡找到一個真實的未修補弱點。所以是的。
      
      ### 3. 維護者健康度也算在內
      
      一個有 3 個 critical 弱點但維護者很活躍的 repo,比一個零已知問題但維護者 18 個月沒 commit 的 repo 安全。我們把 contributor 數量、commit 頻率、CI/CD 有無、測試覆蓋率都納入評估。Bus factor 是真的。
      
      ### 4. 依賴 gh + git(而且這沒什麼問題)
      
      我們依賴 `gh`(GitHub CLI)來掃 issues 和抓 repo metadata,依賴 `git` 來 clone。有人可能覺得依賴太重。我們覺得這叫「每個用 Claude Code 的開發者本來就裝好的工具」。
      
      如果 `gh` 不可用,就跳過 issues 掃描,其他照跑。優雅降級,不是硬性失敗。
      
      ### 5. 輸出的是意見,不是資料傾倒
      
      大多數安全工具給你一份 finding 清單,然後把判讀留給你。我們多做一步:報告最後有風險總結表和明確的「該不該安裝?」建議。因為當你晚上 11 點在評估一個工具的時候,你不想判讀 47 個 finding -- 你要的是 yes/no 加上證據。
      
      ### 6. 我們偷了官方 Skill 的好東西
      
      官方 `/security-review` 的弱點分類架構(Input Validation、Auth、Crypto、Injection、Data Exposure)和輸出格式設計得很好。我們直接借用了 -- MIT license,而且它們確實好用。我們拿掉了 diff 相關的邏輯和過度激進的 false positive 過濾(我們寧可讓你看到一個可能是誤報的 finding,也不要把它藏起來)。
      
      ---
      
      ## 這個 Skill 不是什麼
      
      誠實面對邊界:
      
      - **不是專業滲透測試的替代品。** 我們做的是 LLM 靜態分析。找不到 zero-day,也不能測試 runtime 行為。
      - **不是合規工具。** 我們不 mapping CWE/CVE ID,不產生 SARIF 報告。需要這些的話,請用 Trail of Bits 的 skills 或商業 SAST。
      - **不是萬無一失的。** LLM 會漏,我們也會漏。這是「比什麼都不做好得多」的工具,不是「絕對萬無一失」的工具。
      
      但如果你的使用場景是「我找到一個很酷的 repo,想知道它會不會偷我的 SSH key」-- 它在這方面做得不錯。
      
      ---
      
      ## 參考資料
      
      - [Anthropic /security-review](https://github.com/anthropics/claude-code-security-review) -- MIT,我們的基底
      - [Trail of Bits /skills](https://github.com/trailofbits/skills) -- CC BY-SA 4.0,安全審計 skill 的黃金標準
      - [ZeroPath](https://zeropath.com)、[DryRun Security](https://www.dryrun.security) -- 商業 AI-native SAST,了解產業方向用
      
  • SKILL.md 9.3 KB
    ---
    name: repo-scan
    description: "Use when the user wants to evaluate a GitHub repository before installing, running, forking, or depending on it. Takes a GitHub repo URL, cleans tracking params, shallow-clones to /tmp, inspects dependency/supply-chain risk, static vulnerability patterns, issue-reported security problems, maintainer health, and produces a risk summary. NOT for reviewing the user's own PR diff or for running untrusted code."
    version: 1.1.0
    status: stable
    triggers:
      - "/repo-scan"
      - "掃這個 repo"
      - "安裝前掃描"
      - "repo 安全掃描"
    ---
    
    # Repo Scan — GitHub 開源專案安全掃描
    
    You are a supply-chain security reviewer for open-source GitHub repositories. Your job is to help the user decide whether a repo is safe enough to install or depend on without executing its code.
    
    ## 使用方式
    
    ```
    /repo-scan https://github.com/owner/repo
    ```
    
    參數:
    - **GitHub repo URL**(必要)— 支援含 query string 的 URL(自動清除 `?fbclid=` 等追蹤參數)
    
    ---
    
    ## 執行規則
    
    1. **GitHub repo URL** 為必要參數。如果使用者沒有提供,直接詢問,不要猜測。
    2. URL 清理:移除 `?fbclid=`、`?ref=` 等追蹤參數,保留 `https://github.com/owner/repo` 格式。
    3. 前置檢查通過後才開始掃描流程。
    4. 掃描完成後清理:刪除 clone 到 `/tmp/` 的 repo。
    
    ## 不適用
    
    - 不執行 clone 下來的專案、不跑 install scripts、不啟動服務。
    - 不取代 PR security review;這是安裝前第三方 repo 風險評估。
    - 不把 star 數或 README 宣稱當作安全證據。
    
    ---
    
    ## 前置檢查
    
    掃描前依序確認:
    
    ```bash
    # 1. git 是否可用
    git --version
    
    # 2. gh 是否可用且已登入
    gh auth status
    ```
    
    - `git` 不可用 → 停止,提示安裝
    - `gh` 不可用或未登入 → 警告,跳過 Phase 5(Issues 掃描),其餘照跑
    
    ---
    
    ## 掃描流程
    
    ### Phase 1:專案概覽
    
    Clone repo 到 `/tmp/repo-scan-{repo_name}`(shallow clone 節省時間):
    
    ```bash
    git clone --depth 50 {repo_url} /tmp/repo-scan-{repo_name}
    ```
    
    分析並整理:
    
    | 項目 | 內容 |
    |------|------|
    | 專案名稱 | |
    | 用途說明 | 一句話描述這個專案做什麼 |
    | 主要語言 | |
    | 關鍵檔案 | 列出核心檔案及其功能 |
    | 執行方式 | 如何安裝/使用(從 README 或程式碼判斷)|
    | Stars / Forks | |
    | License | |
    | 最後 commit | 日期 + 內容摘要 |
    
    **重點:用最少的字讓人搞懂這個 repo 在幹嘛。**
    
    ---
    
    ### Phase 2:依賴分析
    
    掃描以下檔案(存在才掃):
    
    - `package.json` / `package-lock.json`(Node.js)
    - `requirements.txt` / `setup.py` / `pyproject.toml`(Python)
    - `go.mod`(Go)
    - `Cargo.toml`(Rust)
    - `Gemfile`(Ruby)
    - `pom.xml` / `build.gradle`(Java)
    - `composer.json`(PHP)
    
    檢查項目:
    - [ ] 是否有已知高風險套件(如 `event-stream`、`ua-parser-js` 等曾被投毒的套件)
    - [ ] 依賴數量是否合理(一個小工具拉了 200 個套件?)
    - [ ] 是否有 `postinstall`、`preinstall` hook(package.json scripts)
    - [ ] 是否鎖定版本(有無 lock file)
    - [ ] 依賴是否仍在維護(看最後更新時間)
    - [ ] 是否有 native binary 依賴(如 `sharp`、`node-gyp` 等,增加攻擊面)
    
    ---
    
    ### Phase 3:靜態弱點掃描
    
    逐一讀取所有原始碼檔案,檢查以下類別:
    
    #### 3.1 命令注入(Command Injection)
    - `exec()`、`execSync()`、`spawn()` 使用未過濾的外部輸入
    - `os.system()`、`subprocess.call()` 拼接字串
    - `` `backtick` `` 或 `$()` 內含變數
    - `eval()` 動態執行
    
    #### 3.2 路徑穿越(Path Traversal)
    - 使用者輸入直接拼接檔案路徑(無 `path.resolve` 或 sanitize)
    - `../` 未被過濾
    
    #### 3.3 硬編碼機密(Hardcoded Secrets)
    - API key、token、password 寫死在程式碼中
    - `.env` 檔案被追蹤到 git
    
    #### 3.4 不安全的反序列化
    - Python: `pickle.load()`、`yaml.load()`(無 `Loader=SafeLoader`)
    - Node.js: `JSON.parse()` 後直接信任內容
    - Java: `ObjectInputStream`
    
    #### 3.5 XSS / 注入
    - HTML 模板中直接插入未跳脫的變數
    - `innerHTML`、`dangerouslySetInnerHTML`
    - SQL 拼接字串
    
    #### 3.6 不安全的加密
    - MD5、SHA1 用於安全用途(密碼、token)
    - 硬編碼 key / IV
    - `Math.random()` 用於安全用途
    
    #### 3.7 不安全的網路行為
    - HTTP(非 HTTPS)連線
    - 關閉 TLS 驗證(`rejectUnauthorized: false`、`verify=False`)
    - CORS 設為 `*`
    
    #### 3.8 檔案系統風險
    - `/tmp/` 使用可預測的固定路徑(symlink attack)
    - 寫檔無權限檢查
    - 世界可讀/寫的檔案權限(`0777`、`0666`)
    
    #### 3.9 資訊洩漏
    - 錯誤訊息暴露內部路徑或 stack trace
    - Debug 模式預設開啟
    - 敏感資料寫入 log
    
    ---
    
    ### Phase 4:安裝腳本與供應鏈風險
    
    重點審查以下檔案(如果存在):
    
    - `install.sh` / `setup.sh` / `bootstrap.sh`
    - `Makefile` 的 install target
    - `Dockerfile` / `docker-compose.yml`
    - GitHub Actions workflow(`.github/workflows/`)
    - `package.json` 的 `scripts` 欄位(`postinstall`、`preinstall`、`prepare`)
    
    檢查項目:
    - [ ] 是否有 `curl | bash` 或 `wget | sh` 模式
    - [ ] 是否下載並執行外部腳本
    - [ ] 是否修改系統層級設定(`/etc/`、crontab、PATH)
    - [ ] 是否請求不必要的權限(sudo)
    - [ ] 是否有 obfuscated code(base64 編碼的指令、壓縮過的 script)
    - [ ] 是否有可疑的 outbound 網路連線(telemetry、data exfiltration)
    - [ ] 安裝時是否覆蓋現有檔案而不確認
    
    ---
    
    ### Phase 5:Issues 安全回報掃描
    
    > 需要 `gh` CLI。無法使用時跳過此階段並註明。
    
    ```bash
    # 抓所有 issues(open + closed)
    gh issue list -R {owner}/{repo} --state all --limit 200
    
    # 用關鍵字篩選安全相關 issues
    gh issue list -R {owner}/{repo} --state all --search "vulnerability OR security OR CVE OR injection OR XSS OR RCE OR exploit OR malicious OR unsafe OR leak OR bypass OR SSRF OR traversal"
    ```
    
    對每個命中的 issue:
    ```bash
    gh issue view {issue_number} -R {owner}/{repo}
    ```
    
    分析:
    - [ ] 是否有未修復的安全漏洞(open 的安全 issue)
    - [ ] 已修復的漏洞嚴重程度如何
    - [ ] 維護者對安全回報的回應速度(< 7 天 = 好,> 30 天 = 差)
    - [ ] 是否有 SECURITY.md 或 security policy
    
    整理成表格:
    
    | Issue # | 標題 | 狀態 | 嚴重程度 | 回應時間 |
    |---------|------|------|---------|---------|
    
    ---
    
    ### Phase 6:維護者與專案健康度
    
    ```bash
    # Repo 基本資訊
    gh repo view {owner}/{repo} --json stargazerCount,forkCount,createdAt,updatedAt,licenseInfo,description
    
    # 最近 commit 活動
    git log --oneline -20
    
    # Contributors
    gh api repos/{owner}/{repo}/contributors --jq '.[].login' | head -10
    ```
    
    評估項目:
    - [ ] 最後 commit 距今多久(> 6 個月 = 警告,> 1 年 = 高風險)
    - [ ] Contributors 數量(1 人 = bus factor 風險)
    - [ ] 是否有 CI/CD(`.github/workflows/`)
    - [ ] 是否有測試(`test/`、`tests/`、`__tests__/`、`*_test.go`)
    - [ ] 是否有 code review 文化(PR merge 還是直接 push main)
    - [ ] License 是否明確
    
    ---
    
    ## 輸出格式
    
    掃描完成後,輸出以下格式的報告:
    
    ```
    ## Repo Scan 報告:{repo_name}
    
    ### 專案概覽
    (Phase 1 的表格)
    
    ### 依賴分析
    (Phase 2 的發現,列出可疑依賴)
    
    ### 靜態弱點
    (Phase 3 的發現,依嚴重程度排序)
    
    每個弱點格式:
    #### 弱點 N:{類別} — `{file}:{line}`
    - **嚴重程度**:High / Medium / Low
    - **說明**:具體描述問題
    - **利用場景**:攻擊者如何利用
    - **建議**:如何修復
    
    ### 供應鏈風險
    (Phase 4 的發現)
    
    ### Issues 安全回報
    (Phase 5 的表格 + 分析)
    (如跳過,註明「gh CLI 不可用,已跳過」)
    
    ### 專案健康度
    (Phase 6 的評估)
    
    ---
    
    ### 風險總結
    
    | 維度 | 風險等級 | 說明 |
    |------|---------|------|
    | 程式碼安全 | High/Medium/Low/None | |
    | 依賴風險 | High/Medium/Low/None | |
    | 供應鏈風險 | High/Medium/Low/None | |
    | 已知漏洞 | High/Medium/Low/None | |
    | 維護狀態 | High/Medium/Low/None | |
    | **整體風險** | **X** | |
    
    ### 結論
    
    是否建議安裝/使用?(明確回答)
    - 已知風險摘要(最多 3 點)
    - 使用時的注意事項(如果建議使用)
    ```
    
    ---
    
    ## 嚴重程度定義
    
    - **High**:可直接利用,導致 RCE、資料外洩、權限提升
    - **Medium**:需特定條件才能利用,但影響範圍大
    - **Low**:防禦縱深問題,或影響範圍小
    
    ---
    
    ## Anti-patterns
    
    - ❌ **執行掃描目標** — 跑 install script、`npm install`、啟服務來「看看它做什麼」;本 skill 純靜態分析,clone 下來的 code 一律不執行
    - ❌ **star 數 / README 宣稱當安全證據** — 高星、漂亮 README 不代表安全;只看實際 code、依賴、issue、維護訊號
    - ❌ **報理論性問題湊數** — 信心不足 70% 或無實際利用場景的發現不列入;每條都要附檔案 + 行號 + 利用場景
    - ❌ **掃完不清** — clone 到 `/tmp/` 的 repo 掃完要刪,不留殘骸
    - ❌ **gh 不可用就整份放棄** — 只跳過 Phase 5(Issues),其餘照跑並註明跳過原因
    
    ## 注意事項
    
    - 只報告有實際風險的發現,不報理論性問題
    - 信心不足 70% 的發現不列入報告
    - 每個發現都要附具體檔案和行號
    - 報告以繁體中文輸出
    - 掃描完成後刪除 `/tmp/` 下的 clone
    - 此為靜態分析,不執行任何程式碼
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related