谷歌公司的软件安全开发实践_任何软件开发公司应存在的服务，实践和工具，第2部分...-CSDN博客

谷歌公司的软件安全开发实践

再来一次。在第一部分中，我们介绍了一些基本工具，例如代码库，问题跟踪器和Wiki。我们还列出了诸如构建器服务器之类的服务，围绕测试的测试工具和实践以及诸如代码覆盖率之类的测试实践。让我们继续！

代码质量（实践和工具）

代码质量与测试非常相似。每个人都承认您应该继续执行实施实践和采取措施来增强所交付软件的质量，但是这些措施通常再次被认为是浪费时间，计划不周或在任何项目计划中都根本不存在。另一方面，开发人员要么受过良好的培训，要么没有现实的时间来解决实际业务开发的问题，并且以更少的错误和最佳实践来构建他们的解决方案。幸运的是，有一些方法可以通过在开发期间使用工具来解决时间和精力问题，这些工具可以扫描您的代码并提供报告，提示和待办事项。我们必须指出，所有这些工具都无法检测到体系结构或设计不佳之类的问题，但可以主动保护您免于编写惰性代码或效率低下的“快速”代码。

以下列表是任何Java开发人员都可以集成到其日常工作+ IDE中的一组工具。这些工具也可以通过在连续集成服务器的生命周期中执行它们的执行来自动化，这些服务器将根据请求或按预定的时间间隔执行代码分析任务。这样，您可以消除每个开发人员机器上的额外处理（资源）负担，并将其分配给中央机器-与团队共享所有结果和报告，或将其提供给高级人员使用。

查找错误
PMD
CheckStyle
依赖
声纳（一站式服务代码质量平台）
预防（商业）
埃玛

（随意评论其他功能，它们既可以作为独立工具，也可以作为您喜欢的IDE上的插件使用）

以上所有工具（或在注释中添加的许多其他工具）为我们提供了防范代码开发错误的第一道防线-但不能认为这是代码质量的圣杯。您仍然需要具有技能并愿意学习和适应的开发人员。强制或引入这些工具应在部门级别上–开发生命周期的一部分。您在更广泛的级别上应用这些概念的次数越多，您就越有可能在大多数软件开发活动中看到该实践的结果。

持续……培训（实践）

开发高质量软件解决方案的道路与工具，实践和人员有关。这最后一部分，人的部分是最重要的。正如我们在以前的帖子中已经说过的那样，除非应用工具或实践的人渴望参与，对什么是质量有常识并热爱他们的工作（即软件开发），否则任何工具或实践都不会有效。公司或部门如何帮助保留甚至提高其员工的技能？我们如何才能使人们更有动力，以及如何确保人们能够执行和交付我们出售给客户的商业承诺？

这确实是一个很大的问题，可能有多个答案–在本帖子上，我想提高培训的重要性（作为对上述问题的潜在答案或活动）。我将尝试列出一些实际和务实的行动。

购买技术书籍：每个软件公司或部门都应拥有自己的微型技术书籍库。我建议每月带一些新东西。有很多公司从亚马逊左右购买书籍，但仅在必要时才购买。如果您用最少的钱走了一步（来……只是其他奖金和赠品的一部分，就预算而言，公司愿意向员工支付。）

派人参加培训课程：与每月购买几本书相比，这种做法的确花费更多。良好的培训课程被认为是一项不错的投资，并且可以快速灵活地获取可以通过特定项目利用的某些技能。实际上，我会建议每家公司提供少一些的“其他奖金”，并投资于培训其东西。在软件/ IT商业知识就是力量中，您对知识技能的投入越多，对未来的投资以及向潜在客户交付的能力就越好。

内部参与人员：组织内部会议，在不同开发团队之间进行代码审查，并鼓励似乎比其他人更活跃的人们进行讲座或研讨会。这可能是吸引开发人员并提高期望的一种好方法。

本文的其余部分由该博客的资深读者和经验丰富的专业人员Dimitris Stergiou（ linkedin ， twitter ， blog ）提供。 Dimitris担任信息安全经理，并希望通过这篇文章强调设计和构建安全软件解决方案的重要性。安全性必须是整个软件开发生命周期的一部分。

如前所述，测试是最重要的软件活动之一。但是，在大多数情况下，测试仅限于功能需求，非功能需求（例如应用程序安全性）在很大程度上被忽略。

在深入探讨细节之前，您需要牢记一个缩写词OWASP （是的，我们将多次引用它）

实践：众所周知，除非不间断地检查软件产品（例如Adobe，Microsoft），否则组织不会对非功能性要求（例如安全性）做出任何“努力”。公平地说，当高级管理人员没有直接销售的功能，也没有明显的好处时，为什么还要投入资源（人员和金钱）来解决安全问题？

答案很简单。 安全要求可作为保险（立即付款，防止不良事件发生），保留市场份额（谁想要使用cr脚的产品？）并提供弹性（特别是如果您的产品用作服务-基于Web）

现在，我们已经确定需要安全性，让我们看看如何实现安全性。由于最新趋势是敏捷开发，因此以下示例说明了如何将安全活动与开发活动联系在一起：

由于这不是“一劳永逸”的文章，因此我们仅关注安全测试（代码检查和动态测试）。

在开始安全测试活动之前，我们需要知道我们在寻找什么以及如何找到它。 OWASP以“ OWASP十大Web应用程序安全性问题 ”文档和“ OWASP测试指南v3 ”的形式提供了有关此主题的最佳资源（v4正在进行中）。这两个文档将提供有关最常见（最有害）Web应用程序问题，针对它们的防御措施以及如何在项目中进行识别的基础知识。

工具类

有许多工具可用于帮助进行安全测试。对于代码检查，一些解决方案是：

同行评审：让开发团队阅读彼此的代码。是的，这是一个手动过程，但是可以提高意识并提高开发人员生成“更好”代码的能力。如果您的编程语言不受任何开源静态代码分析工具的支持，并且您没有预算用于商业解决方案，那么这是唯一的选择。

静态代码分析 [PDF]：根据所使用的编程语言，最好使用一种开源静态代码分析工具来检查代码中的常见问题（OWASP还会维护一系列工具）。这不是一个防弹的过程，通常会产生足够多的问题需要解决，但是，如果您设法找到自己喜欢的代码分析工具，并且设法建立了自定义规则（以遵守组织的编码风格），那么它一定会成功很多低落的果实（空的try / switch块，未使用的变量等）

商业静态代码分析：正如Gartner所建议的 [PDF]一样，该领域有3个主要参与者：IBM（购买Ounce Labs之后），HP（购买Fortify之后）和Veracode （他们没有购买任何东西–至少不是直接购买）。根据项目的数量，所使用的编程语言以及仅用于使许可模型复杂化的许多其他参数（或给我的印象），准备好付巨款。在使用这3种产品（IBM / HP）中的2种之后，我可以说它们是很棒的产品，但绝不能提供“开箱即用”的功能。他们需要进行大量配置才能提供有意义的结果（没人会对扫描产生19,387个缺陷感到满意），但是在您确定基线之后，它们将非常有帮助

云中的静态代码分析：如果您负担不起内部托管的解决方案， Fortify还提供了云（托管）解决方案。他们为开源软件提供了一些特殊优惠，但是我从未尝试过该服务，主要是因为我所服务的每家公司都不满意将其源代码“发布”到云中

到目前为止，您应该对如何涵盖静态测试有了一个想法。但是，你需要覆盖的动态测试，以及。让我们来看看如何做到这一点。

工具类

手动渗透测试：尽管有许多可用的工具，但是在Web应用程序安全性方面，没有任何工具可以匹配经验丰富的渗透测试仪的结果。渗透测试人员确实使用自动化工具来完成繁琐且耗时的任务，但并不仅仅依赖于扫描仪的扫描结果。除其他原因外，我们非常无法创建能够理解和评估业务逻辑的Web应用程序扫描程序

Web应用程序扫描程序：此类别包括许多子类别，具体取决于产品实际如何执行其功能。绝对值得一看的一些是：