Current action framework requires an active product session when running an action. Especially if we ever want to implement pipeline-style actions, it would be good if we can automatically start a session upon action initialization, and terminate the session upon action termination, to avoid users/integrations from having to explicitly run login and logout commands. Two generic approaches come to mind:
Simply have the action run command accept session options like URL & credentials:
If provided, the command will automatically start a session and terminate it upon action termination.
If not provided, an existing session must exist (same as current implementation).
Allow actions to explicitly state that they don't require an existing session, and have the action run the login and logout commands
First option is more generic and works the same for all actions. Second option allows for more flexibility, for example if an action needs to establish multiple sessions (multiple SSC instances, multiple products like SSC & SC-SAST or SSC & FOD, ..., for example for data migration actions).
Closely related to this is with pipeline-style actions that may need access to multiple product modules, in particular SC-SAST & SSC or SC-DAST & SSC, i.e., for starting a scan (using sc-sast scan commands) and then exporting scan results (using ssc action commands). Those actions would either need to be able manage multiple sessions, or we need to implement some approach where an sc-sast session can also be used for accessing ssc commands.
We may even want to consider having all products consolidated into a single module, i.e., move sc-sast and sc-dast commands into the ssc module, as this is more like how things are organized in the fod module. From a user perspective, this would make session management much easier, as they only need a single session to work with those 3 products (although selecting a proper SSC token type and managing SC SAST client-auth-token would require some thought).
Apart from the above, there may be use cases where actions are not (directly) related to any particular product module, for example if we'd want to provide a pipeline-style action that can start a scan on either FoD or SC-SAST/DAST based on input parameters. It wouldn't make much sense to provide this action in either SSC or FoD modules (as users would see FoD-specific options in SSC module and vice versa), to we may also want to support product-agnostic actions. Primary question is where this should live; fcli action *, fcli util action *, ...?
Current action framework requires an active product session when running an action. Especially if we ever want to implement pipeline-style actions, it would be good if we can automatically start a session upon action initialization, and terminate the session upon action termination, to avoid users/integrations from having to explicitly run
loginandlogoutcommands. Two generic approaches come to mind:action runcommand accept session options like URL & credentials:loginandlogoutcommandsFirst option is more generic and works the same for all actions. Second option allows for more flexibility, for example if an action needs to establish multiple sessions (multiple SSC instances, multiple products like SSC & SC-SAST or SSC & FOD, ..., for example for data migration actions).
Closely related to this is with pipeline-style actions that may need access to multiple product modules, in particular SC-SAST & SSC or SC-DAST & SSC, i.e., for starting a scan (using
sc-sast scancommands) and then exporting scan results (usingssc actioncommands). Those actions would either need to be able manage multiple sessions, or we need to implement some approach where ansc-sastsession can also be used for accessingssccommands.We may even want to consider having all products consolidated into a single module, i.e., move
sc-sastandsc-dastcommands into thesscmodule, as this is more like how things are organized in thefodmodule. From a user perspective, this would make session management much easier, as they only need a single session to work with those 3 products (although selecting a proper SSC token type and managing SC SAST client-auth-token would require some thought).Apart from the above, there may be use cases where actions are not (directly) related to any particular product module, for example if we'd want to provide a pipeline-style action that can start a scan on either FoD or SC-SAST/DAST based on input parameters. It wouldn't make much sense to provide this action in either SSC or FoD modules (as users would see FoD-specific options in SSC module and vice versa), to we may also want to support product-agnostic actions. Primary question is where this should live;
fcli action *,fcli util action *, ...?