Fortify Jenkins setup
I am new to fortify and trying to figure out new issues from scan
We use jenkins to build and upload the scans to ssc. Within ssc we mark false positives but don't bring it down to jenkins. Thus the fpr available in the Jenkins is newly created fpr
Using CLI, I need to find if there are any new issues introduced in this scan. I have access to past fprs from ssc and I can merge these using FPRUtility.
I saw FPRUtility has filter 'issue age:new' filter but not sure how I can use it. If I use that filter on merged fpr, I don't get the same result that I can see in on ssc (even though no newbugs were introduced). What is the correct way to find out, using cli, new issues introduced?
Thanks in advance
Re: Fortify Jenkins setup
Before experts answer, I can share a simple (but probably not the most precise) approach where I output the plain text of findings from the downloaded FPR, analyze using that same FPR (which supposedly could apply existing SSC suppressions against similar new findings), then output the list of findings into another file, then coalesce line numbers, then GNU diff -u the files. This would produce new findings in lines starting with "+" (modulo important findings of existing category in same files).
To output findings, I use the following (avoiding CMD misinterpreting less-than, greater-than, exclamation-mark),
FROOT/jre/bin/java -d64 -Xmx4096M -jar FROOT/Core/lib/exe/fpr-utility-exe.jar -project APP.fpr -information -search -query "[OWASP Top 10 2013]:A [fortify priority order]:!low [fortify priority order]:!medium file:!EXCLUDE1_MASK" -categoryIssueCounts -listIssues
For coalescing line numbers, I use
sed -e 's/:[0-9]\+//' findings.txt | uniq
Re: Fortify Jenkins setup
Thanks to my colleague, to Paul Kitor's session with us and my couple of Bash one-liners, we figured that suppressing an issue in SSC does not reflect in downloaded FPRs until an FPR is uploaded and processed by SSC. This resulted in my download-analyze-upload-list script showing the suppressed issue as unsuppressed in the first run following the suppression.
The discovery that the suppression merge occurs in SSC and not in SCA (no thanks to SSC documentation) made me change my script to the following sequence: analyze-upload-wait-download-list. This change allowed the script to sense the issue suppression on the first run after suppressing.
The wait between the upload and download needs to be added to the script (in the original sequence, the wait was implicit relying on the interval between the script runs). I see api/v1/projectVersions/PROJ_ID/artifacts allows to check for the scan's processing status after finding the scan by its ID that was issued in response to resultFileUpload.html.