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 pull requests with Fortify SSC

So how are you doing this at your company?

In the past the SSC ran against a "monolith" build - 6 months release cycle. Regular scans (daily, weekly) ... Sec experts divvy out findings to a team - repeat.

Nowadays we have lots of micro services/mini projects that build reqularly, many branches etc.

NOW - if people actually fixed code (where both the dev and Fortify agree) or added models - then the issue are truly fixed and are no longer reported.

However, the trend is to audit issues away. And of course this is often the legitimate way of dealing with an issue.

In branch N ... of an active project-version.

I can see how one could generate N versions to handle each branch.

I can see that each branch can audit away.

I can see that when a branch pushed back to master then they would also need to push the current state of their FPR into master.

22.1.x has newer API calls /projectVersions/action/copyCurrentState => 

{
"previousProjectVersionId": branchPVID,
"projectVersionId": masterPVID
}


Then build again in master ... it should have:

  • merged in the branched code
  • the audits,
  • checked state of new build with merged audits
  • fixes automatically applied - although they could hit new issues in the master branch

but I still then have to so a similar copyCurrentState into any branch that "git pulls"

Anyone implemented anything like this?

Tags: