Back to Details

code-audit-readonly

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Audit Readonly

只读代码审计

Run a full technical repository audit in read-only mode and record everything in 
improvements.md
.
以只读模式运行完整的技术仓库审计，并将所有内容记录在
improvements.md
中。

Mandatory rules

强制规则

  1. Operate in read-only mode for the audited project.
  2. Do not edit source code, configs, or tests in the audited project.
  3. Do not run automatic refactors, formatters that write to disk, or destructive commands.
  4. Allow only the creation/update of 
    improvements.md
    as the final audit output.
  5. Do not ask for confirmation to proceed with the audit; execute the plan end to end.
  6. Record every validated finding; do not impose arbitrary limits.
  7. If multiple locations share the same issue pattern, still register every location with explicit file and line references.
  8. This audit is intentionally slow: prioritize depth, evidence quality, and completeness over speed.
  9. Do not optimize for fast turnaround if that reduces analysis coverage or confidence.
  1. 对被审计项目以只读模式操作。
  2. 不得编辑被审计项目的源代码、配置文件或测试代码。
  3. 不得运行自动重构、会写入磁盘的格式化工具或破坏性命令。
  4. 仅允许创建/更新
    improvements.md
    作为最终审计输出。
  5. 无需请求确认即可执行审计计划，从头到尾完成流程。
  6. 记录所有经过验证的发现；不得设置任意限制。
  7. 如果多个位置存在相同的问题模式，仍需为每个位置注册记录，并明确标注文件和行号引用。
  8. 本次审计刻意追求全面性：优先保证深度、证据质量和完整性，而非速度。
  9. 不得为了快速交付而降低分析覆盖范围或可信度。

Mandatory analysis scope

强制分析范围

  1. Correctness and logic
    1. Detect obvious and subtle bugs.
    2. Check for race conditions, inconsistent states, and incorrect async/concurrency usage.
    3. Evaluate error/exception handling, nullability, typing, and unsafe conversions.
    4. Cover edge flows and extreme scenarios.
  2. Performance
    1. Find unnecessary allocations, expensive loops, N+1 patterns, excessive I/O, and repeated work.
    2. Check for caching opportunities and inappropriate data structures.
    3. Correlate bottlenecks across modules.
  3. Duplication and maintainability
    1. Detect literal duplication and logical duplication.
    2. Identify long functions, mixed responsibilities, and excessive coupling.
    3. Flag confusing internal APIs, ambiguous names, and outdated comments.
  4. Security (mandatory, thorough)
    1. Hardcoded secrets (tokens, keys, passwords, sensitive endpoints).
    2. Injection vectors (SQL/NoSQL/command/template).
    3. XSS, CSRF, SSRF, open redirect, path traversal.
    4. Insecure uploads (insufficient type/size/validation checks).
    5. Authentication/authorization issues (bypass, missing checks, privilege escalation).
    6. Insufficient validation/sanitization.
    7. Weak cryptography and inadequate hashing.
    8. Insecure configurations (overly broad CORS, missing headers, debug in production).
    9. Vulnerable dependencies and problematic versions.
    10. Sensitive data leakage in logs, errors, and telemetry.
  5. Observability and reliability
    1. Validate log quality without exposing secrets.
    2. Verify metrics/tracing where applicable.
    3. Evaluate consistency and actionability of error messages.
  6. Tests and quality
    1. Identify coverage gaps in critical areas.
    2. Detect brittle tests and missing integration coverage.
    3. Map untested edge cases.
  1. 正确性与逻辑
    1. 检测明显和潜在的Bug。
    2. 检查竞争条件、不一致状态以及异步/并发使用不当的问题。
    3. 评估错误/异常处理、空值处理、类型检查和不安全的类型转换。
    4. 覆盖边缘流程和极端场景。
  2. 性能
    1. 找出不必要的内存分配、低效循环、N+1查询模式、过度I/O操作和重复执行的任务。
    2. 检查可缓存的场景和不合适的数据结构。
    3. 关联跨模块的性能瓶颈。
  3. 代码重复与可维护性
    1. 检测字面重复和逻辑重复的代码。
    2. 识别过长函数、职责混合和过度耦合的问题。
    3. 标记易混淆的内部API、模糊的命名和过时的注释。
  4. 安全（强制且全面）
    1. 硬编码的密钥（令牌、密钥、密码、敏感端点）。
    2. 注入漏洞（SQL/NoSQL/命令/模板注入）。
    3. XSS、CSRF、SSRF、开放重定向、路径遍历。
    4. 不安全的上传（类型/大小/验证检查不足）。
    5. 认证/授权问题（绕过、缺失检查、权限提升）。
    6. 验证/ sanitization不足。
    7. 弱加密和不充分的哈希算法。
    8. 不安全的配置（过于宽松的CORS、缺失安全头、生产环境启用调试模式）。
    9. 存在漏洞的依赖和有问题的版本。
    10. 日志、错误信息和遥测中的敏感数据泄露。
  5. 可观测性与可靠性
    1. 在不暴露密钥的前提下验证日志质量。
    2. 验证指标/跟踪功能（如适用）。
    3. 评估错误信息的一致性和可操作性。
  6. 测试与质量
    1. 识别关键区域的测试覆盖缺口。
    2. 检测脆弱的测试用例和缺失的集成测试覆盖。
    3. 梳理未覆盖的边缘场景。

Execution method

执行方法

  1. Map the repository tree and list all relevant files:
    1. Application code, internal libraries, configs, scripts, CI, Docker, IaC, migrations, and tests.
  2. Initialize 
    improvements.md
    with:
    1. A short system summary inferred from the structure.
    2. A "Progress Tracking" section with all relevant files marked as 
      pending
      .
    3. Severity and category conventions.
  3. Review each file sequentially and deterministically:
    1. Read the entire file.
    2. Record specific findings and correlate with related imports/calls/contracts.
    3. Update progress tracking.
    4. Explicitly record: 
      File fully reviewed: <path/to/file>
      .
    5. Before moving to the next file, run a quick self-check for missed edge cases, security vectors, and cross-file impacts.
  4. Run read-only auxiliary checks when useful:
    1. Static analysis, linter, and typecheck in read-only mode.
    2. Run tests without writing to disk.
    3. Dependency/CVE audit.
  5. Close 
    improvements.md
    with:
    1. A complete finding inventory (all findings captured during the audit).
    2. A prioritized backlog that references finding IDs and contains no artificial cap.
    3. A detailed phased remediation plan (see "Detailed planning requirements").
    4. A brief completeness checkpoint describing what was verified to ensure no relevant area was rushed or skipped.
  1. 梳理仓库目录结构并列出所有相关文件：
    1. 应用代码、内部库、配置文件、脚本、CI配置、Docker文件、IaC、迁移脚本和测试代码。
  2. 初始化
    improvements.md
    ，包含：
    1. 从结构推断出的简短系统概述。
    2. “进度跟踪”部分，所有相关文件标记为
      pending
      。
    3. 严重程度和类别的约定。
  3. 按顺序、确定性地审核每个文件：
    1. 阅读整个文件。
    2. 记录具体发现，并关联相关的导入/调用/契约。
    3. 更新进度跟踪。
    4. 明确记录：
      File fully reviewed: <path/to/file>
      。
    5. 在切换到下一个文件前，快速自我检查是否遗漏边缘场景、安全风险和跨文件影响。
  4. 必要时运行只读辅助检查：
    1. 静态分析、代码检查和类型检查（只读模式）。
    2. 运行测试但不写入磁盘。
    3. 依赖/CVE审计。
  5. 完成
    improvements.md
    的最终内容：
    1. 完整的发现清单（审计过程中捕获的所有发现）。
    2. 包含所有发现的优先级待办事项，引用发现ID且无人工限制。
    3. 详细的分阶段修复计划（见“详细规划要求”）。
    4. 简短的完整性检查说明，描述已验证的内容，确保没有相关区域被仓促处理或跳过。

Progress tracking

进度跟踪

Apply these rules to keep progress tracking clear and stable:
  1. Build a canonical file list once:
    1. Normalize paths (
      ./
      removed, no trailing slash, consistent case as seen on disk).
    2. Sort the list before writing "Progress Tracking".
  2. Keep exactly one progress row per canonical file path.
  3. Update progress in-place:
    1. Change the existing row status (
      pending
      -> 
      in_progress
      -> 
      reviewed
      ).
    2. Never append a second row for the same file.
  4. Write 
    File fully reviewed: <path/to/file>
    exactly once per file.
  5. If a file is revisited, add notes under the same file entry; do not create a new checklist row or a second 
    File fully reviewed
    line.
  6. Before finishing, validate:
    1. Number of 
      reviewed
      rows == number of unique relevant files.
    2. "Progress Tracking" appears exactly once in the report.
    3. Every finding location appears in at least one reviewed file entry.
遵循以下规则保持进度跟踪清晰稳定：
  1. 一次性构建标准文件列表：
    1. 标准化路径（移除
      ./
      ，无末尾斜杠，与磁盘上的大小写保持一致）。
    2. 在写入“进度跟踪”前对列表排序。
  2. 每个标准文件路径对应唯一的进度行。
  3. 原地更新进度：
    1. 修改现有行的状态（
      pending
      -> 
      in_progress
      -> 
      reviewed
      ）。
    2. 切勿为同一文件添加第二行。
  4. 每个文件仅写入一次
    File fully reviewed: <path/to/file>
    。
  5. 如果重新查看某个文件，在同一文件条目下添加注释；不要创建新的检查行或第二条
    File fully reviewed
    记录。
  6. 完成前验证： 
    1. reviewed
      状态的行数 == 唯一相关文件的数量。
    2. 报告中“进度跟踪”部分仅出现一次。
    3. 每个发现的位置至少出现在一个已审核的文件条目中。

Example report structure

示例报告结构

Use this high-level structure to keep the report consistent and to ensure a single "Progress Tracking" section:
markdown
undefined
使用以下高层级结构保持报告一致，并确保仅包含一个“进度跟踪”部分：
markdown
undefined

improvements.md

improvements.md

1. System summary

1. System summary

  • Inferred architecture and main modules.
  • Main risk surfaces.
  • Inferred architecture and main modules.
  • Main risk surfaces.

2. Conventions

2. Conventions

  • Categories and severity scale used in the audit.
  • Finding ID convention (
    A001
    , 
    A002
    , ...).
  • Categories and severity scale used in the audit.
  • Finding ID convention (
    A001
    , 
    A002
    , ...).

3. Progress Tracking

3. Progress Tracking

  • path/to/file-a.ext
  • path/to/file-b.ext
  • path/to/file-c.ext
  • path/to/file-a.ext
  • path/to/file-b.ext
  • path/to/file-c.ext

4. Complete finding inventory

4. Complete finding inventory

A001

A001

Category: ... Severity: ... Location: ... Problem: ... Impact: ... Suggestion: ... Correlation notes: ... Security (if applicable): ...
Category: ... Severity: ... Location: ... Problem: ... Impact: ... Suggestion: ... Correlation notes: ... Security (if applicable): ...

A002

A002

...
...

5. Prioritized backlog (all findings)

5. Prioritized backlog (all findings)

  • Priority 1: A00X, A00Y...
  • Priority 2: A00Z...
  • Priority 1: A00X, A00Y...
  • Priority 2: A00Z...

6. Detailed phased remediation plan

6. Detailed phased remediation plan

Phase 1

Phase 1

  • Objective
  • Findings included
  • Dependencies
  • Validation gates
  • Exit criteria
  • Objective
  • Findings included
  • Dependencies
  • Validation gates
  • Exit criteria

Phase 2

Phase 2

...
...

Phase 3

Phase 3

...
undefined
...
undefined

Categories and severity

类别与严重程度

Use only these categories:
  • Bug
  • Performance
  • Security
  • Duplication
  • Code Quality
  • Architecture
  • Maintainability
  • Observability
  • Tests
  • Dependencies
Use only these severity levels:
  • Critical
  • High
  • Medium
  • Low
仅使用以下类别：
  • Bug
  • Performance
  • Security
  • Duplication
  • Code Quality
  • Architecture
  • Maintainability
  • Observability
  • Tests
  • Dependencies
仅使用以下严重程度级别：
  • Critical
  • High
  • Medium
  • Low

Mandatory format for each finding

每个发现的强制格式

Use unique sequential IDs (
A001
, 
A002
, ...).
text
A0XX
Category: <...>
Severity: <Critical|High|Medium|Low>
Location: <file>:<start line>-<end line>
Problem: <objective description>
Impact: <real or potential impact>
Suggestion: <high-level fix, without editing code>
Correlation notes: <related files/flows>
Security (if applicable): <plausible abuse scenario + mitigation>
使用唯一的连续ID（
A001
, 
A002
, ...）。
text
A0XX
Category: <...>
Severity: <Critical|High|Medium|Low>
Location: <file>:<start line>-<end line>
Problem: <objective description>
Impact: <real or potential impact>
Suggestion: <high-level fix, without editing code>
Correlation notes: <related files/flows>
Security (if applicable): <plausible abuse scenario + mitigation>

Detailed planning requirements

详细规划要求

The planning phase in 
improvements.md
must be explicit and implementation-oriented. Use this structure:
  1. Planning assumptions and constraints:
    1. Confirm read-only audit boundaries.
    2. List unknowns that may affect remediation sequencing.
  2. Prioritized backlog (complete):
    1. Include all findings (
      A001...A0XX
      ) with:
      1. Priority order.
      2. Estimated effort (
        S
        , 
        M
        , 
        L
        ) with a short rationale.
      3. Primary risk type (
        Correctness
        , 
        Security
        , 
        Performance
        , 
        Reliability
        , 
        Maintainability
        ).
  3. Phase plan with objective and controls:
    1. For each phase, include:
      1. Objective.
      2. Findings included (explicit ID list).
      3. Dependencies and ordering constraints.
      4. Validation gates (tests/checks/evidence expected after fixes).
      5. Exit criteria (what must be true to close the phase).
  4. Sequencing rules:
    1. Resolve 
      Critical
      and exploitable 
      High
      security/correctness findings first.
    2. Schedule performance and maintainability work after risk containment unless blocking.
    3. Call out parallelizable workstreams and non-parallelizable bottlenecks.
  5. Delivery roadmap:
    1. Provide a suggested execution order by batch/wave.
    2. For each batch, list expected risk reduction and verification focus.
improvements.md
中的规划部分必须明确且面向实施。使用以下结构：
  1. 规划假设与约束：
    1. 确认只读审计的边界。
    2. 列出可能影响修复顺序的未知因素。
  2. 完整的优先级待办事项：
    1. 包含所有发现（
      A001...A0XX
      ），并附带：
      1. 优先级顺序。
      2. 预估工作量（
        S
        , 
        M
        , 
        L
        ）及简短理由。
      3. 主要风险类型（
        Correctness
        , 
        Security
        , 
        Performance
        , 
        Reliability
        , 
        Maintainability
        ）。
  3. 包含目标与控制措施的阶段计划：
    1. 每个阶段包含：
      1. 目标。
      2. 包含的发现（明确的ID列表）。
      3. 依赖关系和顺序约束。
      4. 验证 gate（修复后预期的测试/检查/证据）。
      5. 退出标准（完成阶段必须满足的条件）。
  4. 排序规则：
    1. 优先解决
      Critical
      和可被利用的
      High
      级别安全/正确性发现。
    2. 除非存在阻塞，否则在风险控制后安排性能和可维护性工作。
    3. 指出可并行的工作流和不可并行的瓶颈。
  5. 交付路线图：
    1. 按批次/阶段提供建议的执行顺序。
    2. 为每个批次列出预期的风险降低效果和验证重点。

Traceability requirements

可追溯性要求

  1. Make every finding traceable to file and line/section.
  2. Avoid generic recommendations without evidence.
  3. Register all validated findings found during the audit, including low-severity and repeated-location findings.
  4. Explicitly record uncertainties when evidence is partial.
  1. 每个发现必须可追溯到文件和行/章节。
  2. 避免无证据的通用建议。
  3. 记录审计过程中发现的所有经过验证的发现，包括低严重程度和重复位置的发现。
  4. 当证据不完整时，明确记录不确定性。

Completion criteria

完成标准

Finish only when:
  1. All relevant files are marked as reviewed in Progress Tracking.
  2. Each reviewed file has the line 
    File fully reviewed: ...
    .
  3. improvements.md
    contains the complete finding inventory, a prioritized backlog, and a detailed phased plan.
  4. The audited project remains intact, with only 
    improvements.md
    as the audit output artifact.
仅在满足以下条件时结束：
  1. 所有相关文件在进度跟踪中标记为已审核。
  2. 每个已审核文件都有
    File fully reviewed: ...
    记录。
  3. improvements.md
    包含完整的发现清单、优先级待办事项和详细的分阶段计划。
  4. 被审计项目保持完整，仅生成
    improvements.md
    作为审计输出产物。