ECC security-review 技能：从密钥管理到部署门禁的十项安全审查清单与 Agent 落地

本篇以 ECC 仓库中的 .agents/skills/security-review/SKILL.md 为主体，完整拆解该 security-review 技能的激活时机、十大安全审查清单（含 FAIL/PASS 对照代码）、自动化安全测试写法与上线前门禁清单，并结合 security-reviewer Agent、/security-scan 命令 与 AgentShield 扫描器说明该技能在 ECC 工程流中的实际调用关系。读完后，你可以直接复用它对鉴权、用户输入、API 端点、密钥、支付等敏感代码做一次结构化安全审查，并知道如何用仓库内配套组件把审查变成可重复、可 CI 化的流程。

1. security-review 技能在 ECC 中的定位

security-review 是 ECC 提供的一个"技能"（Skill）文件，用于在编写或审查敏感代码时给出完整的安全检查清单与参考模式。技能定义位于 SKILL.md，其 frontmatter 声明了触发语义：

name: security-review
description: Use this skill when adding authentication, handling user input,
  working with secrets, creating API endpoints, or implementing payment/sensitive
  features. Provides comprehensive security checklist and patterns.

同一技能目录下的 agents/openai.yaml 提供了该技能在 Agent 界面中的元数据：显示名为 "Security Review"，短描述为 "Security checklist and vulnerability review"，品牌色 #EF4444，默认提示词为 Use $security-review to review sensitive code with the security checklist.，并且 allow_implicit_invocation: true——即允许在上下文中被隐式调用，而不必显式 $security-review 触发。

从仓库结构看，该技能有三层配套组件，共同构成"技能 + Agent + 命令"的安全审查闭环：

组件	路径	角色
技能（本文主体）	.agents/skills/security-review/SKILL.md	提供审查清单与代码模式
规范技能副本	skills/security-review/SKILL.md	带 metadata: origin: ECC 的规范副本，并附带云安全技能
配套技能	skills/security-review/cloud-infrastructure-security.md	云端/CI-CD 基础设施安全检查清单
审查 Agent	agents/security-reviewer.md	执行 OWASP Top 10 扫描、模式识别的专职 Agent
扫描命令	commands/security-scan.md	调用 AgentShield 做确定性扫描并生成修复计划
扫描技能	skills/security-scan/SKILL.md	用 AgentShield 审计 .claude/ 配置面

其中 security-reviewer Agent 在其 Reference 一节明确写道："For detailed vulnerability patterns, code examples, report templates, and PR review templates, see skill: security-review"——即 Agent 负责"怎么扫"，本技能文档负责"按什么标准判"。

2. 激活时机：什么时候必须启动安全审查

技能文档给出了 7 类应激活 security-review 的场景：

• 实现认证（authentication）或授权（authorization）；
• 处理用户输入或文件上传；
• 创建新的 API 端点；
• 操作密钥（secrets）或凭据（credentials）；
• 实现支付类功能；
• 存储或传输敏感数据；
• 集成第三方 API。

与之呼应，security-reviewer Agent 把触发条件细化为两个强度级别：ALWAYS（新增 API 端点、鉴权代码变更、用户输入处理、数据库查询变更、文件上传、支付代码、外部 API 集成、依赖升级）与 IMMEDIATELY（生产事故、依赖 CVE、用户安全报告、重大发布前）。这实际上回答了工程实践中的高频问题：安全审查不是"上线前一次性动作"，而是上述七类代码变更的伴随动作。

3. 十项安全检查清单详解

技能主体是一张十节清单，每节都遵循同一写法：先给 FAIL: NEVER Do This 反例，再给 PASS: ALWAYS Do This 正例，最后以可勾选的 Verification Steps 收尾。下面逐节展开，代码示例完整保留原文。

3.1 密钥管理（Secrets Management）

反例：硬编码密钥

const apiKey = "sk-proj-xxxxx"  // Hardcoded secret
const dbPassword = "password123" // In source code

正例：环境变量 + 存在性校验

const apiKey = process.env.OPENAI_API_KEY
const dbUrl = process.env.DATABASE_URL

// Verify secrets exist
if (!apiKey) {
  throw new Error('OPENAI_API_KEY not configured')
}

验证步骤：

• [ ] 无硬编码 API key、token、密码
• [ ] 所有密钥放在环境变量中
• [ ] .env.local 已加入 .gitignore
• [ ] git 历史中不存在密钥
• [ ] 生产密钥托管在部署平台（Vercel、Railway 等）

这条规则在 ECC 仓库自身同样被严格执行，可作为该模式的现实佐证：SECURITY.md 明确 mcp-configs/mcp-servers.json 只是模板，其中所有 YOUR_*_HERE 值必须在安装时从环境变量或密钥管理器替换，严禁提交真实凭据；若密钥误提交，须立即轮换并重写历史，而不能依赖一次普通 revert。查看 mcp-servers.json 可以看到该约定的落地形态，例如：

"jira": {
  "command": "uvx",
  "args": ["mcp-atlassian==0.21.0"],
  "env": {
    "JIRA_URL": "YOUR_JIRA_URL_HERE",
    "JIRA_EMAIL": "YOUR_JIRA_EMAIL_HERE",
    "JIRA_API_TOKEN": "YOUR_JIRA_API_TOKEN_HERE"
  }
}

[SECURITY.md](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/SECURITY.md?utm_source=gitcode_repo_files) 还给出了针对用户级 Claude Code 配置（~/.claude/settings.json）的快速密钥审计命令：

# macOS / Linux
grep -EnH '(TOKEN|SECRET|KEY|PASSWORD)\s*"\s*:\s*"[A-Za-z0-9_-]{16,}"' ~/.claude/settings.json

# Windows PowerShell
Select-String -Path "$env:USERPROFILE\.claude\settings.json" -Pattern '(TOKEN|SECRET|KEY|PASSWORD)"\s*:\s*"[A-Za-z0-9_-]{16,}"'

若审计命中，应在签发方轮换密钥后再将其移出文件——这正是清单第 1 节"验证密钥存在"背后的完整运维闭环。

3.2 输入校验（Input Validation）

始终用 schema 校验用户输入

import { z } from 'zod'

// Define validation schema
const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1).max(100),
  age: z.number().int().min(0).max(150)
})

// Validate before processing
export async function createUser(input: unknown) {
  try {
    const validated = CreateUserSchema.parse(input)
    return await db.users.create(validated)
  } catch (error) {
    if (error instanceof z.ZodError) {
      return { success: false, errors: error.errors }
    }
    throw error
  }
}

文件上传三重校验：大小、MIME 类型、扩展名

function validateFileUpload(file: File) {
  // Size check (5MB max)
  const maxSize = 5 * 1024 * 1024
  if (file.size > maxSize) {
    throw new Error('File too large (max 5MB)')
  }

  // Type check
  const allowedTypes = ['image/jpeg', 'image/png', 'image/gif']
  if (!allowedTypes.includes(file.type)) {
    throw new Error('Invalid file type')
  }

  // Extension check
  const allowedExtensions = ['.jpg', '.jpeg', '.png', '.gif']
  const extension = file.name.toLowerCase().match(/\.[^.]+$/)?.[0]
  if (!extension || !allowedExtensions.includes(extension)) {
    throw new Error('Invalid file extension')
  }

  return true
}

验证步骤：

• [ ] 所有用户输入均经 schema 校验
• [ ] 文件上传受限制（大小、类型、扩展名）
• [ ] 用户输入不直接进入查询
• [ ] 采用白名单校验（而非黑名单）
• [ ] 错误信息不泄露敏感信息

注意清单强调"Whitelist validation (not blacklist)"：示例中同时校验 file.type 与扩展名白名单，体现了"类型 + 后缀双重白名单"的防御思路——MIME 类型可由客户端伪造，扩展名可被手工修改，二者取交集才能收窄攻击面。

3.3 防 SQL 注入

反例：字符串拼接 SQL

// DANGEROUS - SQL Injection vulnerability
const query = `SELECT * FROM users WHERE email = '${userEmail}'`
await db.query(query)

正例：参数化查询

// Safe - parameterized query
const { data } = await supabase
  .from('users')
  .select('*')
  .eq('email', userEmail)

// Or with raw SQL
await db.query(
  'SELECT * FROM users WHERE email = $1',
  [userEmail]
)

验证步骤：

• [ ] 所有数据库查询使用参数化查询
• [ ] SQL 中不存在字符串拼接
• [ ] ORM / query builder 使用正确
• [ ] Supabase 查询经过正确净化

security-reviewer Agent 的模式识别表把"String-concatenated SQL"标记为 CRITICAL 级，修复方式即"Parameterized queries"，与本节 PASS 示例一一对应；同类 CRITICAL 还包括"Shell command with user input"（应用安全 API 或 execFile）与"Plaintext password comparison"（应使用 bcrypt.compare()）。

3.4 认证与授权（Authentication & Authorization）

JWT 存储：httpOnly Cookie 而非 localStorage

// FAIL: WRONG: localStorage (vulnerable to XSS)
localStorage.setItem('token', token)

// PASS: CORRECT: httpOnly cookies
res.setHeader('Set-Cookie',
  `token=${token}; HttpOnly; Secure; SameSite=Strict; Max-Age=3600`)

localStorage 中的 token 可被任意 XSS 读取，因此技能要求令牌放入 HttpOnly + Secure + SameSite=Strict 的 cookie，从浏览器 JS 作用域中隔离出去。

授权检查：敏感操作前必须先验权

export async function deleteUser(userId: string, requesterId: string) {
  // ALWAYS verify authorization first
  const requester = await db.users.findUnique({
    where: { id: requesterId }
  })

  if (requester.role !== 'admin') {
    return NextResponse.json(
      { error: 'Unauthorized' },
      { status: 403 }
    )
  }

  // Proceed with deletion
  await db.users.delete({ where: { id: userId } })
}

行级安全（Supabase RLS）

-- Enable RLS on all tables
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

-- Users can only view their own data
CREATE POLICY "Users view own data"
  ON users FOR SELECT
  USING (auth.uid() = id);

-- Users can only update their own data
CREATE POLICY "Users update own data"
  ON users FOR UPDATE
  USING (auth.uid() = id);

验证步骤：

• [ ] token 存于 httpOnly cookie（而非 localStorage）
• [ ] 敏感操作前执行授权检查
• [ ] Supabase 启用 Row Level Security
• [ ] 实现基于角色的访问控制（RBAC）
• [ ] 会话管理安全

这一节实际上是"应用层鉴权 + 数据库层 RLS"的双层防线：应用层漏掉一个端点的鉴权时，RLS 策略仍能把越权读取挡在数据库层。

3.5 防 XSS（XSS Prevention）

净化用户 HTML

import DOMPurify from 'isomorphic-dompurify'

// ALWAYS sanitize user-provided HTML
function renderUserContent(html: string) {
  const clean = DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'],
    ALLOWED_ATTR: []
  })
  return <div dangerouslySetInnerHTML={{ __html: clean }} />
}

净化配置采用最小化白名单：仅允许 5 个基础排版标签、零属性，即使 dangerouslySetInnerHTML 渲染，注入面也被压缩到无脚本、无事件处理器、无任意属性的纯文本结构。

内容安全策略（CSP）

// next.config.js
const securityHeaders = [
  {
    key: 'Content-Security-Policy',
    value: `
      default-src 'self';
      script-src 'self' 'unsafe-eval' 'unsafe-inline';
      style-src 'self' 'unsafe-inline';
      img-src 'self' data: https:;
      font-src 'self';
      connect-src 'self' https://api.example.com;
    `.replace(/\s{2,}/g, ' ').trim()
  }
]

验证步骤：

• [ ] 用户提供的 HTML 已净化
• [ ] 已配置 CSP 响应头
• [ ] 无不加校验的动态内容渲染
• [ ] 使用 React 内置的 XSS 防护

需要特别指出的是仓库内两份副本的差异：skills/security-review/SKILL.md（带 origin: ECC 的规范副本）对 CSP 一节做了收紧，明确要求"从最严格开始，仅在拥有书面移除计划时才放宽；不得默认使用 'unsafe-inline' 或 'unsafe-eval'，它们会使 CSP 的大部分保护失效，应视为临时兼容性债务"，并给出了更严格的基线策略：

// next.config.js
const securityHeaders = [
  {
    key: 'Content-Security-Policy',
    value: `
      default-src 'self';
      base-uri 'self';
      object-src 'none';
      frame-ancestors 'none';
      script-src 'self';
      style-src 'self';
      img-src 'self' data: https:;
      font-src 'self';
      connect-src 'self' https://api.example.com;
    `.replace(/\s{2,}/g, ' ').trim()
  }
]

相比 .agents/ 版本，新增的 base-uri 'self'、object-src 'none'、frame-ancestors 'none' 分别封堵了 base 标签劫持、插件对象加载与点击劫持（clickjacking）。实践建议以规范副本的严格基线为准，把宽松指令当作需要偿还的技术债。

3.6 防 CSRF（CSRF Protection）

CSRF Token 校验

import { csrf } from '@/lib/csrf'

export async function POST(request: Request) {
  const token = request.headers.get('X-CSRF-Token')

  if (!csrf.verify(token)) {
    return NextResponse.json(
      { error: 'Invalid CSRF token' },
      { status: 403 }
    )
  }

  // Process request
}

SameSite Cookie

res.setHeader('Set-Cookie',
  `session=${sessionId}; HttpOnly; Secure; SameSite=Strict`)

验证步骤：

• [ ] 所有状态变更操作要求 CSRF token
• [ ] 所有 cookie 使用 SameSite=Strict
• [ ] 实现双提交 cookie（double-submit cookie）模式

3.7 速率限制（Rate Limiting）

通用 API 限流

import rateLimit from 'express-rate-limit'

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // 100 requests per window
  message: 'Too many requests'
})

// Apply to routes
app.use('/api/', limiter)

高开销操作更严格的限流

// Aggressive rate limiting for searches
const searchLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 10, // 10 requests per minute
  message: 'Too many search requests'
})

app.use('/api/search', searchLimiter)

验证步骤：

• [ ] 所有 API 端点启用限流
• [ ] 高开销操作使用更严格阈值
• [ ] 基于 IP 的限流
• [ ] 基于用户的限流（已认证场景）

两级阈值（15 分钟 100 次 vs 1 分钟 10 次）体现的原则是：限流强度应与单次请求的成本成正比，搜索、AI 调用、报表类端点理应比简单 CRUD 更苛刻。security-reviewer Agent 也把"No rate limiting"列为 HIGH 级模式，修复建议同样是引入 express-rate-limit。

3.8 敏感数据暴露（Sensitive Data Exposure）

日志脱敏

// FAIL: WRONG: Logging sensitive data
console.log('User login:', { email, password })
console.log('Payment:', { cardNumber, cvv })

// PASS: CORRECT: Redact sensitive data
console.log('User login:', { email, userId })
console.log('Payment:', { last4: card.last4, userId })

错误信息分级

// FAIL: WRONG: Exposing internal details
catch (error) {
  return NextResponse.json(
    { error: error.message, stack: error.stack },
    { status: 500 }
  )
}

// PASS: CORRECT: Generic error messages
catch (error) {
  console.error('Internal error:', error)
  return NextResponse.json(
    { error: 'An error occurred. Please try again.' },
    { status: 500 }
  )
}

验证步骤：

• [ ] 日志中不含密码、token、密钥
• [ ] 面向用户的错误信息保持通用
• [ ] 详细错误只写入服务端日志
• [ ] 不向用户暴露堆栈信息

这一节的安全逻辑是"信息不对称"：详细诊断留在服务端日志供排查，客户端只拿到通用文案，避免攻击者借 error.message 与 stack trace 反推技术栈与内部路径。

3.9 区块链安全（Solana）

钱包签名校验

import { verify } from '@solana/web3.js'

async function verifyWalletOwnership(
  publicKey: string,
  signature: string,
  message: string
) {
  try {
    const isValid = verify(
      Buffer.from(message),
      Buffer.from(signature, 'base64'),
      Buffer.from(publicKey, 'base64')
    )
    return isValid
  } catch (error) {
    return false
  }
}

交易三重校验：收款方、金额上限、余额

async function verifyTransaction(transaction: Transaction) {
  // Verify recipient
  if (transaction.to !== expectedRecipient) {
    throw new Error('Invalid recipient')
  }

  // Verify amount
  if (transaction.amount > maxAmount) {
    throw new Error('Amount exceeds limit')
  }

  // Verify user has sufficient balance
  const balance = await getBalance(transaction.from)
  if (balance < transaction.amount) {
    throw new Error('Insufficient balance')
  }

  return true
}

验证步骤：

• [ ] 校验钱包签名
• [ ] 校验交易详情
• [ ] 交易前检查余额
• [ ] 杜绝"盲目签交易"（blind transaction signing）

对链上场景而言，签名即授权，因此"校验先于签名"的顺序不可颠倒；收款方白名单 + 金额上限 + 余额检查三道闸共同防止重放与超额划转。

3.10 依赖安全（Dependency Security）

定期审计与更新

# Check for vulnerabilities
npm audit

# Fix automatically fixable issues
npm audit fix

# Update dependencies
npm update

# Check for outdated packages
npm outdated

锁定文件纪律

# ALWAYS commit lock files
git add package-lock.json

# Use in CI/CD for reproducible builds
npm ci  # Instead of npm install

验证步骤：

• [ ] 依赖保持最新
• [ ] 无已知漏洞（npm audit 干净）
• [ ] lock 文件已提交
• [ ] 启用 Dependabot
• [ ] 定期做安全更新

配套的 security-reviewer Agent 给出了两条可直接运行的分析命令：npm audit --audit-level=high 与 npx eslint . --plugin security；而 security-scan 命令 的 CI 模式进一步展示了把依赖审计嵌入流水线的形态（npm audit --audit-level=high 作为流水线步骤之一）。

4. 自动化安全测试：把清单变成可执行的断言

技能文档给出了四类自动化测试模板，覆盖认证、授权、输入校验与限流：

// Test authentication
test('requires authentication', async () => {
  const response = await fetch('/api/protected')
  expect(response.status).toBe(401)
})

// Test authorization
test('requires admin role', async () => {
  const response = await fetch('/api/admin', {
    headers: { Authorization: `Bearer ${userToken}` }
  })
  expect(response.status).toBe(403)
})

// Test input validation
test('rejects invalid input', async () => {
  const response = await fetch('/api/users', {
    method: 'POST',
    body: JSON.stringify({ email: 'not-an-email' })
  })
  expect(response.status).toBe(400)
})

// Test rate limiting
test('enforces rate limits', async () => {
  const requests = Array(101).fill(null).map(() =>
    fetch('/api/endpoint')
  )

  const responses = await Promise.all(requests)
  const tooManyRequests = responses.filter(r => r.status === 429)

  expect(tooManyRequests.length).toBeGreaterThan(0)
})

这四组断言的价值在于把"检查清单"转化为回归防线：401/403/400/429 四个状态码分别对应认证缺失、越权、非法输入、限流失效四种典型事故。一旦未来重构不小心移除了鉴权中间件或限流器，测试会先于攻击者发现它。

5. 上线前安全门禁清单（Pre-Deployment Security Checklist）

技能要求在任何生产部署之前逐项确认（17 项）：

• [ ] 密钥：无硬编码密钥，全部来自环境变量
• [ ] 输入校验：所有用户输入已校验
• [ ] SQL 注入：所有查询已参数化
• [ ] XSS：用户内容已净化
• [ ] CSRF：防护已启用
• [ ] 认证：token 处理正确
• [ ] 授权：角色检查到位
• [ ] 速率限制：所有端点启用
• [ ] HTTPS：生产环境强制
• [ ] 安全响应头：CSP、X-Frame-Options 已配置
• [ ] 错误处理：错误中不含敏感数据
• [ ] 日志：不记录敏感数据
• [ ] 依赖：保持最新、无已知漏洞
• [ ] 行级安全：Supabase 已启用 RLS
• [ ] CORS：配置正确
• [ ] 文件上传：已校验（大小、类型）
• [ ] 钱包签名：已校验（如涉及区块链）

这份清单可视为前三节十项检查点的部署视角汇总，前 10 项与第 1～8 节逐项对应，后 7 项（HTTPS、安全头、CORS 等）补充了传输层与网络层维度。

6. 与 ECC 生态的联动：从清单到流水线

技能文档本身是"静态知识"，ECC 通过三个组件让它成为"可执行流程"：

（1）security-reviewer Agent。agents/security-reviewer.md 定义了审查工作流：初次扫描（npm audit、eslint-plugin-security、硬编码密钥搜索，重点覆盖鉴权/API/数据库查询/上传/支付/webhook 六类高危区）→ OWASP Top 10 逐项检查 → 代码模式识别。其模式-严重度-修复表可直接作为审查输出的评分依据：

模式	严重度	修复
硬编码密钥	CRITICAL	使用 process.env
用户输入拼入 Shell 命令	CRITICAL	使用安全 API 或 execFile
字符串拼接 SQL	CRITICAL	参数化查询
innerHTML = userInput	HIGH	使用 textContent 或 DOMPurify
fetch(userProvidedUrl)	HIGH	白名单域名
明文比对密码	CRITICAL	使用 bcrypt.compare()
路由无鉴权检查	CRITICAL	添加认证中间件
余额检查无锁	CRITICAL	事务中使用 FOR UPDATE
无限流	HIGH	添加 express-rate-limit
记录密码/密钥到日志	MEDIUM	净化日志输出

文档还列出了常见误报（.env.example 中的环境变量、测试凭据、公开 API key、用作校验和的 SHA256/MD5），要求"标记前必须验证上下文"，避免审查结果被噪音淹没。

（2）/security-scan 命令 + AgentShield。commands/security-scan.md 定义了确定性扫描的调用方式：

npx ecc-agentshield scan --path "${TARGET_PATH:-.}" --format text

支持 --format text|json|markdown|html、--min-severity low|medium|high|critical、--fix（仅应用被显式标记为安全且可自动修复的项）等参数，并强调"不得编造发现，以 AgentShield 输出为事实来源"。其 CI 门禁形态为：

- uses: affaan-m/agentshield@v1
  with:
    path: "."
    min-severity: "medium"
    fail-on-findings: true

与 security-review 技能 的分工是：AgentShield 负责机器可判定的确定性发现（硬编码密钥、过宽权限、危险 hook/MCP 配置），技能清单负责需要工程师判断的模式审查（RLS 策略是否合理、CSP 是否过松等）。

（3）云安全配套技能。cloud-infrastructure-security.md 把同一套"FAIL/PASS + 验证步骤"方法论扩展到基础设施层：IAM 最小权限与 MFA、云密钥管理器与自动轮换、VPC/安全组限制、日志与监控、CI/CD 流水线安全（OIDC 替代长效凭据、密钥扫描、依赖审计）、Cloudflare/WAF 配置与备份容灾，并给出 S3 公开桶、RDS 公网暴露两个典型误配置反例。它与本技能的关系是"应用代码面"与"部署环境面"的两份互补门禁。

7. 小结

security-review 技能给出的不是一份泛泛的安全口号，而是一套可直接执行的审查资产：7 类激活场景决定"何时审"，十节 FAIL/PASS 清单决定"按什么标准审"，四类自动化测试决定"如何防回归"，17 项上线前清单决定"何时放行"。在 ECC 中，它通过 security-reviewer Agent 成为代码审查的常驻角色，通过 /security-scan 命令 与 AgentShield 获得确定性扫描底座，通过 SECURITY.md 的密钥管理政策（如 mcp-configs/mcp-servers.json 的 YOUR_*_HERE 模板约定）在仓库自身得到一致执行。技能文档结尾的提醒值得作为收尾：Security is not optional. One vulnerability can compromise the entire platform. When in doubt, err on the side of caution.