问持续部署/交付和安全性

EN

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

预打包的安全测试很好，您应该使用它们(大多数组织在QA检查之前都会这样做)，但它们没有内置测试那么有效。这是因为没有人像你的开发人员一样知道安全“危险区域”(或者至少他们应该知道)。如果他们不让他们读一本书。对于web应用，我强烈推荐"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应用上运行(没有特定的顺序)。这些将发现常见的和现有的漏洞，但不会发现您的web应用程序的独特漏洞：

1. Nessus
2. OpenVAS
3. Nikto
4. Acunetix
5. Burp Suite
6. W3af
7. Retina
8. Nexpose

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

我们编写了验收测试，通过与系统的任何其他用户相同的渠道与系统进行交互，并证明系统的安全条款如预期的那样工作。

因此，一个测试将断言，如果登录成功，则系统的其他功能可用。另一种说法是，如果登录失败，你就不能访问任何安全功能--真的很简单。

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

Logon是一个简单的例子，但这种方法适用于任何用户级别的安全特性--实际上是任何特性。

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

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

我们在Mozilla中的方法是通过OWASP ZAP代理我们的(功能)回归测试，然后使用ZAP爬行器，主动和被动扫描器，这些都可以通过REST API控制。

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

这种方法允许安全工具(在本例中为ZAP)“学习”应用程序“应该”如何使用，并且通常比爬行更有效。

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