分享加密项目审计”干货”

 一份好的加密项目审计报告可以让客户发现潜在问题，并助之解决这些问题，最后可以帮助该项目或产品得到改进，使客户获得更高的价值。不过，这要建立在审计人员以专业和客观的态度与你合作，双方共同实现这个目标的前提基础上。如果审计人员都能遵循一定的质量和道德标准，那么客户就能更好地达到他们的预期和要求。

通常，客户对加密项目的要求不仅仅是找到问题，而是能找到解决方案。因此，这要求审计人员能够为每个发现的问题都提供一些附带的解决建议，而不是在重言式推荐中简单写一句“修复这个问题”。其次，应具体说明问题并在可能的情况下提供补丁。虽然作为审计师，找出最佳解决方法并不总是那么容易的，但可以尝试先写下几种解决策略，然后再与客户进行讨论。不仅如此，解决方案还可区分为短期修复和长期修复。短期修复的解决方案比较简单，例如添加其他的健全性检查或更新某些依赖性方案；而长期修复的解决方案耗时较长，有可能需要做更多工作或进行系统/设计更改。

提到与客户的讨论，在这里要建议审计师积极与客户进行交流，通常来说，最好在准备工作说明时或是在启动会议期间能和对方就如何使用沟通渠道达成共识。不仅如此，审核人员定期与客户共享他们的审计工作进度是非常重要的，比如自己正在评审代码中的哪一部分、发现哪些内容不清楚或有错误信息，同时还要在发现问题后立即报告，这将有助于审计师及早发现错误，并让开发人员实施debug措施。

当然，如果最终的审计报告中没有涉及到任何一个安全问题的话，对审核员和客户而言可能都会感到一丝尴尬，客户甚至会以为审核人员可能没有很好地完成工作，自己的钱也许白花了。所以为了减轻这种担忧，无论最终的报告中什么问题都没发现还是发现了一堆问题，建议最好可以首先列出自己一直在寻找的错误类型，然后还可以描述自己使用过哪些审计工具及其配置，并枚举已验证的属性。

但是，在这要注意的一点是，审计人员通常会夸大问题的严重性。而做出这样的评级决定有时并非因为项目真的有明显问题，而是因为项目只是“看起来”很糟糕并且会让审计人员感到尴尬，或者因为他们推测在事件重合的情况下或许会出现漏洞。但要知道，客户并不关心审计员对bug的个人感觉，他们只需要有意义的风险等级，然后再去确定修复bug的优先级，这样才能与用户进行交互。如果漏洞确实非常严重，比如按照威胁模型的定义，这些漏洞很可能被利用，而且存在严重危害，那么可以将其评估为严重漏洞。记住，夸大严重性不会帮助审计员在审计工作中树立声誉。

如何撰写高质量审计报告

接下来，我们就来谈谈如何撰写一份高质量的审计报告吧。

首先，审计员必须得了解审计目标受众对象。审计需要满足目标受众的需求，因此需要向不同的受众提供不同的审计文档，比如如果只有开发人员会阅读报告，那么一个非正式的轻量级标记语言文档就足够了，这样可以节省编辑时间；但如果报告需要与投资者、合规审计员或高层管理人员共享，那么就必须提交一份带有颜色和徽标的精美审计报告，以及一份执行摘要。所以，事先了解谁将阅读审计报告，特别是这份报告是否会被公布是十分重要的。在这种情况下，还需要格外小心，以避免误解和误导性引用相关内容。

其次，了解审计行业的最新动态，做好功课也是很重要的。比如有哪些最新的参考资料文献和最新的漏洞和攻击策略，这会帮助审计员节省相当多的时间来维护加密组件中常见问题的清单，以及特定于某些变成语言的常见错误和缺陷清单。此外，创建自己的审计工具也是一种十分有效的做法，这可以使审计过程自动化并节省时间。目前 市场上已经有了不少这种工具，因此审计员可以在开始审计之前先熟悉下相关审计工具。

再次，要记住详尽的报告好过于简洁的报告。对于一个熟悉攻击和利用技术安全漏洞的审核员来说，往往很想跳过一些细节问题，并期望读者自己填补漏洞描述和解决建议中的空白，但这样做的确有一定风险，因为读者会误解实际问题，继而无法正确解决。编写详细的报告信息还可以帮助你发现分析中的潜在错误或误解，同时也可以充分利用外部资源，例如博客文章、研究文章、甚至来自类似项目的代码库。

另外请记住，在进行审计的时候，即使某些代码的编写质量可能会令人感到震惊，但也不要使用贬义或嘲讽的语气，而是要坦率而诚实地进行评估。同样，当代码质量高于平均水平时，也不要过分赞美。

给审计员的建议

为了减轻审计员工作量，在这给出一个建议，那就是审核员可以将代码审核任务按照代码库的不同组件进行划分，比如package、subcrates等，然后在团队成员之间分配工作，毕竟人多力量大嘛。但这种方法也有一些问题，那就是某一个人只关注给定的代码行，而没有完全了解组件之间的交互。所以如果想做的更好，其实可以让两个人负责审计同一组件，并且每个人至少要对所审查的所有组件以及它们如何协同工作有基本的了解。不仅如此，两个人工作也会有助于共同讨论识别错误和检测模型错误，而且不会让人感到无聊。

提到团队合作，那么记录自己的工作也是十分重要的。比如每工作1、2个小时后，通过追踪自己的工作，包括已经分析的文件/功能/机制，然后记下想法或是失败的攻击尝试，然后与团队其他人进行共享。此外，这种做法也是向客户证明工作合理性的一种尝试。

那么说完了审计员的工作，再来谈谈他们的收费情况吧。虽然说一般都是严格按照工作时间收费，但这并不总是规则，特别是在规模较大和专业程度较低的公司中。 “一天”的工作通常被理解为相当于8个小时的工作，因此，审计员应该按每8小时工作的天数收费，而不是为分配给该项目的员工出现在办公室并工作了一个工作日的每个工作日收费。毕竟，有时候你需要在会议和茶歇之间耗费好几个小时。

给客户的建议

为了更好地对一个加密项目进行评估，选择一个好的审计员固然重要，对于客户来说，确定审计需求并与审计人员进行沟通也是十分重要的。客户最好能从项目角度详细说明这意味着什么，比如是否最担心编码错误；是否担心代码和规范之间不匹配；是否担心出现设计错误等。

其次，客户需要让审核人员知道审核的重点放在哪里，以及自认为最大的风险是什么，然后在威胁模型和运营模型的背景下描述这些问题。要记住，尽可能多地共享信息，不要相信“代码足以说明文档”这种话，尤其是面对复杂的加密协议时。即使代码清楚地描述了已完成的工作，也无法准确描述出应采取的安全措施，更不用说对抗模型和目标安全属性了。因此，拥有详细的解释文档，并与审核人员共享所有设计文档、相关研究论文、以前的审核报告是十分重要的。这不光可以使审计人员节省时间，还可以帮助他们掌握被审核系统的所有内容。        

另外，客户也需要摆正心态,以建设性的方式看待流程。把审计报告看作是对项目的认可固然很“诱人”，但倘若收到的审计报告发现了工作中的大量问题，也许会让人很不开心。在这需要明白的一点是：审计不太可能对产品无条件认可，因为这可能会引起对审计人员潜在利益冲突的质疑。而且，审计只是一个时间点审核，审计的目标是发现潜在问题，这样就可以帮助客户解决这些问题，并改善审计目标的安全态势。审计的结果就是应该帮助项目或产品得到改进，并在客户和审计员双方的共同努力下实现这个目标。

当然，作为客户肯定还是需要考虑审计费用的。建议客户事先就报告内容达成协议，比如你只需要在审计报告中对安全性问题进行非正式描述时，可能不希望为只需要3天时间就能搞定的工作付费，尤其是这项工作可能只是简单编写规范而已。因此，请在工作说明或启动会议的时候准确反映出对审计报告有何期望，以及哪些事情是你不希望看到的。

其次，客户需要审核下工作量，不要被审计公司牵着鼻子走。假如一个只有500行代码的项目，审计公司却提出需要耗费5人/周的工作量，那就太可笑了。这个时候，客户可以毫不犹豫地直接告诉审计人员自己所发现的问题，或者直接换一家审计公司。另外，相比于那些在项目开发工作中花费大量时间（比如6个月）的开发人员，审计人员对代码库的了解程度肯定有所欠缺，因此客户需要确认审计方案和实施措施，并且帮助审计人员充分了解代码库，毕竟如果他们不了解项目的代码在做什么，那么也不太可能在其中发现错误。

在这再提供一个小贴士，假如你不一定需要审计报告的话，那么可以要求仅通过IRC、Slack、Signal或其他平台非正式地向开发人员索要审计报告调查结果。如果你需要一份包含所有调查结果的综合报告来存档，但不需要一份超级正式和精良的文件，那么审计人员就不用在报告准备上花费太多时间，这么做也能帮助客户节省几天的咨询费。

最后要提醒客户一点的是，需小心处理超售工作包。一些审计公司可能会推广销售一些“额外工作”，比如：“威胁建模”、“安全强化”、“性能优化”、或其他或多或少相关的子项目之类的东西，这些子项目会增加你的咨询费用。所以，甲乙双方都应该事先清楚地理解审计工作内容和目标，以及审计工作将为客户带来哪些价值。但有时候，审计咨询公司的销售人员可能会推销许多“不实用”的服务，如果甲方经理不熟悉具体情况、或是在没有工程师参与时便草草签约，那么可能会上当受骗，这种情况最终也会伤害甲乙双方。

总结

以上分享的建议都是综合了许多有着丰富安全审计工作经验的大咖的经验之谈，他们十分了解审计过程中有哪些事情行之有效，哪些事情劳而无功。希望这些干货能够切实帮助到大家。