我在LinkedIn上看到一个帖子，有人问几个静态分析安全厂商的区别。有一个人不出所料地回答说，他们的解决方案比较好，因为当其他公司注重质量和安全时，他们在严格地执行安全。
当然，这句话很可笑。而这种想法也许正说明了目前业界应用安全问题的猖獗；例如，那些试图将安全小组与SDLC的其他部分（包括开发和测试工作）完全分开运行的组织。在这种模式下，安全小组运行自己的测试，主要是试图破坏软件，然后将安全错误反馈给开发团队。换句话说，试图在他们的代码中测试安全。我可以向你保证，这并不比在你的代码中测试质量更有效。文章源自玩技e族-https://www.playezu.com/185056.html
当然，这种安全测试是必要的，但这根本不够。虽然破坏软件确实很有用，但依靠它作为提高安全性的方法，会导致在发现错误的时候为时已晚，最终被压制。特别是，诸如不恰当的框架和算法等根源问题被扫地出门，因为时间表赢得了重写代码和将版本发布出去之间的冲突。文章源自玩技e族-https://www.playezu.com/185056.html
在我上面提到的Linkedin评论中，供应商通过声称他们的软件以某种方式更好，而实际上没有说任何有用的关于如何或为什么它更好的东西，这是在危险地误导毫无戒心的潜在客户。我无意挑剔任何一个特定的工具供应商，尤其是我自己也需要供应商提供的工具。然而，我对这种稻草人的论点感到失望，因为这种论点给人的感觉是在兜售蛇油。在这种情况下，厂商的产品可能确实有有趣的独特功能，但我们留下的印象是，安全与质量有某种神奇的不同，这降低了我们对应用安全的理解，使我们都有点不安全。文章源自玩技e族-https://www.playezu.com/185056.html
安全必须像对待质量一样对待，而质量必须基于成熟的工程实践，因为事实是，如果你有质量问题，你就有安全问题。研究表明，50-70%的安全缺陷都是质量缺陷。换句话说，好的老式质量缺陷正在变成入侵者/黑客/不良行为者用来渗透你的应用程序的漏洞（我们称之为“零日漏洞”）。文章源自玩技e族-https://www.playezu.com/185056.html
“研究人员的共识是，至少有一半，甚至可能多达70%的常见软件漏洞是根本性的代码质量问题，可以通过编写更好的软件来预防。马虎的编码。”文章源自玩技e族-https://www.playezu.com/185056.html
——Jim Bird在“构建真正的软件”中说道。文章源自玩技e族-https://www.playezu.com/185056.html
如果你还不确定质量和安全是如何重叠的，请看一下CWE Top 25中的几个例子。以下可能的安全结果来自CWE技术影响工作。文章源自玩技e族-https://www.playezu.com/185056.html
#3 CWE 120 - 缓冲区复制而不检查输入的大小（“经典缓冲区溢出”） - 可能会导致执行未经授权的代码或命令，可能会导致未经授权的数据访问，可能会导致拒绝服务（DoS）。文章源自玩技e族-https://www.playezu.com/185056.html
#20 CWE 131 - 缓冲区大小计算错误（导致缓冲区溢出） - 可能出现DoS，执行未经授权的代码或命令，可能出现未经授权的读取/修改内存。文章源自玩技e族-https://www.playezu.com/185056.html
#25 CWE 190 - 整数溢出或环绕（导致未定义的行为，从而导致崩溃） - 可能的DoS，可能的内存修改，可能执行未经授权的代码或命令，可能的任意代码执行。文章源自玩技e族-https://www.playezu.com/185056.html
如果你进一步去看完整的CWE列表（超过800个项目），你会发现很多其他的问题，即所有形式的溢出/下溢、初始化、不受控制的递归等。这些都是常见的安全攻击，也是明显的质量问题。
构建它
软件系统的复杂性增长非常迅速。想要测试每一个可能的变化很快就变得几乎不可能。正如Richard Bender所说：“潜在测试的数量超过了宇宙中分子的数量。”这只是一种更有趣的说法，你永远也做不到。或者Jim Bird说的：“对于一个大系统，你需要无限多的笔测试人员在无限多的键盘上工作无限多的时间，也许才能找到所有的bug。”
所以安全性和可靠性都要设计和工程化进去。你不能把它们测试进去。只要安全性是“额外”的东西，它就会受到影响。
可以做什么呢？
以下是你可以做的几件事，可以同时开始提高你的软件质量和安全性。
1、对开发人员进行安全开发方面的培训。在安全开发实践中对开发人员进行充分的培训意味着他们可以预防（或至少发现并修复）安全问题。
2、设计和构建你的系统时要刻意关注质量和安全。避免那些“能用”但并不是一个好的选择的代码，因为它有潜在的安全问题。静态分析可以帮助你做到这一点，检查你的代码，不仅要检查错误，还要检查是否符合已知的最佳实践。
3、停止依赖边缘工具。认识你的实际暴露和攻击面。防火墙和反病毒无法弥补不安全的代码——你必须加固你的应用程序。
4、收集/测量缺陷数据，并使用它来评估和改进你的开发实践。哪些代码或组件产生的问题最多？哪些代码是最好的？它们是如何测试的？重复好的想法，弃掉坏的想法。
5、使用严格的静态分析。不要简单地接受别人的评估，认为报告的缺陷不是一个重要的问题或假阳性。获取一套包括检测和预防在内的好规则，并按其生活。最好的方法是从围绕最佳实践的工程方法（CWE、CERT和OWASP等编码标准的作用）。静态分析是确保最佳实践被遵循的方法。
6、使用运行时分析。它会发现真正的问题（尤其是讨厌的内存问题），它能准确地告诉你哪里出了问题，出了什么问题，而不会出现任何误报。
因此，我们需要开始在代码中构建安全性。这是真正加固的最好方法，而不仅仅是修补已知的漏洞。将编码、构建和测试的所有软件开发结果整合到一个中央存储库中，可以提供控制、测量和可追溯性。这是未来改进的基础。
而且请记住，坚实的预防的成本比处理坏的或不安全的软件的成本要低。所以，真的没有任何借口对软件测试视而不见了。
评论