Visitor.
214 views

Properly and automatically propagating audit metadata in CI workflow

Hi folks - 

I seek clarity on how Fortify can be best integrated into a CI based workflow.  

This is a follow up to the only other thread that discusses this topic:  SSC Application Version Git Jenkins Automation Workflow FPR Merging 

For context, my CI infrastructure automatically creates pipeline jobs for every branch and pull request that is created in monitored git repositories, and automatically runs the appropriate job when commits are pushed to a branch.  That pipeline includes a Fortify scan. 

The previous thread went a little off the rails with the participants talking past each other, so I will describe the  typical workflow (and resulting automation in italics) explicitly:

  1. Developer creates a new branch 'feature_foo' off master in order to develop a new feature, makes changes in support of that  and pushes changes to bitbucket.   For the sake of discussion, let's presume his changes introduce a new vulnerability.
    1. A new pipeline job is created and run against that branch. 
    2. The pipeline notes that a version named 'feature_foo' does not exist in the SSC project corresponding to this repo, so it creates a new one initialized from master.
    3. The pipeline scans the branch and uploads the FPR to SSC
    4. SSC reports to the pipeline that a new error exists, causing the pipeline job to abort.
  2. Developer examines the version 'feature_foo' in the SSC interface, determines that the vulnerability detected is a false positive, makes a comment and audits it as a nonissue.  Developer goes to Jenkins and triggers the pipeline job manually for their branch.
    1. The pipeline scans the codebase, and uploads the FPR
    2. SSC reports to the pipeline that there are no new issues, the pipeline passes
  3. Developer creates a pull request to master through the SCM UI
    1. A new pipeline job is created  and run for PR-XXX (where XXX is an integer) that operates on the result of rebasing the branch on top of master.
    2. The pipeline notes that a version named 'PR-XXX' doesn't exist and creates it, initializing it based on the 'feature_foo' version
    3. The pipeline scans the codebase, and uploads the FPR
    4. SSC reports to the pipeline that there are no new issues, since the issue audit status was inherited from the branch, the pipeline passes
  4. Developer is then able to merge the pull request by clicking 'merge'
    1. The pipeline job for master is triggered, which scans and uploads the FPR to SSC.
    2. SSC reports the false positive as a new issue, causing the jenkins job to fail
  5. Developer goes into SSC, audits the issue as a false positive and re-enters his comment.  Developer then manually triggers the master job.
    1. The pipeline job for master is triggered, which scans and uploads the FPR to SSC.
    2. SSC reports to the pipeline that there are no new issues, the pipeline passes

Now, based on my reading of the thread I linked above, everything in red (4.2 and after) should not be necessary.  Based on my reading and understanding of the very last post in that thread, when SSC is processing the FPR for master after the branch was merged, it should have assigned the same issue ID to the detected vulnerability, and thus the suppression should have carried over.  Is that a correct understanding?

What I am observing in practice is that the same vulnerability is detected in both places and assigned the same issue ID.   Any comments or auditing done to an issue in one version is not reflected in the other version.  As a result, my engineers are having to waste time auditing the same issue over and over again. 

Could someone clarify my understanding, and comment on whether the above is expected behavior?

Labels (1)
Tags (1)
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.