Fortify按需和内部之间的差异

Question

HPE Fortify按需和内部部署有什么区别？

我正在尝试使用在亚马逊云上运行的jenkins设置防御。需要建议。

Answer 1

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

我都用过。如果您在Fortify上出售，则应使用内部版本。如果您愿意使用其他工具，则应询问Fortify是否适合您。

Fortify on Demand通常不适用于自动化，这是其简短原因。它有太多问题，Fortify支持人员将花费更多的精力来尝试使您手动完成工作，而不是尝试解决问题。

现在让我们按每种技术的优缺点进行分类。

在内部设防

通过大量的工作和/或成本，您可以在Fortm上设置Fortify以在DevSecOps环境中有效地工作。在开发环境和Fortify SSC服务器之间，建议有一个环境（例如Jenkins服务器），而不是Fortify扫描所来自的环境。这个中间环境从开发环境接收代码，对其进行扫描，然后将结果上传到Fortify SSC（本地服务器）。如果出现问题，拥有这种中间环境对于高效调试至关重要-AppSec团队将对其进行完全控制和可视化。 AppSec团队将不得不维护中间环境Fortify SSC，并向开发人员提供脚本以将其代码上传到中间环境。这样的设置可用于实现安全性并提高公司环境中安全编码实践的标准，但设置起来需要花费时间。

优点：

• 您完全处于控制之中，并且可以有效地调试问题，这很重要，因为它总是会出现问题。
• 它使您可以有效地扩展安全性
• 强化扫描引擎非常强大。

缺点：

• 大量的设置工作
• 您必须维护环境
• Fortify总是有很多误报
• 强化扫描很慢
• Fortify需要能够（对于大多数语言）构建以执行最佳扫描，这将以多种方式咬住您
• Fortify对开发人员不太友好
• 您经常需要深入研究以确定Fortify的发现是否适用于某些特殊的东西，或者只是“充满了”。了解野兽需要时间。

按需强化

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

不幸的是，它根本不起作用。 Fortify on Demand总是会破坏一切，您几乎无法调试问题。您被迫打开Fortify支持帮助票。强化支持很慢。当事情失败时，他们的膝盖反应就是您做错了什么，他们告诉您尝试不同的事情。他们几乎不花力气调试问题。如果您是Fortify的专家（了解有关fpr文件的各种信息以及发生故障时查找的内容），则可以将Fortify支持固定下来，以证明问题出在其环境中。但是，与其修复它，不如说他们会鼓励您不要使用他们的插件，而是做其他事情。因此，简短的总结是，如果您想要自动化，Fortify on Demand不适合您。他们的销售人员不会这么说，但是当您锁定他们时，这就是他们促使您接受的方式。

现在要弄清楚，您需要了解的一件事是，除非您是专家，否则您可能会认为VSTS插件可以正常工作，并且您的开发人员编写了很棒的代码，因此Fortify不会找到太多东西。不要被欺骗。查看fpr文件。您可以找出要扫描的内容，并且经常会发现许多问题不起作用。在我的最新情况下，我发现没有扫描任何控制器文件，这是扫描应用程序最重要的部分。我很困惑，Fortify支持人员认为解决他们所在环境的问题不是他们的责任。

优点：

• 您不需要维护环境
• 更少的误报和更少的废话

缺点：

• 不适用于自动化
• 没有Fortify支持就无法调试问题
• 强化支持很慢
• 当问题很复杂且在Fortify环境中时，Fortify支持人员将尽一切可能尝试避免解决问题。当他们要求您花很多精力去做其他事情，如果他们对问题进行了一些基本的检查，这些事情显然是不相关的，那真让人沮丧。 （调试中的第1步应该查看有效负载和fpr文件-但他们确实努力做到这一点）
• 即使扫描结果中的废话少了，但废话还是会漏掉。
• 强化扫描很慢
• Fortify需要能够（对于大多数语言）构建以执行最佳扫描，这将以多种方式咬住您
• Fortify对开发人员不太友好

Answer 2

“本地”意味着您自己运行Fortify工具，并安装在您管理的硬件（AWS实例，开发人员工作站等）上。

“按需”表示您将Fortify用作服务（供应商将其称为“安全性即服务”）。营销材料表明，您发送了源代码以供他们的团队分析（使用Fortify），然后您将被发送回结果报告。