4

我知道这是一个模糊的问题，但我正在寻找有关团队如何将安全性与持续交付/部署集成的博客或信息。我们每天多次部署到 AWS，我正在寻找团队为流程增加安全性的一些方法。

我看过一个演示文稿，其中一个团队使用 cucumber 进行了一些 nmap 测试，这并不是我想要的，但可能是在应用程序节点部署后，在它们进入负载均衡器接受流量之前对它们进行一些自动化测试。

4

4 回答 4

1

这可能不是您想要的，但有效安全测试的关键是在设计、实施等时将其构建到产品中。在应用程序的所有级别上，就像单元测试一样编码安全测试。使用这种方法，安全测试与一般应用程序测试没有什么不同。

预打包的安全测试很好，您应该使用它们（大多数组织在 QA 检查之前这样做），但它们不如您的内置测试有效。这是因为没有人像您的开发人员那样知道安全“危险区域”（或者至少他们应该知道。如果他们没有让他们读一本书。对于 Web 应用程序，我强烈推荐“Web 应用程序黑客手册”，对于其他应用程序我推荐Robert Seacord 的“Secure Coding in C and C++”，即使你不使用 C/C++。如果你可以等待的话，Seacord 的书的第 2 版将于 4 月出版）。

除非在设计时考虑，否则安全性永远不会有效。如果您已经搞砸了，请尝试将安全测试集成到您的常规应用程序测试中。

编辑：

一些很棒的预装扫描仪（一些像语音一样免费，另一些像啤酒一样免费，还有一些根本不免费）可以针对您的 Web 应用程序运行（无特定顺序）。这些将找到常见和现有的漏洞，但不会找到您的 Web 应用程序的独特漏洞：

  1. 内苏斯
  2. 开放式增值服务
  3. 尼克托
  4. Acunetix
  5. 打嗝套房
  6. W3af
  7. 视网膜
  8. 曝光
于 2013-03-15T16:50:11.903 回答
1

在我的上一家公司 LMAX 中，我们像对待任何其他公司一样对待安全特性，并对这些特性进行自动化验收测试。

我们编写了验收测试，通过与系统的任何其他用户相同的渠道与系统交互，并证明系统的安全规定按预期工作。

因此，一项测试会断言，如果登录成功，则系统的其他功能可用。另一个人会断言，如果登录不成功，您将无法访问任何安全功能 - 真的很简单。

诀窍是确保您的验收测试通过与真实用户相同的通信渠道与系统交互，或者尽可能接近，没有特殊的技巧或后门进入应用程序的主要逻辑 - 特别是没有技巧或后门- 允许您绕过安全功能的门 ;-)

登录是一个简单的例子，但这种方法适用于任何用户级安全功能——实际上是任何功能。

当然还有其他类别的安全问题，检查缓冲区溢出、sql 注入等。其中很多是关于将您的应用程序架构成安全的——例如，通过分层应用程序来明确职责分离。

如果适用于您的应用程序，您也可以在验收测试中包含针对这些安全要求类别的测试，或者在部署管道中添加一个额外的步骤来针对这些类型的暴露运行测试。这取决于您的应用程序的性质，我可能会添加到大多数应用程序的验收测试中，并为应用程序采用专用的管道阶段方法，我可以在其中自动生成测试用例以尝试注入 - 例如在 Web 应用程序中搜索所有输入字段并试图注入垃圾？

于 2013-03-19T10:21:56.290 回答
0

作为持续集成的一部分，可以做两件事——一是通过 check marx 等工具对安全故障进行静态代码分析，还可以将其集成到 WAPiti 等运行时漏洞评估工具中。在这种情况下，您始终处于安全问题之上。有时，您可以运行第三方的重量级安全评估。

本质上是在更改时（或尽可能频繁地）执行此操作，而不是将其作为发布前的最后一步。

我们为我们的日常构建做这些。

于 2014-04-16T10:28:39.370 回答
0

我们在 Mozilla 中处理这个问题的方法是通过 OWASP ZAP 代理我们的（功能）回归测试，然后使用 ZAP 蜘蛛、主动和被动扫描仪，这些都可以通过 REST API 进行控制。

我录制了一段关于这个过程的视频：http ://www.youtube.com/watch?v= ZWSLFHpg1So，还有更多关于 ZAP wiki 的详细信息：http ://code.google.com/p/zaproxy/wiki/ SecRegTests

这种方法允许安全工具（在这种情况下为 ZAP）“学习”应用程序“应该”如何使用，并且通常比爬取更有效。

当然，自动扫描只会发现潜在漏洞的一个子集，但这确实意味着安全人员可以专注于更“有趣”的问题:)

于 2013-03-20T09:14:07.683 回答