安全审计服务是个系统性工程,合约之间的组合,合约的升级等任何变动都可能导致原先的审计工作变得“无意义”。
原文作者:@tmel0211
原文来源:X
注:原文来自@tmel0211发布长推。
大家或许注意到,OpenZeppelin、Safe等一些安全专家联名推出了ERC-7512标准,介绍了一种在on-chain环境下披露Audit Report的方法,并有统一的接口可供链上调用,旨在提高区块链行业的整体安全性。这事该如何解读呢?
在我看来,安全行业缺的并非透明报告,而是规范的审计流程和业务权责共识。简单说说:
1)直觉发现只有部分安全公司参与,比如Openzepplin、Safe等,国内知名的安全公司 SlowMist、BlockSec、Certik、PeckShield等并未表态,跟几个安全大佬简单聊了下,也都表示,目前尚是一种没有统一共识要推进这个,静待后续。
2)安全审计报告基于统一标准存放在链上,相比现在存放在Github上,唯一的作用可能就是防篡改了,但这一点需求并不刚性。审计公司给出的报告通常也受合作法律合同的条款约束,不太可能被恶意篡改,也没那个必要。
3)这个标准,我感觉目的是引导安全公司在链上输出统一格式、规范的审计报告内容,主要为了便于后续第三方公司做插件解析之类的服务(可解析性)。整体目的,是通过合约的调用的透明形式,提高审计报告的多场景曝光率。比如开发一款插件,在Etherscan查合约时都能自动解析出安全审计报告内容,同理在Uniswap等交易前端也可以集成报告可视化内容。不过,审计报告内容通常是滞后的,用户使用产品时去查看已经被解决的若干问题,也不那么刚性了,而且若一个项目被查出问题很多,多少会影响交互心理。
4)整体来说是个有意义的尝试,以此为出发点,逐步探索出审计报告——三方解析调用——插件前端曝光等一条安全审计曝光路径,最好再衍生出一套行之有效的“问责”体系,若参与的项目多,安全公司多,达成一定普及度之后会有效改善当前审计行业存在的乱象。
总之,安全审计服务是个系统性工程,合约之间的组合,合约的升级等任何变动都可能导致原先的审计工作变得“无意义”。
本质上,安全审计就是第三方安全公司利用专业度帮助项目方排查上线前问题,解决运营过程中的突发应急问题,并辅以其他工具、服务等帮助来提升项目的安全度。但毕竟是“外包”服务,不是终身全包无忧保障。
更多的安全隐患和风险排查断不能仅依赖安全公司,市场应该重视安全审计,但也不能太依赖安全审计,尤其是把审计当成背书的方式推向市场,就完全变味了。