SSC: Add commands to create SSC reports

[kadraman]

It would be very useful to be able to create and download SSC reports for an Application Version. This could be done via "fcli ssc reports" subcommand and could be equivalent of what is available in the SSC JavaScript sandbox: https://fortify.github.io/ssc-js-sandbox-docs/#/2017/08/03/generateReport

[rsenden]

Any suggestions on what the command line options for the fcli ssc report generate command should look like, in particular for specifying report parameters?

[kadraman]

I have a script to create and download an ssc report and I had to specify the whole of the JSON (attached) and replace project id etc!. To start with we could just ask for report JSON as input and replace project id etc? ???

Do we want separate command:

fcli ssc report create/wait-for/download/delete

or a single command "generate" as you suggest.
fortify-ssc-report.ps1.txt

[rsenden]

As for the command structure; I'm not sure whether to use create or generate; the latter may be more descriptive, whereas create is more consistent with other entities. Definitely we'd also have the other wait-for/download/delete commands.

As for specifying report parameters, I don't think requiring users to create a JSON file is very user-friendly. We could potentially do one or more of the following:

1. Have a command which, given a report definition name like 'Application Summary', generates a YAML file that lists all report parameters for that particular report, together with comments explaining allowed values for each parameter. Users can then fill in the YAML file and pass it to the create command.
2. Provide a repeatable -p|--report-param option to allow specifying each option value on the command line
3. Interactively prompt for report parameters (useful for interactive use, not useful for automations)

Independent of which option we choose, users should be able to work with 'friendly' names rather than id's, i.e. specify OWASP Top 10 version by name instead of external list id, specify <app>:<version> instead of id, ...

#1 somewhat corresponds to how things are done for creating/uploading report definitions, although in general I'm not a big fan of using files to describe input. The file needs to be stored somewhere (source code repo?), and to understand what a particular command in a pipeline is doing exactly, you need to look at the file contents instead of seeing it directly in command line options.

On the other hand, it does allow for simple reuse of existing report generation definitions, and saves you from having to manually specify all of the report parameters every time you want to manually regenerate a particular report with the same settings.