在项目生命周期中，您是否适合软件的外部渗透/安全测试？

Question

假设您正在开发一个需要通过第三方安全/渗透测试才能发布到客户端的软件，那么在项目生命周期的哪一点，您会执行测试吗？

通过测试意味着没有检测到任何重大缺陷，或者更有可能的是，任何检测到的缺陷在发布之前都得到了正确的纠正。

Answer 1

我猜这取决于进行测试的成本(现金、时间和资源)，它可以重复多久一次，以及您需要提前多少时间协商测试日期。还有它的有效性有多有限，也就是说，如果您在通过测试后对代码做了最简单的更改，那么它是否会使整个测试无效，迫使您完全重复，还是部分重复？

如果它是昂贵的，很难安排，我会安排它到UAT阶段，并尝试运行尽可能多的内部测试之前。显然，这样做越容易，越便宜，越早开始测试是值得的(一旦我有了一个相当稳定的版本，包括所有关键特性，也就是说)。

Answer 2

显而易见的简单答案是:最后。在开发的后半段，这样做只会留下漏洞的空间，等等。

更有效的办法是经常这样做。这样你就能发现并修复那些缺陷，更接近于你实际制造它们的时候，这比记住你几个月前做过的要容易得多。如果您可以将渗透测试的一些基本知识应用到单元测试中，那么首先要建立一个连续集成服务器，如果您制造了任何真正的坏消息(尽管不能真正替代真正的测试)，它可以提醒您。

Answer 3

在项目生命周期中，您是否适合软件的外部渗透/安全测试？

它发生在生命周期的每一步。

首先，渗透测试只是一个更复杂的安全难题中的一小部分。

其次，渗透测试包括运行时配置、适当的管理以及软件实现问题。渗透测试需要对操作系统、web服务器、数据库、防火墙和应用软件进行适当的修补和配置。

在开始进行详细设计之前，您需要对体系结构进行渗透测试。架构本身是安全的吗？

你对设计做渗透测试。设计有多安全？会有哪些渗透机会？

作为编码和单元测试的一部分，您可以进行渗透测试。代码符合设计要求吗？它是否正确地使用了体系结构特性来防止安全问题？

然后，您可以对最终的软件产品进行各种安全检查，包括--但不限于--渗透测试。

安全是无处不在的。或者它有洞。这不是工作计划中的“步骤”。这是一个潜在的原则。