ln-22-codebase-auditor

代码库审计

目标： 对生产代码开展全面、只读的健康审计。找出具体的跨领域故障、安全、交付和维护风险；不要将检测器匹配结果或个人风格偏好当作问题。此审计不能替代文档可信度、测试组合、整体架构或持久化专项审查。

执行约定： 按顺序排列的复选框即为完成定义。内部将每一项标记为 PENDING、PROVEN（有具体证据）、CLEARED（有证据表明其条件不存在）或 UNPROVEN（存在证据缺口）；阅读、委派或工具故障都不构成证明。每完成一个章节后都要核对各项。返回前，处理所有 PENDING 项，只统计 PROVEN 和 CLEARED 项；对每个缺口应用本技能的判定和审批规则。 保留用户意图、范围和现有授权。继续已获授权的工作；仅在存在尚未解决且影响重大的选择或需要外部审批时才询问。根据风险大小调整审查深度，不得悄然跳过检查。保留依赖关系和安全顺序；其他情况下，选择适合各项要求的验证方法。

工具路由

需求	首选工具	适用情况	后备方案
代码库概览和技术栈检测	原生文件列表、清单、构建文件和代码库说明	确定范围、生成内容区域、入口点、支持的运行时和命令	定向检查目录树和已知入口点
符号、调用方、归属和数据流	语言服务器或宿主原生代码智能工具	问题取决于符号身份、引用、重写、路由连接或跨文件行为	进行有限文本搜索，并直接检查所有相关匹配项
当前变更和历史背景	Git 状态、差异、日志和 blame	区分当前工作、回归、刻意设定的限制和失效的兼容路径	检查当前实现和明确的决策记录
交付健康状况	代码库定义的构建、lint、类型、测试和冒烟测试命令	确定项目能否在文档所述环境中交付	检查 CI 和脚本；将命令无法执行标记为不可用
依赖和安全状态	原生包管理器审计、清单、锁文件和官方公告	检查已知漏洞、不受支持的版本和依赖健康状况	查阅官方注册表和供应商来源；切勿猜测严重程度
运行时证据	现有日志、指标、跟踪记录、性能分析和诊断信息	静态分析无法确定发生频率、可达性或运行影响	分析调用路径，并明确说明仅基于静态分析的限制
当前外部行为	官方规范、供应商文档和发行说明	问题取决于当前 API、运行时或标准行为	通过网络搜索查阅一手来源；否则标记为 UNVERIFIED

从摘要级别的发现开始，再逐步缩小范围后深入阅读。仅运行代码库定义的或明确安全的诊断命令；审计期间绝不发布、部署、迁移生产数据、轮换密钥或重写文件。

证据规则

• 模式匹配只是候选项，不是问题。应确认其可达性、上下文和后果。
• 运行时故障或确定性的命令输出优先于静态疑点；若无法执行，静态证据仍然有效，但必须明确说明这一限制。
• 对生成代码、第三方代码、测试夹具、迁移历史和有意保留的兼容代码，应结合具体上下文处理。
• 只有在外部最佳实践能应对代码库中的具体缺陷或风险时，才具有可执行性。
• 只对根因不同的问题评分或计数；共享同一修正方案的症状应去重。

检查清单

1. 确定范围和基线

• 检测语言、框架、包管理器、入口点、部署模式、生成内容区域，以及仓库支持的验证命令。
• 在要求探测、遥测、信号处理或关闭行为之前，先将每个运行时界面归类为长期运行的服务、CLI、库、作业、无服务器函数或平台托管组件。
• 阅读适用的说明，识别安全边界、关键业务路径、公共接口和不可逆操作。
• 检查 Git 状态，确保审计不会覆盖、错误归属或忽略用户的其他更改。
• 确定可行的构建、lint、类型检查、测试和冒烟测试基线；记录已执行的范围、环境、退出状态和证据。确认必需的工作确实已运行，而不是因为未选择测试或跳过检查关卡而成功。
• 根据风险确定排除项和审查深度，而不是对每个文件一视同仁地扫描。
• 保持审计只读。仅允许使用获准的缓存和构建产物，并在创建时予以说明。

2. 审计安全和交付边界

• 搜索已提交的密钥、不安全的凭证模式、敏感默认值、调试绕过机制，以及通过日志或错误意外暴露信息的情况。
• 对于凭证相关发现，绝不暴露原始值：区分有效凭证与占位符、测试夹具、示例和允许列表中的指纹；仅报告类型、位置和已脱敏的证据。只有确认凭证已暴露时，才建议撤销、轮换或修复历史记录，并且审计期间不得执行这些操作。
• 追踪不可信输入流向 SQL、shell、模板、HTML、文件路径、URL、反序列化、重定向和其他易受注入攻击的接收点。
• 检查身份验证、授权、租户或所有权隔离、权限转换、不安全的直接对象访问，以及默认拒绝行为。
• 检查信任边界处的验证、规范化、大小和速率限制、不安全的文件操作，以及破坏性操作的确认或防护措施。
• 根据实际调用路径、框架行为、配置和当前官方指南核实安全问题，再判定严重性。
• 检查编译器、lint、类型检查器、测试、打包和 CI 配置，查找被跳过的关卡、被忽略的失败、环境漂移和不可复现的交付。
• 验证成功打包后是否生成了预期的入口点、资源、元数据、目标平台和可部署产物；仅退出码为零并不能证明构建产物可发布。
• 查找过时的跳过、隔离、允许失败、出错后继续和警告抑制路径，这些路径可能让必需的信号显示为绿色。
• 检查配置是否完整、必需环境是否经过验证、是否存在不安全的回退方案或缺失的示例，以及本地、CI 和部署设置之间的差异。

3. 审查可维护性和依赖项

• 查找函数、处理程序、模块、配置和集成代码中有证据支持的重复内容；区分共享的领域概念与偶然相似之处。
• 识别过度抽象、未使用的扩展点、过多的工厂或包装器、并行机制，以及重复实现已声明平台功能的自定义工具。
• 在合并重复内容或移除抽象之前，检查生命周期和所有权边界、有意的解耦、依赖注入或测试接缝、框架要求、公共扩展契约，以及预期的独立演进。
• 检查复杂度热点、过长的方法、巨型模块、过深的嵌套、过多的参数、布尔模式 API、易误导的名称，以及职责混杂的问题。
• 检查算法是否存在提前退出错误、重复键丢失、边界错误、工作量无上限、重复扫描、迭代期间修改数据，以及隐藏的共享状态。
• 检查硬编码的运维值、URL、超时、限制、标识符和特定环境行为，确认哪些应明确设为配置项或命名策略。
• 追踪一个概念在外部契约、DTO、服务、持久化和存储中的表现；只有在不存在明确的序列化器、代码生成或 ORM 边界映射时，才将同义词或大小写不一致列为问题。
• 审查依赖项漏洞、支持状态、许可证或运行时限制、重复包、未使用的包，以及切实可行的替换或移除机会。
• 将安全公告与已解析的版本和部署情况对应，再根据可达性和利用条件，将风险划分为已确认、未知或不适用；调用路径不可用并不能排除受影响组件的风险。
• 只有在检查所需功能的对等性、迁移范围、维护情况、许可证、安全历史和领域特定行为之后，才建议使用原生方案、现有依赖项或外部替代方案。
• 查找不可达代码、未使用的导入和导出、注释掉的实现、过时的标志、失效的兼容垫片，以及与替代实现并存的旧代码。
• 报告可安全删除之前，先结合反射、注册、框架发现、配置、序列化、模板和外部入口，确认死代码的判断。

4. 审查可诊断性、并发与生命周期

• 检查日志是否采用结构化格式、级别是否正确、是否可用于采取行动、能否在请求或任务间关联，以及是否不含机密和过多的负载数据。
• 验证关联上下文是否贯穿出站调用、队列、重试、计划任务和分离的异步边界，而非仅存在于首条请求日志中。
• 检查关键路径的指标、跟踪、健康信号和错误上下文；仅在运维人员需要借此检测或诊断故障时，才要求具备可观测性。
• 沿可达的并发路径，追踪共享可变状态、锁顺序、原子性、异步任务所有权、取消、重试和竞态窗口。
• 检查跨越 await 或 yield 点的读取－修改－写入操作，并为共享文件、子进程、终端或操作系统资源以及用户重复触发操作建立资源／访问方时间线；包括当前进程之外的访问方。
• 检查异步路径中的阻塞 I/O 或同步等待、无界并发、孤立任务、死锁、TOCTOU 风险和非线程安全资源。
• 检查启动顺序、依赖就绪状态、配置验证、快速失败行为、信号处理、优雅关闭和在途工作排空。
• 清点启动和运行期间获取的资源，并确保每项资源都能在成功、失败、超时、取消和重复收到关闭信号时，按安全的依赖逆序进行幂等清理。
• 验证主机特定的探针语义：存活探针失败应足以证明需要重启；就绪探针决定是否可接收流量；启动探针保护初始化过程。避免由依赖项触发的重启级联，以及会造成显著负载或副作用的探针。

5. 验证发现并报告

• 仅在会影响某项发现时，才研究外部 API、标准、漏洞和运行时行为；并使用与相关版本匹配的官方来源。
• 在确认候选问题前，排除框架惯例、生成代码、范围有限的管理路径、测试、示例和已记录的权衡。
• 尽可能通过安全命令、测试、最小调用跟踪或完整静态故障路径复现高严重性问题。
• 应用实质性门槛：要求有证据表明存在具体的故障、安全、交付、可运维性或反复出现的维护影响。排除品味、理论上的纯粹性、泛化实践、假设规模和合理替代方案；要求证明结果或约束，而非偏好的实现方式。
• 外部修正应以匹配版本的官方契约为依据；未解决的权衡应引用主要工程来源。引用有依据的机制；对于本地缺陷，本地证据即可。
• 根据可利用性、数据或可用性影响、交付阻塞、复发性和修复紧迫性，将发现归类为 P0-P3。
• 按风险降低程度和依赖关系排序修复项，而非按文件顺序或检测器类别排序。
• 若无法在没有可信替代方案的情况下验证必要的安全环境、高风险行为或权威契约，则使用 BLOCKED；若有证据表明仍存在未解决的 P0/P1、必要交付门禁失败或行为不安全，则使用 FAIL；仅对已验证的非阻塞风险使用 CONCERNS；只有在完成必要检查且未发现实质性问题时，才使用 PASS。

自检

• 返回前核对。 检查各项证据、需求覆盖情况、矛盾、范围、判定结果和适用的清理事项。修正报告或获准修改的产物。复用有效证据；不要自动重新扫描仓库或重新运行已成功的命令。仅在有相关变更、失败或未解决证据时重复检查。披露剩余差距。

输出约定

按用户使用的语言，依照以下顺序报告；保留全部五个字段，并且每项事实只陈述一次。简短结果可按每个字段一行呈现；省略空表格，不要复制链接的产物：

1. 结果： 技能专属判定及有依据的结果。
2. 范围： 已审查／变更的范围、排除项、基线及重要假设。
3. 证据： 以下技能专属字段；区分事实、推断和未经验证的声明。链接产物；适用时使用表格。
4. 验证： 检查／结果、无法获取的证据，以及适用的清理／外部状态。
5. 完成情况： Checklist: X/Y complete；Incomplete: None，或列出每项 UNPROVEN 的原因、对结果的影响及确切的后续操作；剩余风险和所需决策。

技能专属证据： 安全性、交付、可维护性／依赖项、可诊断性、并发性及生命周期证据。发现项需说明优先级、位置、触发条件或故障路径、置信度、实质影响、不可接受的权衡，以及预期工作量最小的修复方案；也接受其他有效的等效方案。按前置条件和风险降低程度排列修复顺序，而非按检测器数量排列。