fortifyExecuteScan not behaving the same as executeFortifyScan

[Thilaknath]

Hello Team,

Switching the above step to adapt to the new implementation doesn't seem to be straightforward, The scan doesn't take into consideration the generated-sources, target folders which cause a drop in the number of lines scanned.

Refer to the attached screenshot of scans from executeFortifyScan and fortifyExecuteScan .fpr files opened in audit workbench. gives a clear overview of packages missed out in scan.

Trying to add them as the additional source using src flag like the following doesn't seem to help as well

  fortifyExecuteScan:
    dockerImage: 'docker.wdf.sap.corp:50000/iotmac/maven:3.6-slave'
    fortifyCredentialsId: 'FORTIFY_CREDENTIALS_TOKEN_BAF'
    src:
      - '**/target/**/*'
    dockerVolumeBind:
      '/home/ccloud/.m2': '/home/piper/.m2'
![results-with-old-Piper-Fortify-step](https://user-images.githubusercontent.com/3452073/98288482-ea26a280-1f74-11eb-8a4d-3389dff06187.png)

[Thilaknath]

@nevskrem

[nevskrem]

@Thilaknath please use the internal repo specifically when pasting internal details. We basically adhered to the previous defaults. I will cross check tomorrow.

[Thilaknath]

@nevskrem Thanks for the correction. I removed the images. yes the defaults don't seem to be the same and also it would be great if you could refer where you are loading them from.

[Thilaknath]

@nevskrem Do you have any update?

[DinakarV]

@nevskrem I am highly interested in this topic as well, did you get a chance to check this? Please do let us know.

[vlkl-sap]

The old step used a Maven plugin as an integration point for Fortify SCA. The new step no longer does that and is thus not able to reflect the advanced stuff happening during the build. One would either need to do workarounds in the pipeline by building first or rearchitecture the step.

[nevskrem]

Corrections have been applied to the step as well as to the defaults which should at least help for better parity. Therefore closing this issue by now.