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
Install
npx skills add https://github.com/KerberosClaw/kc_ai_skills/tree/main/repo-scan
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install kerberosclaw-kc-ai-skills@llmmart
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=等追蹤參數)
執行規則
- GitHub repo URL 為必要參數。如果使用者沒有提供,直接詢問,不要猜測。
- URL 清理:移除
?fbclid=、?ref=等追蹤參數,保留https://github.com/owner/repo格式。 - 前置檢查通過後才開始掃描流程。
- 掃描完成後清理:刪除 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、preinstallhook(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.shMakefile的 install targetDockerfile/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 安全回報掃描
需要
ghCLI。無法使用時跳過此階段並註明。
# 抓所有 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.
Reviews (0)
No reviews yet.
No comments yet.