fcli fod issue *: Add support for issue operations at application level

[rsenden]

Enhancement Request

Current fcli fod issue * commands operate at release level, for example listing all issues for a release. Now that FoD supports API endpoints for managing issues at application level, we should allow fcli fod issue * commands to operate at application level as well. We'd need to decide whether these become new commands, or whether existing commands would accept either release or application.

[kadraman]

The new application level command /api/v3/applications/{applicationId}/issue-count-by-severity operates at a different level than the existing fcli fod issue ls command as this uses /api/v3/releases/{releaseId}/vulnerabilities and supports filters, querying etc. I don't think we want to mix these up in a single command. It also returns more details that just "issue counts" Maybe we have fcli fod issue app-summary and fcli fod issue release-summary or maybe fcli fod issue counts [--rel|--app].

[rsenden]

For SSC, we have two issue commands; list and count. It seems like the /api/v3/applications/{applicationId}/issue-count-by-severity endpoint would be more appropriate for a count command, whereas /api/v3/releases/{releaseId}/vulnerabilities is more appropriate for a list command.

It seems a bit weird though to have count operate at application level, and list at release level. Ideally, we'd want to have commands for both listing and counting vulnerabilities at both application and release level. However, I don't see (unless I'm overlooking) an application-level endpoint for listing vulnerabilities, or a release-level endpoint for counting vulnerabilities.

Ideally, if FoD did provide those endpoints, endpoint request parameters should be mostly the same for both application and release level (as everything operates on vulnerability data), so in that case we could implement a single count and a single list command that both support --app and --rel (exclusive options) to process data at either application or release level.

For the count command, ideally this would support flexible grouping & search criteria like the SSC equivalent, like returning issue counts by OWASP category, or even only critical issue counts by OWASP category.

We should probably raise the following FoD enhancement requests:

• Add /api/v3/applications/{applicationId}/vulnerabilities endpoint, supporting same filtering etcetera parameters as /api/v3/releases/{releaseId}/vulnerabilities.
• Add /api/v3/applications/{applicationId}/issue-count and /api/v3/releases/{releaseId}/issue-count endpoints that both support the same grouping and filtering criteria (more flexibility compared to current /api/v3/applications/{applicationId}/issue-count-by-severity endpoint).

Until then, we could potentially (partially) implement such functionality within fcli. For example, to list issues at application level, we could simply iterate over all application releases and filter out duplicate issue instance id's. To count issues at release level by severity, we could make a simple call to /api/v3/releases/{id}, which returns critical etcetera properties. For consistency with ssc issue count and to potentially support different grouping types later on, each issue count should be returned as a separate row, instead of having a single row with criticial, high, ... properties.