认识达内从这里开始

安全

你在构建一个安全、稳固的系统所花费的精力，和花在其他特性上的一样，取决于项目本身，项目运行的地方、它使用的用户、需要访问的数据等。达内长沙IT培训现在着重看一些你可能在代码审查时关注的地方。

尽可能使用自动化

有惊人数量的安全检查可以被自动化，而不需要人工干预。安全测试不一定要启动所有系统进行完整的渗透测试，一些问题可以在代码级就能被发现。

常见问题如SQL注入或跨站脚本可以在持续集成环境通过相应工具检查出。你也能通过OWASP依赖检测工具自动化检查你依赖中已知的漏洞。

有时需要“看情况”

对有的校验你可以简单回答“是”或“否”，有时你需要一个工具指出潜在的问题，之后再由人工来决定这个是否需要解决。这也正是Upsource真正的闪光点。Upsource显示代码检查结果，审查者可以利用这些来决定代码是否需要改动或还可以接受目前的情况。

理解你用到的依赖

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

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

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

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

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

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

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

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

数据是否需要加密

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

密码是否被很好地控制？

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

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

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

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

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

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

记得叫上专家

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