I'm on the DevOps team of a large organization with a lot of .NET applications. I'm trying to figure out what to recommend for Fortify SSC application version management for some of the larger applications. There doesn't seem to be guidance and there are gaps within the SSC user guide.

For an example application the organization may "go to production" with say "1.0.0" of a shared API, and immediately afterwards there are two separate teams updating this shared application for the next release, "1.1.0-release-abc" and "1.1.0-release-xyz", each working out of their own branch in source control. The team that will go to production first and become the final "1.1.0" release is unknown and may change with business requirements. Say release-xyz goes to Production first, they'll later merge their code to the master branch as "1.1.0" and release-abc will need to merge from master and change their version to "1.2.0-release-abc".

I don't know how to manage this in Fortify SSC and have it make any sense. If I allow the teams to work out of the same version one team may introduce issues that don't affect the other team. They can't go to production until all issues in SSC are resolved or have comments. InfoSec is requiring Fortify scan results to move forward in release pipelines but release management requires deploying successfully before merging into a master branch. I could have a unique application version in SSC for every branch but then any issue comments associated with one version will have to be resubmitted when code bases merge. These are very large code bases with maybe hundreds of comments and false positive or non-impactful items that have to be tracked.

Has anyone come up with a solution or best practices for this?

Also it's not clear to me what happens when FPRs from separate source branches are uploaded to the same application version. I would expect that the last FPR uploaded would be the definitive list of active issues but SSC seems to show a mixture of issues from both the most recent FPR and issues from previous FPRs. I read that it merges results but how does it decide when an issue has been removed/resolved because it's no longer in code? Deleting scan results seems to make some issues disappear but what are the actual rules for how this happens? Many of our apps have 100s of artifacts still linked to them from uploads through the years so am I expected to delete these old ones? Or is it intended for new versions to represent clean slates? How does this interact with creating a new application version by copying a previous one (to retain the issue comments)?

Thanks.