Merging previous Fortify SCA scan results?

We're  looking at how we can reincorporate comments/tagging analysis performed in previous scans without having to store away the entire previous FPR file.  It appears that this is stored in a simple xml "audit.xml" within the .FPR.  The tooling doesn't seem to provide any way of utilizing this analysis in subsequent scans, short of a full "merge", which requires retaining the entire previous .FPR file.  Ideally, we'd like our developers to comment on issues, save audit.xml as permanent artifact in the project (allowing for diff-merges), then reincorporate the audit results in subsequent scans.

It seems like it would be straightforward enough to replace the empty audit.xml in a new scan with the previous result.  This might have been unanticipated by the developers of the solution, however, and I wanted to get some feedback from HP before attempting to proceed with such a strategy.  Ideally, -merge should be able to accept just audit results, with a complimentary function to export audit results.  Is there a way to formally suggest an enhancement request?

Tags:

  • Hi Matt, at present the merge functionality allows you to carry over all audits from one scan to the next - as long as the code base between the 2 scans is the same. If I understand your request correctly, rather than merging 2 FPR files you want to be able to export the audit results out of an FPR and merge these into a new FPR. Is that correct?

    You can submit formal enhancement requests to fortifytechsupport@hp.com. These will then be filed accordingly and reviewed by our Product Management team. When you submit the request, if you can provide the anticipated workflow with the new functionality that'll help the PM folks.

    Also, are you using SSC Server to manage your results? Many customers will have their scanning scripts such that the results are uploaded to SSC immediately after the scan. These will then be automatically merged with the previous results in the Project and all audit data copied over.

  • While we do have SSC, this is to facilitate developer analysis during the development process.  We personally haven't found SSC well-suited for managing multiple development branches.  I'll submit the enhancement request.