Jenkins 按需强化和内部部署强化之间的差异

HPE按需强化和预置强化之间有什么区别

我正在尝试与詹金斯一起设置fortify，詹金斯正在亚马逊云上运行。需要建议。

“内部部署”表示您自己正在运行Fortify工具，安装在您管理的硬件（AWS实例、开发人员工作站等）上

---

“随需应变”表示您正在使用Fortify作为服务（供应商称之为“安全即服务”）。营销材料表明，您将源代码发送给他们的团队进行分析（使用Fortify），并且您将收到一份结果报告。

我的评论是我自己的，不一定反映我雇主的观点

我两者都用过。如果您购买的是Fortify，那么您应该使用内部版本。如果您愿意使用其他工具，那么您应该询问Fortify是否适合您

简单的原因是，按需强化通常不适用于自动化。它有太多的问题，而强化支持将花费更多的精力让您手动执行某些操作，而不是试图修复这些问题

现在让我们来详细分析一下每种方法的优缺点

加强内部部署 通过大量的工作和/或成本，您可以设置Fortify on Premise，以便在DevSecOps环境中高效地工作。在开发环境和Fortify SSC服务器之间，建议使用一个环境（如Jenkins服务器），而不是从中进行Fortify扫描。这个中间环境接收来自dev环境的代码，对其进行扫描，并将结果上传到Fortify SSC（内部部署服务器）。如果出现问题，拥有这个中间环境对于高效调试是至关重要的，因为AppSec团队将对其拥有完全的控制和可见性。AppSec团队必须维护中间环境，加强SSC，并向开发人员提供一个脚本，以将其代码上传到中间环境。这样的设置可以用来实现安全性，并提高企业环境中安全编码实践的标准，但设置起来需要时间

优点：

• 您完全可以控制，并且可以有效地调试问题，这一点很重要，因为问题总是存在的
• 它允许您有效地扩展安全性
• 强化扫描引擎非常强大

缺点：

• 大量的安装工作
• 您必须维护环境
• Fortify总是有很多误报
• 强化扫描速度慢
• Fortify需要能够构建（对于大多数语言）以执行最佳扫描，这将在许多方面影响您
• Fortify对开发人员不是那么友好
• 你经常需要深入挖掘，弄清楚一个强化的发现是关于什么特别的东西，还是仅仅是“充满了它”。理解这只野兽需要时间

按需加固 Fortify on Demand的吸引力在于，您不需要所有这些设置来高效地扫描代码库。此外，他们还提供Jenkins和VSTS插件，将它们放入开发人员构建环境中，将代码上传到云服务器，在那里进行扫描，然后您就可以得到结果。它们似乎使您更容易构建集成安全性

不幸的是，它根本不起作用。使用Fortify on Demand时，事情总是会中断，您几乎没有能力调试问题。您被迫打开强化支持帮助票证。加强支持是缓慢的。当事情失败时，他们下意识的反应是你做错了什么，他们告诉你尝试不同的东西。他们很少努力调试问题。如果您是Fortify方面的专家（了解有关fpr文件的各种信息以及发生故障时要查找的内容），您可以确定Fortify支持以证明问题出在他们的环境中。但他们不会修复它，而是鼓励你不要使用他们的插件，而是做其他事情。因此，简短的总结是，如果您想要自动化，按需强化不适合您。他们的销售人员不会这么说，但当你把他们牵制住时，他们会促使你接受

现在需要明确的是，您需要了解的一件事是，除非您是专家，否则您可能会认为VSTS插件工作正常，并且您的开发人员编写了很棒的代码，这就是为什么Fortify找不到太多。不要上当受骗。看看fpr文件。你可以找出扫描的内容，你会发现很多东西都不起作用。在我最近的案例中，我发现没有扫描任何控制器文件，这是扫描应用程序最重要的部分。我感到困惑的是，Fortify Support认为解决环境中的问题不是他们的责任

优点：

• 您不需要维护环境
• 扫描结果中的误报和无意义更少

缺点：

• 不适合自动化
• 在没有强化支持的情况下无法调试问题
• 加强支持是缓慢的
• 当问题复杂且处于强化环境中时，强化支持将尽一切可能避免解决问题。当他们要求你花费大量精力做一些显然与问题无关的事情时，你会感到非常沮丧，因为他们对问题做了一些基本的检查。（调试中的第1步应该是查看有效负载和fpr文件——但他们确实尽力不这么做）
• 尽管扫描结果中没有那么多废话，但还是有废话漏掉了
• 强化扫描速度慢
• Fortify需要能够构建（对于大多数语言）以执行最佳扫描，这将在许多方面影响您
• Fortify对开发人员不是那么友好

我们是否需要