This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Handling and storing suppressions in code

We are using Fortify SCA in our Gitlab CI/CD pipeline and we are having issues with suppressions. Currently, we create a branch, work in that branch and scans are run, the devs suppress known findings and when we merge back to main, the suppressions do not get stored. Are we missing a tool. I read somewhere that the SSC tool is what stores and manages that data.

Please forgive my limited knowledge, I am just trying to figure out why fortify is not integrating well with gitlab when its supposed to be fully supported.

End result is to suppress findings in the branch for known findings, we then fix whatever other findings are there, and merge back to main. When we are done, main retains those suppressions and we dont have to do all that again to successfully pass scans.

Thanks in advance,


  • Maybe we are not following best practices. If this is not a best practice to suppress findings. How do we then pass scans when our gates are set? If we mark it as not a finding, but it is actually a finding, and we do not have the resources to fix that finding right now, how do we address that.

  • Suggested Answer

    SCA is the client

    SSC is the server

    If you really fix an issue in a build - and by that I mean a fix that your devs and Fortify SCA accept - then the issue is removed - gone.

    But if you audit an issue (suppression is not the same thing as auditing) then given there are NO code changes, the issue will be found again in the next SCA client scan.

    That's where the SSC (server) comes into the equation. This allows a common place to view the current status of the project-version (now application, applicationVersion).

    Every scan still finds the audited issue - but on upload the server can remove the finding provided it correlates with existing audits.

    So if you are not using an SSC, you would need a different mechanism to reaudit.

    The SCA can compare a previous run with the current - but that's about it.

    You could export your findings into a SARIF (Static Analysis Result Independent Format) and try using an open source Defect Dojo to give some similar functionality to SSC. But the SSC is the official way to achieve this.

    Let me know if I misunderstood your workflow - maybe I can give a better answer

  • We have a similar but slightly different problem. Our Cyber team used AWB for a long time and utilized custom filters and suppress capabilities to eliminate noise including false positives. Now we are in the process of building CI/CD pipelines using Jenkins/Ansible to perform the scan by utilizing SCA. Although SCA can produces the scan reports based on some standard templates like "FISMA Compliance", "DISA STIG" etc. but it seems to be impossible to provide the same dynamic capabilities in AWB to filter and suppress findings for SCA implementation in CI/CD. 

    What is the best way to carry the same filter and suppress configuration metadata to SCA and produce the same scan reports that will match with the AWB reports? 

    If it is not feasible, what is the best path meet the Cyber team's requirements to have the same AWB functionality available in CI/CD pipelines? That may include some additional tools etc.


  • the SSC is the server - this handles the elimination of issues based on audits.
    The SCA is a client. Each scan will see the same issues if not fixed to Fortify's liking.

    It seems to me you should consider using an SSC?

  • My Cyber team controls the adjudication process from SSC, where developers and Cyber Security Engineers collaborate to resolve scan issues together. Dev can use the AWB to do detail analysis of scan issues but they are not allowed to upload scan artifacts to SSC. By disallowing uploads, Cyber has a comfort level of scan issues not being hidden or suppressed in AWB. Trust BUT Verify.