Security Scanner — 7-Phase Audit Pipeline

Version: 1.1.0 | Author: Shadows Company | License: MIT

WHEN TO TRIGGER

- Before any production deployment
After a security incident
Regular scheduled audit (monthly recommended)
New dependency or library added
User says "security audit", "check for vulnerabilities", "scan security"
Code review for security-sensitive features (auth, payments, data handling)

WHEN NOT TO TRIGGER

- Simple UI changes with no data handling
Documentation-only changes

PREREQUISITES

Required:

- git — Used in Phase 6 to scan git history for leaked secrets via git log --all -p. Detection: which git or git --version.

Optional (auto-detected for dependency scanning in Phase 2):

- npm — Node.js package manager. Runs npm audit --json for JavaScript/TypeScript projects. Detected via which npm and presence of package.json.
INLINECODE8 / pip3 — Python package manager. Runs pip audit for Python projects. Detected via which pip or which pip3 and presence of requirements.txt or pyproject.toml.
INLINECODE15 — Rust package manager. Runs cargo audit for Rust projects. Detected via which cargo and presence of Cargo.toml.
INLINECODE19 — Used optionally in Phase 5 for HTTP security header checks. Only invoked when the user provides a target URL. Detected via which curl.

If no package manager is detected, Phase 2 is skipped with a note in the report.

PROTOCOL — 7 PHASES

Phase 1 — RECONNAISSANCE

Map the attack surface:

1. List all entry points (routes, APIs, webhooks, forms)
Identify data flows (user input -> storage -> output)
Map authentication and authorization boundaries
Identify external service integrations
Check for exposed ports and services

CODEBLOCK0

Phase 2 — DEPENDENCY SCAN

Check for known vulnerabilities in dependencies:

CODEBLOCK1

For each vulnerability found:

- Severity (Critical/High/Medium/Low)
CVE identifier
Affected package and version
Available fix version
Is it exploitable in this context?

NOTE: npm audit and pip audit make network calls to vulnerability databases (registry.npmjs.org, pypi.org/pyup.io). These are read-only queries.

Phase 3 — APPLICATION SECURITY TESTS

Check OWASP Top 10:

1. Injection (SQL, NoSQL, OS, LDAP)

- Search for string concatenation in queries - Verify parameterized queries are used CODEBLOCK2

2. Broken Authentication

3. Sensitive Data Exposure

- Search for hardcoded secrets:

   grep -rniE "(password|secret|api_key|token|private_key)\s*[:=]\s*['\"][^'\"]{8,}" --include="*.py" --include="*.js" --include="*.ts" --include="*.env"

- Check HTTPS enforcement, HSTS headers

4. XSS — Search for unsanitized user input in HTML output:

   grep -rn "innerHTML\|dangerouslySetInnerHTML\|v-html\|\|safe" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" --include="*.html" --include="*.py"

5. CSRF — Verify anti-CSRF tokens on state-changing endpoints
Insecure Deserialization — Search for dangerous deserialization:

CODEBLOCK5

Phase 4 — API SECURITY

For each API endpoint:

1. Authentication required? (JWT, API key, session)
Authorization enforced? (role checks, ownership validation)
Rate limiting configured?
Input validation present? (schema validation, type checking)
Response doesn't leak internal details? (stack traces, DB structure)
CORS properly configured?

Phase 5 — HARDENING CHECK

Verify infrastructure hardening.

HTTP Security Headers (only when user provides a target URL):

CODEBLOCK6

IMPORTANT: Only run this check when user provides a target URL. Never make network requests to URLs not explicitly provided by the user.

Checklist:

- [ ] Strict-Transport-Security header present
[ ] Content-Security-Policy header present
[ ] X-Frame-Options header present
[ ] X-Content-Type-Options: nosniff header present
[ ] No server version exposed in response headers
[ ] Debug mode disabled in production config
[ ] Error pages don't leak stack traces (inspect error handlers in code)
[ ] File upload restrictions enforced (check upload handlers for size/type validation)

Phase 6 — SECRETS VERIFICATION

CODEBLOCK7

Verify:

- [ ] .env files listed in INLINECODE29
[ ] No secrets found in git history
[ ] Secrets stored in environment variables or vault
[ ] No secrets printed in logs or error messages

Phase 7 — REPORT

Generate a structured security report using the OUTPUT FORMAT below.

LIMITATIONS

Grep-based scanning (Phases 3 and 6) uses pattern matching to detect common vulnerability signatures. This approach has inherent limitations:

False positives:

- Comments or documentation containing patterns like password = "example" will be flagged
Test fixtures with dummy secrets (e.g., api_key = "test_key_123") will trigger alerts
String comparisons against constant values (e.g., if method == "SELECT") may be flagged as injection

False negatives:

- Obfuscated secrets (base64-encoded, split across variables) will not be detected
Indirect injection via variable references (e.g., query = build_query(user_input)) is not caught
Secrets committed then deleted from history require --all flag and full history scan
Framework-specific vulnerability patterns not covered by generic regexes

Recommendation: Complement grep-based scans with dedicated tools:

- SAST: Semgrep, CodeQL, or Bandit (Python)
Secrets: gitleaks, trufflehog, or detect-secrets
DAST: OWASP ZAP, Burp Suite, or Nuclei
SCA: Snyk, Dependabot, or Trivy

RULES

1. Never skip phases — even if project seems simple
Evidence-based — every finding must have file:line or command output
Severity accuracy — don't inflate or downplay risks
Actionable remediation — every finding must include HOW to fix
No false security — passing this scan doesn't mean 100% secure

SECURITY CONSIDERATIONS

- Commands executed: grep (local pattern matching), git log (local history scan), npm audit / pip audit / cargo audit (dependency vulnerability check), curl (HTTP HEAD request — Phase 5 only).
Network access: Phase 2 dependency scanners (npm audit, pip audit) make read-only queries to vulnerability databases. Phase 5 makes ONE outbound HTTP HEAD request via curl to check security headers — only when the user provides a target URL. All other phases are local-only.
Data read: Source files, dependency manifests, git history — all within the local repository.
File modification: None. This skill is read-only.
Persistence: None.
Credentials: None required by the skill itself. Scanned output may display secret-like patterns found in the repository — run in a secure terminal.
Sandboxing: Not required (no code execution). Standard terminal security applies when displaying scan results.

OUTPUT FORMAT

CODEBLOCK8

Published by Shadows Company — "We work in the shadows to serve the Light."

安全扫描器 — 7阶段审计管道

版本: 1.1.0 | 作者: Shadows Company | 许可证: MIT

何时触发

- 任何生产环境部署之前
安全事件发生后
定期计划审计（建议每月一次）
新增依赖或库
用户提及安全审计、检查漏洞、扫描安全
对安全敏感功能（认证、支付、数据处理）进行代码审查

何时不触发

- 不涉及数据处理的简单UI变更
仅文档变更

前置条件

必需：

- git — 在第6阶段用于通过git log --all -p扫描git历史中的泄露密钥。检测方式：which git或git --version。

可选（在第2阶段自动检测用于依赖扫描）：

- npm — Node.js包管理器。对JavaScript/TypeScript项目运行npm audit --json。通过which npm和package.json的存在检测。
pip / pip3 — Python包管理器。对Python项目运行pip audit。通过which pip或which pip3以及requirements.txt或pyproject.toml的存在检测。
cargo — Rust包管理器。对Rust项目运行cargo audit。通过which cargo和Cargo.toml的存在检测。
curl — 在第5阶段可选用于HTTP安全头检查。仅在用户提供目标URL时调用。通过which curl检测。

如果未检测到任何包管理器，第2阶段将被跳过，并在报告中注明。

协议 — 7个阶段

第1阶段 — 侦察

绘制攻击面：

1. 列出所有入口点（路由、API、Webhook、表单）
识别数据流（用户输入 -> 存储 -> 输出）
映射认证和授权边界
识别外部服务集成
检查暴露的端口和服务

bash

Node.js — 查找所有路由定义

grep -rn app\.$get\|post\|put\|delete\|patch$ --include=.js --include=.ts -l

Python — 查找所有路由定义

grep -rn @app\.$route\|get\|post$ --include=*.py -l

第2阶段 — 依赖扫描

检查依赖中的已知漏洞：

bash

Node.js — 需要npm

npm audit --json 2>/dev/null || echo npm audit不可用 — 安装npm或跳过第2阶段

Python — 需要pip-audit（pip install pip-audit）

pip audit 2>/dev/null || echo pip audit不可用 — 安装pip-audit或跳过第2阶段

Rust — 需要cargo-audit（cargo install cargo-audit）

cargo audit 2>/dev/null || echo cargo-audit不可用 — 安装cargo-audit或跳过第2阶段

对于发现的每个漏洞：

- 严重程度（严重/高/中/低）
CVE标识符
受影响的包和版本
可用的修复版本
在当前上下文中是否可利用

注意：npm audit和pip audit会向漏洞数据库（registry.npmjs.org、pypi.org/pyup.io）发起网络调用。这些是只读查询。

第3阶段 — 应用程序安全测试

检查OWASP Top 10：

1. 注入（SQL、NoSQL、OS、LDAP）

- 搜索查询中的字符串拼接 - 验证是否使用参数化查询 bash grep -rn f[\].SELECT\|f[\].INSERT\|f[\].UPDATE --include=.py grep -rn query.\+\|exec.\+ --include=.js --include=.ts

2. 失效的身份认证

3. 敏感数据泄露

- 搜索硬编码的密钥： bash grep -rniE (password|secret|apikey|token|privatekey)\s[:=]\s[\][^\]{8,} --include=.py --include=.js --include=.ts --include=.env

- 检查HTTPS强制、HSTS头

4. XSS — 搜索HTML输出中未清理的用户输入：

bash grep -rn innerHTML\|dangerouslySetInnerHTML\|v-html\|\|safe --include=.js --include=.ts --include=.jsx --include=.tsx --include=.html --include=.py

5. CSRF — 验证状态变更端点上的反CSRF令牌
不安全的反序列化 — 搜索危险的反序列化：

bash grep -rn eval(\|pickle\.loads\|yaml\.load( --include=.py --include=.js --include=*.ts

第4阶段 — API安全

对于每个API端点：

1. 是否需要认证？（JWT、API密钥、会话）
是否强制执行授权？（角色检查、所有权验证）
是否配置了速率限制？
是否存在输入验证？（模式验证、类型检查）
响应是否不泄露内部细节？（堆栈跟踪、数据库结构）
CORS是否配置正确？

第5阶段 — 加固检查

验证基础设施加固。

HTTP安全头（仅在用户提供目标URL时）：

bash

将$TARGET_URL替换为用户提供的URL

curl -sI $TARGET_URL | grep -iE (strict-transport|content-security|x-frame|x-content-type)

重要：仅在用户提供目标URL时运行此检查。切勿对用户未明确提供的URL发起网络请求。

检查清单：

- [ ] 存在Strict-Transport-Security头
[ ] 存在Content-Security-Policy头
[ ] 存在X-Frame-Options头
[ ] 存在X-Content-Type-Options: nosniff头
[ ] 响应头中未暴露服务器版本
[ ] 生产配置中禁用调试模式
[ ] 错误页面不泄露堆栈跟踪（检查代码中的错误处理器）
[ ] 强制执行文件上传限制（检查上传处理器的大小/类型验证）

第6阶段 — 密钥验证

bash

检查git历史中的泄露密钥（本地操作，无网络）

验证.gitignore是否覆盖敏感文件

验证：

- [ ] .env文件列在.gitignore中
[ ] git历史中未发现密钥
[ ] 密钥存储在环境变量或保险库中
[ ] 日志或错误消息中未打印密钥

第7阶段 — 报告

使用下面的输出格式生成结构化的安全报告。

局限性

基于grep的扫描（第3和第6阶段）使用模式匹配来检测常见漏洞特征。这种方法具有固有的局限性：

误报：

- 包含password = example等模式的注释或文档将被标记
包含虚拟密钥的测试夹具（例如apikey = testkey_123）将触发警报
与常量值的字符串比较（例如if method == SELECT）可能被标记为注入

漏报：

- 混淆的密钥（base64编码、跨变量拆分）不会被检测到
通过变量引用的间接注入（例如query = buildquery(userinput)）不会被捕获
提交后删除的密钥需要--all标志和完整历史扫描
通用正则表达式未覆盖的框架特定漏洞模式

建议：使用专用工具补充基于grep的扫描：

- SAST：Semgrep、CodeQL或Bandit（Python）
密钥：gitleaks、trufflehog或detect-secrets
DAST：OWASP ZAP、Burp Suite或Nuclei
SCA：Snyk、Dependabot或Trivy

规则

1. 切勿跳过阶段 — 即使项目看起来很简单
基于证据 — 每个发现必须有文件:行号或命令输出

security-scanner安全扫描器