Closed rsenden closed 4 months ago
Similar to #85.
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.
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.
fcli <module> export
commandThis 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:
-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)--input app-version=RWI:1.0,other-input=abc
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 parametersThe 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), ...
-o custom=<config>
optionThis 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:
--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.util
module, or maybe the config
module.--export
options on all list
commandsSomewhat similar to the above, with export-specific options being provided through the output framework:
get
commands--export-dir
option,, ...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)This has been implemented with the new fcli ssc action run *-report
commands.
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.