SSC: Implement 'ssc vulnerability export' command

[rsenden]

This should replicate the functionality of FortifyVulnerabilityExporter. Initially, this could just wrap a call to the existing FortifyVulnerabilityExporter command, but eventually this functionality should be natively integrated into fcli.

FortifyVulnerabilityExporter is mostly just a JSON transformation utility, transforming Fortify vulnerability data into various other formats based on a configuration file. Currently it is heavily based on Spring Expression Language and just a couple of custom transformation classes. We should investigate the possibility to integrate Spring Expression Language into fcli (which may be difficult due to potentially lacking support for native images), or use a different expression language/JSON transformation library.

[MikeTheSnowman]

Similar to #85.

[rsenden]

As fcli now supports SpEL, it should be fairly easy to add core formatting functionality from FVE into fcli, potentially allowing many of the existing mappings to be re-used. We'll need to do some research as to how to best provide export functionality within fcli. In particular, do we just want to support export of vulnerability data (for feature parity with FVE), or more generic export/formatting functionality supported on other fcli entities as well, i.e. exporting SSC application versions? Below are some idea that come to mind.

Only vulnerability export

We'd only have for example an fcli ssc appversion-vuln export command that provides similar functionality as FVE, exporting the vulnerability data for a single application version to various output formats.

Generic fcli <module> export command

This command would for example have generate-config and generate commands, providing various built-in export configurations like 'vulnerability to ...' configurations to match FVE functionality. The generate command would take (at least) the following inputs:

• Built-in configuration name or external configuration file
• -q/--query for selecting a subset of records
• -d/--destination-dir for selecting the output directory; a configuration could potentially output multiple files (for example BitBucket requires multiple files for each export, and some FVE configuration allow for exporting SAST/DAST/OSS results to separate files in a single run)
• Any input parameters as defined in the given configuration file. From a picocli perspective, this could be represented as:
  • Repeatable option, i.e. --input app-version=RWI:1.0,other-input=abc
  • Positional parameter with arity 0.., allowing the input parameters to look like regular options from a user perspective, i.e. --app-version RWI:1.0 --other-input=abc. Potentially, we could even construct a new picocli CommandLine instance, based on the input parameters defined in the configuration, to parse these parameters

The configuration file could for example look something like the following:

inputs:
  - name: appVersion # export command could convert this to kebab-case for CLI option name,
                     # or we could have separate elements for specifying CLI option name and internal property name
    type: appVersion # Similar functionality as the corresponding resolver, mapping app version name or id to a descriptor,
                     # such that other elements in this configuration can reference for example `inputs.appVersion.id`

source:
  endpoint: /api/v1/projectVersions/${inputs.appVersion.id}/issues
  embed: ... # Similar to FVE, declaring either simple sub-entities (if available), or arbitrary endpoints, optionally 
             # referencing properties from the results returned by the primary endpoint

mapping:
  ... # Similar to FVE

outputs:
  # TBD; define output type (csv, json, yml, ...), file name(s), ...

Generic -o custom=<config> option

This would make export functionality available on every fcli command that utilizes the output framework, allowing any fcli output to be formatted according to the mapping defined in the given configuration (built-in configuration name, or external configuration file), taking into account the other command options like queries, app/version selection, ...

Using this option on list commands with predefined configurations would provide export-like functionality. If needed, users can even use custom output formats for other commands like get commands, thereby providing a lot of flexibility.

However, there are some potential drawbacks to this approach:

• To be consistent with other output formats, the formatted output should be written to stdout by default, with the possibility to use the --output-file option for saving to a file; this only allows for a single output file, so it would be difficult to support BitBucket output, and you'd need to run the command multiple times with different configurations if separate files are required for SAST/DAST/OSS results.
• This somewhat 'hides' export functionality into a generic option, possibly causing users to overlook this major fcli capability.
• It may be more difficult for users to understand which configuration files can be used on which commands, and easy to make mistakes. For example, which entities are supported by a given configuration file, and which commands within that entity?
• It may be impossible/more difficult to reference data from a parent entity, i.e. reference app version data in a 'vulnerability export' configuration.
• We need some place for users to list built-in configurations, save them to an external file to allow for customization, ... This would likely live in the util module, or maybe the config module.

Generic --export options on all list commands

Somewhat similar to the above, with export-specific options being provided through the output framework:

• Doesn't support arbitrary formatting on for example get commands
• Would allow for supporting multiple output files, allowing to specify an output directory using an --export-dir option,, ...
• Command output (stdout/--output-file) would either be the same as without --export, or command output would show export status information (the latter is probably more useful, and potentially more performant in case of large data sets)
• Potentially same difficulties with regards to understanding which configurations can be used with which entities/commands
• Same difficulties with referencing data from a parent entity
• Again need a place for listing built-in configurations, generating sample configurations, ...

[rsenden]

This has been implemented with the new fcli ssc action run *-report commands.