安全审计：对照报告范围与已部署代码

安全审计报告支持的是一次范围明确的检查，不是对所有同名部署的永久安全证明。研究时应把报告的代码范围、版本、发现和假设，与当前相关合约逐项对照，交付一张范围差异表。

Ethereum 智能合约安全指南介绍安全实践和审查作用，但不认证任何具体协议。项目宣称经过审计时，要追到原始报告及其对应代码，不能停在宣传徽章。

确认报告身份与范围

记录审查机构、日期、对象、仓库、提交或发布标识、包含文件及排除组件。优先读原报告，审计公司标识列表不能告诉你每一家到底审查了什么。

同时阅读假设。报告可能假定管理员可信、使用特定预言机、依赖某版本组件，或按某种部署参数运行。如果实际系统不同，报告仍可能有价值，但必须解释差异，不能直接照搬结论。

不要把表格压缩为问题数量排名。发现较多可能与范围和深度相关，发现较少也可能只是范围狭窄，没有上下文不能直接比较。

假设虚构项目发布提交 A 的报告，范围包括金库，明确排除桥接集成。当前部署对应提交 B，其中更改一段记账逻辑，面向用户的产品又依赖那座桥。

正确结论不是报告毫无价值。它仍支持特定版本和范围的审查，但新增记账变化与被排除集成形成证据缺口。下一步应请求版本差异、后续报告或其他相关材料，不宣称新部署已经被覆盖。

如果某发现被标为已解决，还要核实修复是否进入实际部署。报告状态属于审查过程，不自动证明当前配置。以上情景完全是假设，不针对真实项目。

重要发现应保存问题描述、受影响组件、缓解方式和审查者回应。把“接受风险”与“验证代码修复”分开，团队接受风险不意味着风险消失，只说明在该检查中作出了一项决定。

后续升级改变已审查行为时，保留原报告作为历史证据，再添加新版本复核触发项。只看当前徽章，可能看不到中间已经发生多次修改。

还要识别代码范围外的控制，例如特权密钥、部署脚本、前端路由、托管和外部依赖。除非报告明确纳入，不能假设合约审查覆盖它们。研究笔记也应注明自己的范围，不把阅读报告说成重新完成安全审计。

公开报告可能省略保密信息，或缺少版本映射。如果无法把部署字节码与审查源码对应，就把关系标为待核。没有公开发现，不证明不存在漏洞；审查完成，也不保证未来行为。

常见错误包括只看机构标识、把旧报告套到新实现、把全部已解决标签当作部署修复，以及把窄范围代码检查当成整体运营安全评估。结论应说明审了什么、哪些与部署一致、哪些重要差异未解决，而不是给保证性安全等级或现货投资结果。

不是。它是带范围、假设和限制的审查，部署变化和范围外风险仍需检查。

不应忽略。保留相关历史发现，再定位具体变化，并寻找能覆盖差异的后续证据。