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

shooking_sap 10 months ago

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:

devops

shooking_sap 10 months ago
I was thinking something like https://futurestud.io/tutorials/github-actions-run-on-pull-request#:~:text=Clone%20Another%20Repository-,Run%20Actions%20on%20Pull%20Requests,%5D%20and%20you're%20done.

(excerpt from above)

Here’s a sample configuration to run your action when pushing code to the repository or on pull requests:

name: Run tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - name: … and I would have thought the following direction would be involved

git pull (from master to my current branch)

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

some check for NOOP (like someone checks directly into master from master)

and for the PR - git push

{ "previousProjectVersionId": branchPVID, "projectVersionId": masterPVID }
Cancel
Vote Up 0 Vote Down

Cancel

Menu

Fortify After Hours Discussions

Handling pull requests with Fortify SSC

Tags:

Resources