第三方类库是侵蚀系统安全并引起漏洞的一个途径。当审查代码时至少你要检查是否引入了新的依赖（如第三方类库）。如果你还没有自动化检查漏洞，你应该检查新引入的类库中已知的问题。

你也应该尝试着最小化每个类库的版本，当然如果其他依赖有一个额外的间接依赖，这点可能达不到。但最简单的最小化自己代码暴露在他人代码的（通过类库或服务）安全问题中的方法有：

尽可能使用源码并理解它的可信度。

使用你所能得到的质量最高的类库。

追踪你在何处使用了什么，当新的漏洞出现，你可以查看你受影响的程度。

　　检查是否新的路径和服务需要认证

无论你开发web应用、提供web服务或一些其他需要认证的API，当你增加一个新的URI或服务时，你应该确保它不能在没有认证的情况下被访问（假设认证是你系统的需求）。你只要简单地检查代码的开发者写了合适的测试用例来展示进行了认证。

你应该不只针对使用用户名和密码的人类用户来考虑认证。其他系统或自动化流程来访问你的应用或服务也会需要认证。这可能影响你们系统中对“用户”的定义。

　　数据是否需要加密

当你保存一些数据到磁盘或通过线缆传输，你需要了解数据是否应该被加密。显然密码永远不应该是简单文本，但是有诸多其他情况数据需要加密。如果被审查的代码通过线缆来传送数据或保存在某地或以其他方式离开你的系统，且你不知道它是否应该被加密，尝试询问下你组织中可以回答这个问题的人。

　　密码是否被很好地控制？

这里的密码包含密码（如用户密码、数据库密码或其他系统的密码）、秘钥、令牌等等。这些永远不应该存放在会提交到源码控制系统的代码或配置文件中，有其他方式管理这些密码，例如通过密码服务器（secret server）。当审查代码时，要确保这些密码不会悄悄进入你的版本控制系统中。

　　代码的运行是否应该被日志记录或监控？是否正确地使用？

日志和监控需求因各个项目而不同，一些需要合规，一些拥有比别人严格的行为、事件日志规范。如果你有规章规定哪些需要记录日志，何时、如何记录，那么作为代码审查者你应该检查提交的代码是否满足要求。如果你没有固定的规章，那么就考虑：

代码是否改变了数据（如增删改操作）？是否应该记录由谁何时改变了什么？

代码是否涉及关键性能的部分？是否应该在性能监控系统中记录开始时间和结束时间？

每条日志的日志等级是否恰当？一个好的经验法则是“ERROR”触发一个提示发送到某处，如果你不想这些消息在凌晨3点叫醒谁，那么就将之降级为“INFO”或“DEBUG”。当在循环中或一条数据可能产生多条输出的情况下，一般不需要将它们记录到生产日志文件中，它们更应该被放在“DEBUG”级别。

　　记得叫上专家

安全是个很大的话题，大到足以让你的公司聘请技术安全专家。我们有安全专家就可以获得他们的帮助，如，邀请他们参加代码审查，或邀请他们在审查代码时和我们结对。如果这个无法实现，我们可以充分学习我们系统的环境，来理解我们有哪种安全需求（面向内部的企业级应用和面向客户的网页应用有不同的标准），所以我们可以更好地理解我们应该在代码审查中看什么。

　　写在最后

代码审查是一个很好的方式，不仅确保了代码质量和一致性，也在团队中或团队间分享了项目知识。即使你已经自动化了基础的校验，还有许多不同代码、设计的方面需要考虑。代码审查工具，如Upsource，通过在每个代码提交的检查中高亮可疑的代码并分析哪些问题已经被修复，新引入哪些问题，可以帮你定位一些潜在的问题。工具也可以简化流程，因为它提供了一个平台来讨论设计和代码实现，也可以邀请审查者、作者和其他相关人员参加讨论直到达成共识。

最后，团队需要花时间决定代码质量的哪些因素对他们是重要的，也需要专家人工决定哪些规则应用到各个代码审查中，参与到审查中的每个人都应该具备并使用人际交往的技巧，如积极的反馈、谈判妥协以达到最终的共识，即代码应该怎么样才“足够好”可以通过审查。

原文链接：https://www.infoq.com/articles/effective-code-reviews

　　今日荐文

　　微软开源软件列表