Now that fcli provides support for exporting vulnerability data through the various *-report actions, and with the upcoming deprecation of FortifyVulnerabilityExporter (FVE), we should replace FortifyVulnerabilityExporter invocations with fcli fod/ssc action run github-sast-report invocations.
This should be mostly a drop-in replacement, although session management might be a complicating factor. With FVE, we simply passed SSC credentials, whereas with fcli, we need to run a session login command before we can run the action run command. Question is how to best handle the SSC/FoD session, also taking into account that the ssc-export/fod-export actions may either be used directly from a user workflow, or invoked as part of the composite fod-sast-scan or sc-sast-scan actions.
If used as a stand-alone action, the *-export actions would be responsible for running the session login and session logout commands, but when used from within the *-scan composite actions, we'd likely want to reuse the session set up by that composite action (note that the sc-sast-scan action currently doesn't set up an SSC session, but it will need to do so for other enhancements like running a check-policy action).
So, we'll need to implement some approach that allows the *-export actions (or ideally the appropriate *-login/*-logout actions) detect whether a session already exists, and then re-use that session instead of creating a new session. Obviously, when implementing this in the *-login/*-logout actions, we'd need to ensure that logout is only invoked once all sub-actions have completed, i.e., the fod-export action shouldn't log out of a session created by the fod-sast-scan action. We could keep track of the number of times that the login/logout actions have been invoked, or maybe somehow detect and store which caller (workflow/composite action) was responsible for running the login command, and only run the logout command when being called from the same caller.
Enhancement Request
Now that fcli provides support for exporting vulnerability data through the various *-report actions, and with the upcoming deprecation of FortifyVulnerabilityExporter (FVE), we should replace FortifyVulnerabilityExporter invocations with
fcli fod/ssc action run github-sast-reportinvocations.This should be mostly a drop-in replacement, although session management might be a complicating factor. With FVE, we simply passed SSC credentials, whereas with fcli, we need to run a
session logincommand before we can run theaction runcommand. Question is how to best handle the SSC/FoD session, also taking into account that thessc-export/fod-exportactions may either be used directly from a user workflow, or invoked as part of the compositefod-sast-scanorsc-sast-scanactions.If used as a stand-alone action, the
*-exportactions would be responsible for running thesession loginandsession logoutcommands, but when used from within the*-scancomposite actions, we'd likely want to reuse the session set up by that composite action (note that thesc-sast-scanaction currently doesn't set up an SSC session, but it will need to do so for other enhancements like running acheck-policyaction).So, we'll need to implement some approach that allows the
*-exportactions (or ideally the appropriate*-login/*-logoutactions) detect whether a session already exists, and then re-use that session instead of creating a new session. Obviously, when implementing this in the*-login/*-logoutactions, we'd need to ensure thatlogoutis only invoked once all sub-actions have completed, i.e., thefod-exportaction shouldn't log out of a session created by thefod-sast-scanaction. We could keep track of the number of times that the login/logout actions have been invoked, or maybe somehow detect and store which caller (workflow/composite action) was responsible for running the login command, and only run the logout command when being called from the same caller.