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

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

最佳答案

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

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

简短的原因是,按需安装通常不适用于自动化。它有太多问题,Fortify支持人员将花费更多的精力来尝试使您手动执行操作,而不是尝试解决问题。

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

在前提上强化

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

优点:

  • 您完全可以控制,并且可以有效地调试问题,这很重要,因为总会有问题。
  • 它使您可以有效地扩展安全性
  • Fortify扫描引擎非常强大。

  • 缺点:
  • 大量的设置工作
  • 您必须维护环境
  • 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环境中,Fortify支持人员将尽一切可能尝试避免解决问题。如果他们要求您花很多精力去做其他与问题无关的事情,这些事情显然是不相关的,那真是令人沮丧。 (调试中的第1步应该查看有效负载和fpr文件-但他们确实努力做到这一点)
  • 尽管扫描结果中的废话少了,但废话还是会漏掉。
  • 强化扫描速度很慢
  • Fortify需要能够(对于大多数语言)构建以执行最佳扫描,这将以多种方式咬住您
  • Fortify对开发人员不太友好
  • 10-08 16:13