软件安全的最大风险是检验工具及过程不透明的本质，以及不同的检验技术（例如自动化动态测试）不能 覆盖假阴性错误的潜在可能性。
尽管安全软件开发生命周期(SDLC)有很多相关的最佳实践，但大多数 组织依然有一种倾向，那就是主要依赖测试去构建安全的软件。当前的测试方法有一个最严重的副作用，即组 织不太清楚哪些已经被其解决方案测试过，而（甚至更重要的是）还有哪些未被测试过。我们的研究表明，任 何单一的自动化保证机制最多可以检验44%的安全需求。NIST 静态分析工具博览会发现，Tomcat中有26个已知 的漏洞，但所有静态分析工具综合起来只报告了其中4个警告。因为依赖不透明的检验过程是一种普遍存在的 习惯，甚至已经成为行业标准，因此许多组织在构建安全的软件时，满足于把测试作为最主要的手段。
举个例子，假设你雇用一家咨询公司为你的软件执行渗透测试。许多人将这种测试称为“黑盒”（基 于同名的质保技术），测试人员没有详细的系统内部构件知识（比如系统代码）。执行测试之后，一成不变地 生成一份报告，概括你应用中的几类漏洞。你修复了漏洞，然后提交应用做回归测试，下一份报告反馈说“已 清除”——也就是说没有任何漏洞了。或者充其量仅仅告知你，你的应用在同一时间范围内不会被同样的测试 人员以同样的方式攻破。但另一方面，它不会告诉你：
你的应用中还有哪些潜在的威胁？
你的应用中哪些威胁“其实不易受到攻击”？
你的应用中有哪些威胁未被测试人员评估？从运行期的角度来看，哪些威胁无法测试？
测试的时间及其他约束如何影响了结果的可靠性？例如，如果测试人员还有5天时间，他们还将执行哪些其 他的安全测试？
测试人员的技能水平有多高？你能否从不同的测试人员或者另一家咨询公司手中取得一组相同的结果？
以我们的经验来看，组织无法回答以上大多数问题。黑盒是两面的：一方面，测试人员不清楚应用的内部 结构；而另一方面，申请测试的组织对自己软件的安全状况也缺乏了解。并不只是我们意识到了这个问题： Haroon Meer在44con上讨论了渗透测试的挑战。这些问题大多数都适用于任何形式的验证：自动化动态测试、 自动化静态测试、手工渗透测试以及手工代码审查。实际上， 近期有一篇论文介绍了源代码审查中类似的挑 战。
关于需求的实例
为了更好地说明这个问题，让我们看一些常见的高风险软件的安全需求， 以及如何将常见的验证方法应用到这些需求上。
需求：使用安全的哈希算法（如SHA-2）和唯一的混淆 值（salt value）去哈希（Hash）用户密码。多次迭代该算法。
在 过去的一年里，LinkedIn、Last FM和Twitter发生了众所周知的密码泄露事件，对于此类缺陷，本条需求是具 体地、合乎时宜的。
如何应用常见的验证方法：
自动化运行期测试：不可能访问已存的密码，因此无法使用此方法验证本需求
手工运行期测试：只有另一些开发导致已存密码转储时，才能使用此方法验证本需求。这并不是你所能控 制的，因此你不能依靠运行期测试去验证本需求。
自动化静态分析：只有满足以下条件时，才可以用此方法验证本需求：
工具清楚身份认证是如何工作的（例如，使用了标准的组件，就像Java Realms)
工具清楚应用程序使用了哪个特定的哈希算法
如果应用程序为每次哈希使用了唯一的混淆值，工具要清楚混淆算法和混淆值