审计范围是否明确
讨论区块链和审计方法有哪些常见问题，首先需要明确审计对象。本文聚焦智能合约与技术安全评估，不涉及财务报表审计。合约代码、管理权限和外围系统具有不同的检查重点，报告应说明覆盖对象、版本及未检查部分。
以太坊开发者安全文档强调权限控制、测试和独立审查；NIST SP 800-115则从通用信息安全角度说明测试规划、发现分析和缓解措施。前者适用于合约安全讨论，后者提供评估流程参考，不能直接作为某个区块链项目安全的证明。
单一方法能否发现全部问题
单元测试适合检查明确输入下的预期行为，但遗漏的边界条件不会自动成为测试目标。静态分析检查代码结构和潜在执行路径；动态测试通过运行代码观察异常；模糊测试可用大量变化输入探索意外行为。方法之间需要互补。
人工审查适合结合业务规则检查设计是否合理。例如，某个操作在代码层面可以正常完成，仍可能违背权限要求。审计需要先明确允许谁做什么，再判断实现是否符合要求。
形式化验证是否意味着绝对安全
形式化验证适合检查能够明确描述的安全性质，例如特定状态约束是否始终成立。其结论取决于规格、模型和假设，不能扩展为整个系统不存在任何漏洞。
如果规格遗漏了关键业务限制，即使证明成立，也没有回答被遗漏的问题。因此，审计既要检查实现，也要审查验证目标是否准确、完整。
权限检查为何容易出现盲区
函数可被外部调用，并不代表任何调用者都应获准执行敏感操作。权限审查需要覆盖身份检查、角色分配以及管理权变更。仅有访问控制代码，还不足以证明实际配置合理。
单一管理员涉及密钥失陷的集中风险。角色分离和多签可用于分散部分管理权，但效果取决于权限如何分配、签名者是否独立以及执行门槛如何设置。
审计完成后是否还需要复核
独立审计能够增加发现问题的机会，但结果受检查范围和方法限制。阅读报告时，应区分发现的问题、完成的修复与仍未解决的事项，不能只看是否存在审计报告。
整改后需要验证原问题是否消除，并检查修改是否引入新的影响。代码或权限配置发生变化时，也应重新判断原有结论是否适用。有效的审计应把检查、分析、修复和复核连接起来。