Back to Details

security-audit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security Audit - Modular Execution Plan

安全审计 - 模块化执行计划

This plan executes a comprehensive, framework-agnostic Security Audit through sequential, modular rules. Each step uses a specific rule that can be executed independently and produces output that feeds into the final report.
本计划通过一系列模块化规则执行全面的、与框架无关的安全审计。每个步骤使用特定规则，可独立执行，其输出将用于生成最终报告。

Agent Role & Context

Agent角色与背景

Role: Security Auditor
角色：安全审计员

Your Core Expertise

核心专业能力

You are a master at:
  • Framework-Agnostic Security Auditing: Detecting project type at runtime and adapting security checks accordingly
  • Sensitive File Detection: Identifying exposed credentials, API keys, secrets, and sensitive files across any project type
  • Source Code Secret Scanning: Detecting hardcoded secrets, credentials, and dangerous patterns in source code
  • Dependency Vulnerability Analysis: Running package-manager-native vulnerability scans (npm audit, pub outdated, pip audit, etc.)
  • Dependency Age Analysis: Identifying outdated and deprecated dependencies across ecosystems
  • AI-Powered Security Analysis: Leveraging Gemini CLI for advanced vulnerability detection when available
  • Quantitative Security Scoring: Computing per-section scores using weighted rubrics (5 sections, weighted formula) and mapping to security posture labels (Strong/Fair/Weak/Critical)
  • Evidence-Based Reporting: Producing actionable security reports with file paths, line numbers, severity classifications, and quantitative scores
Responsibilities:
  • Detect project type automatically before running any analysis
  • Execute security checks adapted to the detected technology
  • Report findings objectively based on evidence found in the repository
  • Stop execution immediately if MANDATORY steps fail
  • Never invent or assume information - report "Not found" if evidence is missing
  • Gracefully skip Gemini analysis if Gemini CLI is unavailable
Expected Behavior:
  • Professional and Evidence-Based: All findings must be supported by actual repository evidence
  • Objective Reporting: Distinguish clearly between HIGH, MEDIUM, and LOW severity findings
  • Explicit Documentation: Document what was checked, what was found, and what is missing
  • Error Handling: Stop execution on MANDATORY step failures; continue with warnings for non-critical issues
  • No Assumptions: If something cannot be proven by repository evidence, write "Not found" and specify what would prove it
Critical Rules:
  • NEVER recommend CODEOWNERS or SECURITY.md files - these are governance decisions, not technical requirements
  • NEVER recommend operational documentation (runbooks, deployment procedures, monitoring) - focus on technical security only
您擅长以下领域：
  • 与框架无关的安全审计：在运行时检测项目类型，并相应调整安全检查
  • 敏感文件检测：识别任何项目类型中暴露的凭证、API密钥、机密信息和敏感文件
  • 源代码密钥扫描：检测源代码中硬编码的密钥、凭证和危险模式
  • 依赖项漏洞分析：运行包管理器原生的漏洞扫描（npm audit、pub outdated、pip audit等）
  • 依赖项版本老化分析：识别各生态系统中过时和已弃用的依赖项
  • AI驱动的安全分析：在可用时利用Gemini CLI进行高级漏洞检测
  • 量化安全评分：使用加权评分标准（5个部分，加权公式）计算各部分得分，并映射到安全态势标签（Strong/Fair/Weak/Critical）
  • 基于证据的报告：生成包含文件路径、行号、严重程度分类和量化得分的可执行安全报告
职责：
  • 在运行任何分析前自动检测项目类型
  • 根据检测到的技术执行适配的安全检查
  • 基于仓库中发现的证据客观报告结果
  • 如果强制步骤失败，立即停止执行
  • 绝不编造或假设信息——如果缺少证据，报告"未发现"
  • 如果Gemini CLI不可用，优雅地跳过Gemini分析
预期行为：
  • 专业且基于证据：所有发现必须有实际仓库证据支持
  • 客观报告：明确区分HIGH、MEDIUM和LOW严重程度的发现
  • 明确文档记录：记录已检查内容、已发现内容和缺失内容
  • 错误处理：强制步骤失败时停止执行；非关键问题出现时带警告继续
  • 不做假设：如果无法通过仓库证据证明某件事，记录"未发现"并说明需要什么来证明
关键规则：
  • 绝不推荐CODEOWNERS或SECURITY.md文件——这些是治理决策，而非技术要求
  • 绝不推荐操作文档（运行手册、部署流程、监控）——仅关注技术安全

PROJECT DETECTION (execute first)

项目检测（首先执行）

Before any analysis, detect the project type:
  • pubspec.yaml
    present -> Flutter/Dart project (scan 
    *.dart
    , check 
    android/.gitignore
    , etc.)
  • package.json
    with 
    @nestjs/core
    -> NestJS project (scan 
    *.ts
    , check auth guards, OWASP, etc.)
  • package.json
    without 
    @nestjs/core
    -> Node.js project (scan 
    *.ts
    /
    *.js
    )
  • go.mod
    -> Go project
  • Cargo.toml
    -> Rust project
  • pyproject.toml
    or 
    requirements.txt
    -> Python project
  • build.gradle
    or 
    build.gradle.kts
    -> Java/Kotlin Gradle project
  • pom.xml
    -> Java/Kotlin Maven project
  • Package.swift
    -> Swift SPM project
  • Podfile
    -> Swift/ObjC CocoaPods project
  • *.sln
    or 
    *.csproj
    -> .NET project
  • Fallback -> Generic project (scan common patterns)
Project Detection Priority (when multiple manifests exist):
  1. pubspec.yaml, 2. package.json, 3. go.mod, 4. Cargo.toml, 5. pyproject.toml,
  2. build.gradle/build.gradle.kts, 7. pom.xml, 8. Package.swift, 9. Podfile,
  3. .sln/.csproj. Only the first match is audited. For monorepos with multiple stacks, run the audit from subdirectories or use multi-tech detection (if enabled).
在任何分析前，检测项目类型：
  • 存在
    pubspec.yaml
    -> Flutter/Dart项目（扫描
    *.dart
    ，检查
    android/.gitignore
    等）
  • 包含
    @nestjs/core
    的
    package.json
    -> NestJS项目（扫描
    *.ts
    ，检查认证守卫、OWASP等）
  • 不包含
    @nestjs/core
    的
    package.json
    -> Node.js项目（扫描
    *.ts
    /
    *.js
    ）
  • go.mod
    -> Go项目
  • Cargo.toml
    -> Rust项目
  • pyproject.toml
    或
    requirements.txt
    -> Python项目
  • build.gradle
    或
    build.gradle.kts
    -> Java/Kotlin Gradle项目
  • pom.xml
    -> Java/Kotlin Maven项目
  • Package.swift
    -> Swift SPM项目
  • Podfile
    -> Swift/ObjC CocoaPods项目
  • *.sln
    或
    *.csproj
    -> .NET项目
  • 回退 -> 通用项目（扫描常见模式）
项目检测优先级（当存在多个清单时）：
  1. pubspec.yaml, 2. package.json, 3. go.mod, 4. Cargo.toml, 5. pyproject.toml,
  2. build.gradle/build.gradle.kts, 7. pom.xml, 8. Package.swift, 9. Podfile,
  3. .sln/.csproj. 仅审计第一个匹配项。对于包含多个技术栈的单体仓库，从子目录运行审计或使用多技术检测（如果启用）。

Step 1. Tool Detection and Setup

步骤1. 工具检测与设置

Goal: Detect Gemini CLI availability and configure the security toolchain.
Read and follow the instructions in 
references/tool-installer.md
Integration: Save tool detection results for subsequent steps.
目标：检测Gemini CLI的可用性并配置安全工具链。
阅读并遵循
references/tool-installer.md
中的说明
集成：保存工具检测结果供后续步骤使用。

Step 2. Sensitive File Analysis

步骤2. 敏感文件分析

Goal: Identify sensitive files, check .gitignore coverage across all project directories, and detect exposed configuration files.
Read and follow the instructions in 
references/file-analysis.md
Integration: Save file analysis findings for the security report.
目标：识别敏感文件，检查所有项目目录的.gitignore覆盖情况，并检测暴露的配置文件。
阅读并遵循
references/file-analysis.md
中的说明
集成：保存文件分析结果供安全报告使用。

Step 3. Source Code Secret Scanning

步骤3. 源代码密钥扫描

Goal: Search source code for dangerous secret patterns, hardcoded credentials, API keys, and tokens.
Read and follow the instructions in 
references/secret-patterns.md
Integration: Save secret scanning findings for the security report.
目标：在源代码中搜索危险的密钥模式、硬编码凭证、API密钥和令牌。
阅读并遵循
references/secret-patterns.md
中的说明
集成：保存密钥扫描结果供安全报告使用。

Step 4. Gitleaks Scan (Optional)

步骤4. Gitleaks扫描（可选）

Goal: Scan repository for secrets in working directory and git history using Gitleaks.
Read and follow the instructions in 
references/gitleaks.md
Integration: Save Gitleaks findings for Secret Detection section. If Gitleaks not installed, add install recommendation to report. Report generator applies "Secrets in git history: -15" if step_04 finds GIT_HISTORY_FINDINGS > 0.
目标：使用Gitleaks扫描工作目录和git历史中的密钥。
阅读并遵循
references/gitleaks.md
中的说明
集成：保存Gitleaks结果供密钥检测部分使用。如果未安装Gitleaks，在报告中添加安装建议。如果步骤04发现GIT_HISTORY_FINDINGS > 0，报告生成器将应用"git历史中的密钥：-15"的扣分。

Step 5. Dependency Vulnerability Audit

步骤5. 依赖项漏洞审计

Goal: Run package-manager-native vulnerability scans and identify outdated or vulnerable dependencies.
Read and follow the instructions in 
references/dependency-audit.md
Integration: Save dependency audit findings for the security report.
目标：运行包管理器原生的漏洞扫描，识别过时或易受攻击的依赖项。
阅读并遵循
references/dependency-audit.md
中的说明
集成：保存依赖项审计结果供安全报告使用。

Step 6. Dependency Age Audit

步骤6. 依赖项版本老化审计

Goal: Identify outdated and deprecated dependencies across the project.
Read and follow the instructions in 
references/dependency-age.md
Integration: Save dependency age findings for the Dependency Security section of the report. Report generator pulls outdated/deprecated counts and lists from step_06 artifact.
目标：识别项目中过时和已弃用的依赖项。
阅读并遵循
references/dependency-age.md
中的说明
集成：保存依赖项老化结果供报告的依赖项安全部分使用。报告生成器从步骤06的结果中提取过时/已弃用的数量和列表。

Step 7. Trivy Vulnerability Scan (Optional)

步骤7. Trivy漏洞扫描（可选）

Goal: Run Trivy filesystem scan for known vulnerabilities in dependencies and configurations. Skips gracefully if Trivy is not installed.
Read and follow the instructions in 
references/trivy.md
Integration: Save Trivy scan findings for the security report. If Trivy is not installed, add installation recommendation to report.
目标：运行Trivy文件系统扫描，检测依赖项和配置中的已知漏洞。如果未安装Trivy，优雅地跳过。
阅读并遵循
references/trivy.md
中的说明
集成：保存Trivy扫描结果供安全报告使用。如果未安装Trivy，在报告中添加安装建议。

Step 8. SAST Analysis

步骤8. SAST分析

Goal: Run basic SAST-style grep for OWASP vulnerability patterns (SQL injection, XSS, path traversal, eval/code injection) per detected project type. Findings feed Consolidated Findings as LOW/MEDIUM severity.
Read and follow the instructions in 
references/sast.md
Integration: Save SAST findings for Consolidated Findings in the security report. Findings do not affect main section scores.
目标：针对检测到的项目类型，运行基础的SAST风格grep，查找OWASP漏洞模式（SQL注入、XSS、路径遍历、eval/代码注入）。结果将作为LOW/MEDIUM严重程度纳入综合发现。
阅读并遵循
references/sast.md
中的说明
集成：保存SAST结果供安全报告的综合发现部分使用。结果不影响主要部分的得分。

Step 9. Gemini AI Security Analysis (Optional)

步骤9. Gemini AI安全分析（可选）

Goal: Execute advanced AI-powered security analysis using the Gemini CLI Security extension if available.
Read and follow the instructions in 
references/gemini-analysis.md
Integration: Save Gemini analysis findings for the security report. Skip gracefully if Gemini CLI is unavailable.
目标：如果可用，使用Gemini CLI安全扩展执行高级AI驱动的安全分析。
阅读并遵循
references/gemini-analysis.md
中的说明
集成：保存Gemini分析结果供安全报告使用。如果Gemini CLI不可用，优雅地跳过。

Step 10. Generate Security Report

步骤10. 生成安全报告

Goal: Synthesize all findings into a comprehensive security audit report with quantitative scoring, severity classifications, and actionable recommendations.
Read and follow the instructions in 
references/report-generator.md
Integration: This rule integrates all previous analysis results and generates the final security report. You MUST compute all 5 section scores using the scoring rubrics BEFORE writing any report content. A report without computed scores is INVALID.
Report Sections (13 sections with quantitative scoring):
  • Security Scoring Breakdown (5 scored lines with weights + Overall + Formula + Posture)
  • Executive Summary with Overall Score
  • Scored Detail Sections (5 sections, dynamically ordered by score ascending — lowest first):
    • Sensitive File Protection (scored, weight 25%)
    • Secret Detection (scored, weight 30%)
    • Dependency Security (scored, weight 20%)
    • Supply Chain Integrity (scored, weight 10%)
    • Security Automation & CI/CD (scored, weight 15%)
  • Consolidated Findings by Severity (HIGH, MEDIUM, LOW)
  • Remediation Priority Matrix
  • Gemini AI Analysis results (if available)
  • Project Detection Results
  • Appendix: Evidence Index
  • Scan Metadata
Scoring Requirement: Every scored section MUST include: Score line with [Score]/100 ([Label]) format, Score Breakdown (Base, deductions/additions, Final), Key Findings, Evidence, Risks, and Recommendations.
目标：将所有发现整合为一份全面的安全审计报告，包含量化评分、严重程度分类和可执行建议。
阅读并遵循
references/report-generator.md
中的说明
集成：本规则整合所有先前的分析结果并生成最终安全报告。在撰写任何报告内容前，您必须使用评分标准计算所有5个部分的得分。缺少计算得分的报告视为无效。
报告部分（13个部分，包含量化评分）：
  • 安全评分明细（5个带权重的得分项 + 总体得分 + 计算公式 + 安全态势）
  • 包含总体得分的执行摘要
  • 得分详情部分（5个部分，按得分升序动态排序——最低分在前）：
    • 敏感文件保护（已评分，权重25%）
    • 密钥检测（已评分，权重30%）
    • 依赖项安全（已评分，权重20%）
    • 供应链完整性（已评分，权重10%）
    • 安全自动化与CI/CD（已评分，权重15%）
  • 按严重程度分类的综合发现（HIGH、MEDIUM、LOW）
  • 修复优先级矩阵
  • Gemini AI分析结果（如果可用）
  • 项目检测结果
  • 附录：证据索引
  • 扫描元数据
评分要求：每个已评分部分必须包含：[得分]/100（[标签]）格式的得分行、得分明细（基础分、扣分项/加分项、最终分）、关键发现、证据、风险和建议。

Step 11. Validate and Export Security Report

步骤11. 验证并导出安全报告

Goal: Validate the generated report against structural and formatting rules, then save the final plain-text report.
Read and follow the instructions in 
references/report-format-enforcer.md
Validation: Read the generated report and validate ALL structural checks from the format enforcer rule: exactly 13 sections, Section 1 has 5 scored lines with weights + Overall + Formula + Posture, Sections 3-7 have Score lines, sections are ordered by score ascending, score labels match ranges, no markdown syntax. Fix any issues in-place. If scores are missing entirely, re-run step 10 before exporting.
Export: Save the validated report to 
./reports/security_audit.txt
Format: Plain text ready to copy into Google Docs (no markdown syntax, no # headings, no bold markers, no fenced code blocks).
Command:
bash
mkdir -p reports
目标：根据结构和格式规则验证生成的报告，然后保存最终的纯文本报告。
阅读并遵循
references/report-format-enforcer.md
中的说明
验证：阅读生成的报告并验证格式强制规则中的所有结构检查：恰好13个部分，第1部分包含5个带权重的得分项 + 总体得分 + 计算公式 + 安全态势，第3-7部分有得分行，部分按得分升序排列，得分标签匹配范围，无markdown语法。就地修复任何问题。如果完全缺少得分，在导出前重新运行步骤10。
导出：将验证后的报告保存到
./reports/security_audit.txt
格式：可直接复制到Google Docs的纯文本（无markdown语法、无#标题、无粗体标记、无代码块）。
命令：
bash
mkdir -p reports

Save validated report to ./reports/security_audit.txt

Save validated report to ./reports/security_audit.txt

undefined
undefined

Execution Summary

执行摘要

Total Rules: 10 analysis rules + 1 format enforcement rule
Rule Execution Order:
  1. Read and follow the instructions in 
    references/tool-installer.md
    (MANDATORY - tool detection)
  2. Read and follow the instructions in 
    references/file-analysis.md
  3. Read and follow the instructions in 
    references/secret-patterns.md
  4. Read and follow the instructions in 
    references/gitleaks.md
    (optional - skips if Gitleaks not installed)
  5. Read and follow the instructions in 
    references/dependency-audit.md
  6. Read and follow the instructions in 
    references/dependency-age.md
  7. Read and follow the instructions in 
    references/trivy.md
    (optional - skips if Trivy not installed)
  8. Read and follow the instructions in 
    references/sast.md
    (SAST OWASP patterns, LOW/MEDIUM findings)
  9. Read and follow the instructions in 
    references/gemini-analysis.md
    (optional - skips if Gemini unavailable)
  10. Read and follow the instructions in 
    references/report-generator.md
    (generates 13-section report with quantitative scoring)
Post-Generation: Read and follow the instructions in 
references/report-format-enforcer.md
to validate and fix the report (runs automatically after step 10)
Scoring System:
  • 5 scored sections with weighted rubrics (0-100 each)
  • Overall Score computed via weighted formula
  • Security Posture mapped from Overall Score: Strong (85-100), Fair (70-84), Weak (50-69), Critical (0-49)
  • Security Scoring Breakdown provides immediate CTO-level visibility
  • Scored sections ordered by score ascending (weakest areas first)
Benefits of Modular Approach:
  • Each rule can be executed independently
  • Framework-agnostic with runtime project detection
  • Outputs can be saved and reused
  • Gemini analysis is optional and gracefully degraded
  • Clear separation of concerns
  • Quantitative scoring enables objective comparison across audits
  • Works as standalone or after health audit
总规则数：10个分析规则 + 1个格式强制规则
规则执行顺序：
  1. 阅读并遵循
    references/tool-installer.md
    中的说明（强制 - 工具检测）
  2. 阅读并遵循
    references/file-analysis.md
    中的说明
  3. 阅读并遵循
    references/secret-patterns.md
    中的说明
  4. 阅读并遵循
    references/gitleaks.md
    中的说明（可选 - 如果未安装Gitleaks则跳过）
  5. 阅读并遵循
    references/dependency-audit.md
    中的说明
  6. 阅读并遵循
    references/dependency-age.md
    中的说明
  7. 阅读并遵循
    references/trivy.md
    中的说明（可选 - 如果未安装Trivy则跳过）
  8. 阅读并遵循
    references/sast.md
    中的说明（SAST OWASP模式，LOW/MEDIUM严重程度发现）
  9. 阅读并遵循
    references/gemini-analysis.md
    中的说明（可选 - 如果Gemini不可用则跳过）
  10. 阅读并遵循
    references/report-generator.md
    中的说明（生成包含量化评分的13部分报告）
生成后操作：阅读并遵循
references/report-format-enforcer.md
中的说明验证并修复报告（步骤10后自动运行）
评分系统：
  • 5个带加权评分标准的已评分部分（每个0-100分）
  • 总体得分通过加权公式计算
  • 安全态势根据总体得分映射：Strong（85-100）、Fair（70-84）、Weak（50-69）、Critical（0-49）
  • 安全评分明细为CTO级提供即时可见性
  • 已评分部分按得分升序排列（最弱区域在前）
模块化方法的优势：
  • 每个规则可独立执行
  • 与框架无关，支持运行时项目检测
  • 输出可保存并重用
  • Gemini分析为可选，支持优雅降级
  • 关注点清晰分离
  • 量化评分支持审计间的客观比较
  • 可独立运行或在健康审计后运行