适用范围与判断依据
本文讨论涉及区块链系统开发、集成及智能合约交付的服务采购，不涉及数字资产交易。NIST的网络安全供应链风险管理摘要强调，应识别、评估和缓解所采购产品及服务的供应链风险。以太坊开发者安全文档则指出，合约权限、测试及独立审查需要配合使用，审计不能发现所有漏洞。这些原则可用于设计采购检查项，但不代表具体服务已经安全达标。
误区一：先选区块链产品，再补业务需求
采购对象不应只是“上链”功能，而应是明确的业务能力。需求阶段需要界定参与方、数据来源、操作权限和异常处理方式，再判断区块链是否适配。链上记录并不能单独证明输入数据真实，因此数据采集与审核责任也应进入需求范围。
误区二：只考察供应商，不追问技术依赖
供应商能完成演示，不等于其开发、集成和部署过程具有足够透明度。评估时可要求说明关键软件组件、外部接口及运维依赖，并明确谁负责漏洞处理与版本维护。检查深度应随系统重要性和服务边界调整，不必对所有采购采用同一套要求。
误区三：有审计报告就可以直接验收
审计是补充审查，不是安全承诺。验收需要核对报告覆盖的代码版本、检查范围、遗留问题及整改结果，避免报告与实际部署内容脱节。对智能合约，还应结合功能测试、异常输入测试和权限测试；采用形式化验证时，也要说明所验证的性质与假设，不能据此推断整个系统没有风险。
误区四：去中心化意味着无需管理权限
暂停、升级等敏感操作仍可能依赖管理员账户。采购文件应明确权限归属、授权边界以及密钥保管和交接责任。角色分离或多签可降低部分单点风险，但效果取决于实际配置和执行安排，并非增加账户数量就自动获得安全性。
误区五：上线交付就是服务结束
交付条件还应覆盖监控、事件响应、漏洞通报和维护责任。合约能否升级、谁有权批准变更，以及无法直接修补时如何处置，都应提前约定，不能默认链上代码与普通后台软件具有相同的修复方式。
常见问题：如何把要求变成验收依据
可将每项重要需求对应到明确证据，例如权限配置记录、测试结果、部署版本和问题整改记录。没有智能合约开发的采购，可缩减合约代码检查，但仍需评估集成与运维风险。判断重点是交付物是否满足约定条件，而不是是否拥有某个技术标签或单份报告。