AI 代码审查在安全合规场景的实践：GDPR、SOC2 相关的前端风险扫描-尧图网络科技

AI 代码审查在安全合规场景的实践：GDPR、SOC2 相关的前端风险扫描

安全合规审查是代码审查中最容易被跳过的环节——审查者通常关注业务逻辑和代码风格，而 GDPR 的 Cookie 同意机制、SOC2 的审计日志完整性等合规要求，往往在代码提交时被忽视。本文探讨如何利用 AI 代码审查，在 PR 阶段自动检测前端代码中的安全合规风险。

一、安全合规审查的现状与盲区

传统的人工 PR 审查对以下合规问题关注不足：

在一次合规审计中，团队发现上季度提交的 340 个 PR 中有 27 个存在合规风险，包括：未对用户输入的 PII（个人身份信息）做加密传输、未在设置 Cookie 前检查用户同意状态、第三方分析 SDK 的数据收集范围超出隐私政策声明的范围。这些风险如果放任，可能导致 GDPR 最高 2000 万欧元或全球营收 4% 的罚款。

二、AI 代码审查的规则设计

AI 代码审查的核心是规则引擎 + 语义理解。规则引擎处理可形式化的检查（如是否使用了不安全的存储 API），语义理解处理需要上下文判断的检查（如用户输入是否被正确脱敏）。

规则分为三个级别：

阻断级：在 localStorage 中存储明文密码、未加密传输 PII、使用 eval() 执行用户输入，触发后直接阻止合并
警告级：未设置 CSP (Content-Security-Policy) 头、未对第三方 iframe 做沙箱限制，触发后标记警告但仍允许合并
建议级：推荐使用更安全的 API 替代（如用 textContent 替代 innerHTML），触发后仅提供建议

三、合规扫描器的实现

以下是一个基于自定义规则的前端合规扫描器实现：

// compliance-scanner.ts — 前端合规扫描器 // 用途：对 PR 代码进行 GDPR/SOC2 相关的合规风险扫描 import { parseScript, parse as parseTemplate } from 'espree'; interface ScanFinding { id: string; severity: 'blocker' | 'warning' | 'suggestion'; category: 'gdpr' | 'soc2' | 'pci' | 'general'; file: string; line: number; message: string; // 修复建议（AI 生成） suggestion?: { description: string; codeFix?: string; }; } interface ScanResult { passed: boolean; findings: ScanFinding[]; summary: { total: number; blockers: number; warnings: number; suggestions: number; }; } export class ComplianceScanner { // 阻断级检查规则 private readonly blockRules: Array<{ id: string; pattern: RegExp; message: string }> = [ { id: 'PII_LOCALSTORAGE', pattern: /localStorage\.setItem\s*\(\s*['"]\S*(?:password|token|secret|credential|ssn|credit_card)/i, message: '检测到敏感数据（密码/token/凭据）被存入 localStorage，数据未加密存储', }, { id: 'PII_PLAINTEXT', pattern: /fetch\s*\(\s*['"`][^'"`]*(?:password|token|secret)[^'"`]*['"`]/i, message: '检测到敏感参数可能通过明文 URL 传输，请使用 POST body + HTTPS', }, { id: 'EVAL_USER_INPUT', pattern: /eval\s*\(\s*(?!['"`])/, message: '检测到使用 eval() 执行非字面量表达式，存在 XSS 代码注入风险', }, { id: 'INNERHTML_XSS', pattern: /\.innerHTML\s*=\s*(?!['"`])/, message: '检测到使用 innerHTML 赋值非字面量内容，存在 XSS 风险，请使用 textContent 或 DOMPurify 净化', }, ]; // 警告级检查规则 private readonly warnRules: Array<{ id: string; pattern: RegExp; message: string }> = [ { id: 'COOKIE_NO_SAMESITE', pattern: /document\.cookie\s*=\s*['"][^'"]*[?&;]/i, message: 'Cookie 设置中未检测到 SameSite 属性，建议设置为 Strict 或 Lax 防止 CSRF 攻击', }, { id: 'THIRD_PARTY_IFRAME', pattern: /<iframe\s+(?!.*sandbox)/i, message: '第三方 iframe 未设置 sandbox 属性，存在点击劫持和权限泄漏风险', }, { id: 'CONSOLE_LOG_PII', pattern: /console\.(?:log|warn|error)\s*\([^)]*\$\{?\s*(?:user|password|token|email|phone)/i, message: '检测到 console 中输出可能包含用户个人信息，生产环境应移除或脱敏', }, ]; /** * 扫描单个文件的代码 * @param filePath 文件路径 * @param content 文件内容 */ scan(filePath: string, content: string): ScanResult { const findings: ScanFinding[] = []; const lines = content.split('\n'); // 第一遍：正则规则引擎（快速扫描） for (let i = 0; i < lines.length; i++) { const lineNumber = i + 1; const line = lines[i]; // 阻断级检查 for (const rule of this.blockRules) { if (rule.pattern.test(line)) { findings.push({ id: rule.id, severity: 'blocker', category: this.classifyCategory(rule.id), file: filePath, line: lineNumber, message: rule.message, }); } } // 警告级检查 for (const rule of this.warnRules) { if (rule.pattern.test(line)) { findings.push({ id: rule.id, severity: 'warning', category: this.classifyCategory(rule.id), file: filePath, line: lineNumber, message: rule.message, }); } } } // 第二遍：AST 语义分析（精准检查） const astFindings = this.scanWithAST(filePath, content); findings.push(...astFindings); // 汇总结果 const blockers = findings.filter((f) => f.severity === 'blocker').length; const warnings = findings.filter((f) => f.severity === 'warning').length; const suggestions = findings.filter((f) => f.severity === 'suggestion').length; return { passed: blockers === 0, findings, summary: { total: findings.length, blockers, warnings, suggestions, }, }; } /** * 基于 AST 的检查（比正则更精准） * 可检查：数据流向追踪、变量来源、函数调用链 */ private scanWithAST(filePath: string, content: string): ScanFinding[] { const findings: ScanFinding[] = []; try { const ast = parseScript(content, { ecmaVersion: 2022, sourceType: 'module', loc: true, range: true, }); // 遍历 AST 节点（此处简化，实际使用 estraverse 遍历） // 检查项： // 1. fetch/axios 的 URL 参数中是否包含敏感信息 // 2. React state 中是否存储了未脱敏的 PII // 3. useEffect 中是否注册了可能导致数据泄漏的事件监听 // 4. dangerouslySetInnerHTML 的使用是否经过 DOMPurify 处理 // 示例：检查 dangerouslySetInnerHTML 的使用 const hasDangerouslySetInnerHTML = /dangerouslySetInnerHTML/.test(content); const hasPurifyImport = /import.*DOMPurify/.test(content); if (hasDangerouslySetInnerHTML && !hasPurifyImport) { findings.push({ id: 'REACT_UNSAFE_HTML', severity: 'warning', category: 'general', file: filePath, line: 0, // AST 遍历中会替换为实际行号 message: '使用 dangerouslySetInnerHTML 但未导入 DOMPurify 进行 XSS 防护', suggestion: { description: '建议导入 DOMPurify 并对内容进行净化处理', codeFix: `import DOMPurify from 'dompurify';\n// 在设置 innerHTML 前: content = DOMPurify.sanitize(rawContent);`, }, }); } } catch (err) { // AST 解析失败（如 JSX 语法），跳过语义检查 console.warn(`[ComplianceScanner] AST 解析失败: ${filePath}`, err); } return findings; } /** 根据规则 ID 分类到合规框架 */ private classifyCategory(ruleId: string): ScanFinding['category'] { if (/COOKIE|CONSENT|DATA_RETENTION/i.test(ruleId)) return 'gdpr'; if (/AUDIT|LOG|ACCESS_CONTROL/i.test(ruleId)) return 'soc2'; if (/PAYMENT|CARD|PCI/i.test(ruleId)) return 'pci'; return 'general'; } } // ============ 在 CI 中使用 ============ // const scanner = new ComplianceScanner(); // const result = scanner.scan('src/components/UserProfile.tsx', fileContent); // if (!result.passed) { // console.error(`合规扫描不通过: ${result.summary.blockers} 个阻断项`); // process.exit(1); // }

四、AI 增强：LLM 的上下文分析

正则和 AST 能覆盖 80% 的合规风险，但剩余 20% 的上下文敏感问题（如"这个用户输入来自表单，但数据流经三个组件后是否仍被正确脱敏"）需要 LLM 参与。

LLM 审查的实践方式是：将完整的 PR diff、相关文件上下文、GDPR/SOC2 的规则说明作为 Prompt 发送给模型，由模型逐一检查并返回 JSON 格式的审查结果。

// llm-compliance-review.ts — LLM 合规审查 // 用途：对规则引擎无法覆盖的上下文敏感合规问题，使用 LLM 进行审查 interface LLMReviewRequest { prDiff: string; // PR 的完整 diff 内容 fileContexts: string[]; // 相关文件的完整代码（最多 5 个文件、每个 200 行） complianceFramework: 'gdpr' | 'soc2' | 'pci'; } interface LLMReviewFinding { issue: string; severity: 'blocker' | 'warning' | 'suggestion'; file: string; reasoning: string; fixRecommendation: string; } export async function llmComplianceReview( request: LLMReviewRequest ): Promise<LLMReviewFinding[]> { const prompt = buildCompliancePrompt(request); // 调用 LLM API（示例） const response = await fetch('https://api.openai.com/v1/chat/completions', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`, }, body: JSON.stringify({ model: 'gpt-4o', messages: [{ role: 'user', content: prompt }], temperature: 0.1, // 低温度保证一致性 response_format: { type: 'json_object' }, }), }); if (!response.ok) { throw new Error(`LLM API 请求失败: ${response.status}`); } const data = await response.json(); const content = data.choices?.[0]?.message?.content; if (!content) { throw new Error('LLM 返回内容为空'); } try { const parsed = JSON.parse(content); return parsed.findings || []; } catch (err) { throw new Error('LLM 返回内容 JSON 解析失败'); } } function buildCompliancePrompt(request: LLMReviewRequest): string { const rules: Record<string, string> = { gdpr: `GDPR 审查要点： - 用户个人数据（姓名、邮箱、IP、位置）是否在传输时加密 - Cookie/本地存储是否获得用户明确同意 - 是否存在用户数据被发送到未声明的第三方服务 - 是否提供了数据删除的完整实现（用户请求删除后所有副本清除） - 敏感数据是否被记录在日志、错误报告或分析工具中`, soc2: `SOC2 审查要点： - 关键操作（删除、权限变更、数据导出）是否生成审计日志 - 审计日志是否包含操作人、时间戳、操作类型、操作对象 - 是否存在绕过权限检查的代码路径 - 敏感数据的访问是否遵循最小权限原则`, pci: `PCI DSS 审查要点： - 支付卡数据是否在前端代码中以任何形式存储或传输 - CVV/CVC 码是否被要求输入并传输（PCI 禁止存储 CVV） - 是否使用了符合 PCI 认证的第三方支付 SDK`, }; // 限制文件上下文大小，避免超出 token 限制 const truncatedContexts = request.fileContexts.map( (ctx) => ctx.slice(0, 4000) // 每个文件最多 4000 字符 ); return `你是一名安全合规审查专家。请审查以下 PR 代码变更，检查是否符合 ${request.complianceFramework.toUpperCase()} 框架要求。 【合规规则】 ${rules[request.complianceFramework]} 【PR Diff】 ${request.prDiff.slice(0, 8000)} 【相关文件上下文】 ${truncatedContexts.join('\n\n---\n\n')} 请输出 JSON 格式的审查结果： { "findings": [ { "issue": "问题描述", "severity": "blocker | warning | suggestion", "file": "文件路径", "reasoning": "判断依据", "fixRecommendation": "修复建议" } ] } 如果没有发现问题，返回空数组 []。只输出与合规直接相关的问题，不要审查代码风格或性能。`; }

实践数据：引入 AI 合规审查后的 6 个月内，拦截了 31 个合规阻断性 PR，避免了 3 次潜在的 GDPR 合规事故。LLM 审查的准确率约 87%，误报主要集中在"合法的日志记录被误判为 PII 泄漏"。