先明确：核验的是哪一种说法
“区块链通过安全审计”容易混淆审查对象：被审查的可能是某组智能合约，也可能是其他软件组件，并不必然覆盖整个系统。核验时应先明确项目名称、审查对象和报告结论，再判断宣传是否超出了证据范围。
本文适用于智能合约及相关软件审计资料的真实性与适用范围核验，不对任何具体项目是否通过审计作出判断。
两个参考来源分别能证明什么
Ethereum 智能合约安全指南将独立审计视为开发与测试之外的补充检查，并提醒审计无法发现所有缺陷。因此，不能把存在审计报告直接解释为系统绝对安全。参考地址：https://ethereum.org/developers/docs/smart-contracts/security/
NIST 的 SSDF 介绍安全软件开发实践，涉及组织准备、软件保护、安全开发与漏洞响应，也强调组件来源信息。它是理解开发过程的参考框架，不是某个区块链项目通过审计的证明。参考地址：https://csrc.nist.gov/projects/ssdf
这两个来源支持通用核验原则，不能相互叠加成具体项目的审计背书。项目层面的结论仍需要对应的原始报告与版本证据。
核验发布主体与原始报告
优先寻找审计机构自身发布或确认的完整报告，再与项目方提供的文件核对。重点检查项目名称、报告版本、发布日期、审计范围和结论是否一致。只有标志、截图、摘要或转载链接时，不宜认定审计声明已经得到充分核实。
核对域名有助于识别来源，但 HTTPS 只能说明连接受到保护，不能单独证明页面声明真实。若存在多个不同版本的报告，应确认修订关系，而不是只选择结论更有利的一份。
把报告对应到实际代码
建议记录报告列出的代码仓库、提交标识、文件范围和排除项，再核对这些信息与被宣传的软件版本是否对应。报告真实，并不意味着当前部署仍然运行被审查的代码。
涉及链上合约时，还应核对网络、合约地址及部署版本；存在可升级机制时，应关注实际使用的实现版本。无法建立对应关系时，准确表述应是“已有某版本审计资料”，而非“当前系统已获安全保证”。
检查问题状态与结论边界
阅读问题清单时，应区分已发现、已修复、经复核确认，以及接受风险或暂不处理等状态。项目方声称完成修复，与审计方确认修复有效，不是同一种证据。
审计结论还受范围、时间和假设条件限制。后续代码修改、依赖变化或配置调整，都可能需要重新评估。整理核验结果时，可以列出来源、版本、覆盖范围、复核记录和未解决疑点，避免用一个“通过”掩盖差异。
常见问题：缺少证据如何表述
没有公开报告是否代表没有审计？不能直接这样推断。更稳妥的结论是公开证据不足，尚无法独立核验。两个网站转发同一份声明，也不等于获得两项独立确认。
引用 Ethereum 安全指南或声称采用 SSDF，是否等于认证？不是。前者提供安全实践说明，后者提供开发框架；具体项目的审计状态，应由与该项目及其版本直接相关的证据支持。