我知道这是一个模糊的问题，但我正在寻找关于团队如何将安全性与持续交付/部署相集成的博客或信息。我们每天多次部署到AWS，我正在寻找团队为流量添加安全性的一些方法。
我见过一个团队使用黄瓜做一些nmap测试的演示文稿，这不是我正在寻找的东西，但是在他们进入负载均衡器之前部署后，可能会对app节点进行一些自动测试接受交通。
答案 0 :(得分：1)
这可能不是您正在寻找的，但有效安全测试的关键是在设计时，实施等将其构建到产品中。编码安全测试就像您将单元一样测试，在应用程序的所有级别。使用这种方法，安全测试与一般应用程序测试没有什么不同。
预先打包的安全测试很好，您应该使用它们（大多数组织在QA检查之前执行此操作），但它们不如您的内置测试有效。这是因为没有人像你的开发人员那样知道安全“危险区域”（或者至少他们应该知道。如果他们没有他们读书。对于网络应用我强烈推荐"The Web Application Hacker's Handbook,"和其他应用我推荐"Secure Coding in C and C++" by Robert Seacord，即使你没有做C / C ++。如果你可以等一下，4月份会出现2nd Edition of Seacord's book。
除非在设计时考虑，否则安全性永远不会有效。如果您已经搞砸了，请尝试将安全测试集成到您的常规应用测试中。
编辑：
一些优秀的预装扫描仪（一些免费的语音，其他免费的啤酒，其他一些不是免费的）可以针对您的网络应用运行（无特定顺序）。这些将找到常见和现有的漏洞，但不会找到您的Web应用程序的独特漏洞：
答案 1 :(得分：1)
在我的上一家公司LMAX，我们处理安全功能，就像这些功能的任何其他和自动验收测试一样。
我们编写的验收测试通过与系统其他任何用户相同的渠道与系统进行交互，并证明系统的安全规定按预期工作。
因此，一项测试会断言如果登录成功，系统的其他功能可用。另一个人断言，如果登录失败，你就无法访问任何安全功能 - 简单的确实。
诀窍是确保您的验收测试通过与真实用户相同的通信渠道与系统交互，或尽可能接近，在应用程序的主要逻辑中没有特殊的技巧或后门 - 特别是没有允许您绕过安全功能的技巧或后门; - ）
登录是一个简单的例子，但这种方法适用于任何用户级安全功能 - 实际上是任何功能。
当然还有其他类的安全问题，检查缓冲区溢出，sql注入等。其中很多是关于将应用程序设计为安全的 - 例如，通过将应用程序分层，明确分离职责。
您也可以在验收测试中包含针对这些安全要求类的测试（如果适用于您的应用程序），或者在部署管道中添加额外步骤以针对这些类型的曝光运行测试。这取决于您的应用程序的性质，我可能会添加到大多数应用程序的验收测试，并采取专用的管道阶段方法的应用程序，我可以自动生成测试用例尝试注入 - 例如在web-app中搜索所有输入字段并尝试注入垃圾？
答案 2 :(得分：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）“学习”应该如何使用应用程序，并且通常比仅仅使用蜘蛛更有效。
当然，自动扫描只能找到潜在漏洞的一个子集，但它确实意味着安全人员可以专注于更“有趣”的问题：）
答案 3 :(得分：0)
作为持续集成的一部分，有两件事可以做 - 一个是通过check marx等工具进行安全故障的静态代码分析，也可以集成到WAPiti等运行时漏洞评估工具中。在这种情况下，您始终处于安全问题的最前沿。偶尔你可以通过第三方进行重量级安全评估。
基本上是在改变时（或尽可能频繁地）在发布之前将其作为最后一步。
我们为每日构建做这些。