敏捷开发环境中的漏洞测试评估

Question

详细信息：

我会对你们如何处理敏捷环境中的漏洞测试感兴趣？

示例：

您有每周一次的测试系列，在其中测试项目是否存在漏洞。发现的弱点会对你的产品造成持久的损害。

在敏捷开发中，您认为这些错误或漏洞有什么价值？

您定义了什么工作流？

Answer 1

敏捷方法是关于快速反馈循环的。将漏洞测试集成到流程中的最佳实践将因流程的不同而有所不同。例如，如果您使用的是连续部署，您可能希望比部署频率较低的组织更经常地运行某种级别的漏洞扫描，例如每周或每月进行一次或两次部署。

不过，我认为有一些普遍的良好做法。

一个好的做法是有一个安全可靠的环境来进行针对漏洞的测试。您可能不希望在测试中这样做，主要是在发现和利用漏洞时。您需要一个可以利用该漏洞并在不影响最终用户的情况下找到其局限性的环境。这也使您能够在不影响最终用户性能或稳定性的情况下运行并发扫描。

另一个好的做法是使用自动化。让您的漏洞工具设置并指向您的测试环境，并计划定期运行。这可能是构建过程的一部分，将新版本部署到安全环境会触发扫描。它可能与日程有关，一天一次，或者一周一次。确保不仅考虑扫描因为软件的变化，而且用新的规则和模式更新扫描仪本身。

第三种做法是将安全性构建到整个生命周期，而不是在最后依赖它。对开发人员和操作人员进行有关安全主题和标准的培训，以便他们能够在需求、规划、设计和开发活动中考虑这些问题。将静态分析集成到构建过程中，以失败不符合质量规则的构建，包括引入漏洞。这还可以帮助执行代码样式，代码样式可以使人们更容易阅读和避免漏洞或现有漏洞的原因。考虑由安全专家提供的由人主导的渗透测试，并找到方法来改进您的流程，使您能够更快地找到任何东西。目标应该是防止引入漏洞，同时在进程的早期检测到任何漏洞。

最后的做法是将漏洞管理扩展到第三方组件。这包括与软件捆绑在一起的第三方库。如果该系统作为服务软件运行，它还将包括操作系统和操作系统级库。您不仅应该修补已知的安全漏洞，而且确保您使用的是受支持的版本，可以确保您将收到安全修补程序(如果有的话)。

无论您的工具和活动如何，一旦您发现潜在的漏洞，请将其视为bug报告。首先，确认它是真实的。有些工具有错误阳性，或者可能标记有其他缓解措施的漏洞，或者“漏洞”可能是系统的预期行为。如果确认了该漏洞，请将其视为任何其他缺陷。如果您有一个无bug或零错误策略，这可能意味着在检测和确认后立即处理它。否则，它可能意味着把它放在一个有意义的地方，基于风险暴露、开发难度、修复成本等因素。