先区分资料能证明什么
区块链审计安全资料的核验，关键不是寻找一个权威标识，而是判断证据是否支持相应结论。通用指南解释安全方法，开发框架说明流程要求，具体审计报告才可能说明某段代码接受了哪些检查。三者不能互相替代。
以下核验方法主要适用于智能合约安全资料和软件开发流程材料，不构成对任何具体项目的安全认定。
两个来源的用途与边界
Ethereum 智能合约安全文档讨论访问控制、测试和独立审查，并提醒审计不能发现所有漏洞。它适合用于理解合约安全检查的基本方向，不能证明某个项目已经接受审计或不存在风险。
NIST SP 800-218 的 SSDF 1.1 是安全软件开发框架，强调将安全实践融入开发生命周期，以减少漏洞及其影响、处理漏洞根因。它可用于理解流程层面的安全要求，并非某个区块链项目的审计证明。
核对发布主体与文档身份
核验时应记录原始发布地址、发布机构、文档名称和版本，区分原文、译文、转载与摘录。上述资料对应 ethereum.org 的智能合约安全页面，以及 csrc.nist.gov 的 SP 800-218 发布页面。仅凭截图或机构标识，不能确定内容完整且未经修改。
文档编号、版本与发布日期应相互对应。HTTPS 主要保护连接传输，不能单独证明网页中的每项说法正确；历史版本也不能自动代表当前适用要求。
把项目结论对应到具体证据
若核验对象是具体项目，应进一步检查报告是否标明代码仓库、提交版本、审查范围和排除项。项目名称相同，不代表部署代码与受审代码一致；后续修改和升级也可能超出原审计范围。
对于漏洞处理，需要区分发现问题、声称修复和修复后复核。核验记录宜保留对应报告位置与代码版本。缺少这些信息时，应写明尚不能确认，而不是推定问题已解决。
常见问题：权威来源是否足够
两个独立来源能否直接证明项目安全？不能。独立性有助于比较观点，但不同来源可能只讨论一般原则，未检查同一项目。交叉核验必须围绕同一个待证实的命题。
通过测试或形式化验证是否意味着绝对安全？不能这样概括。测试受用例覆盖限制，形式化验证的结论依赖明确的规格、模型和假设。可靠表述应交代检查对象、适用条件和未覆盖范围，而不是将有限证据扩展为整体安全保证。