Enforce presence of mandatory properties in the Security Reports

Problem to solve

Reports generated by our Analyzers are leveraging the Issue struct of the common library.

Now that we store reported vulnerabilities in DB, some of these properties are mandatory.

We should enforce the presence of these properties and report entries with missing one as errors.

This will be even more necessary if we want to make this API public.

Proposal

  1. Find a way to validate presence of some properties in the go structs reported by the analyzers
  2. Find a way to report errors:
    • A. Ignore (don't report) and log warnings for incompatible entries
    • B. Report errors (this requires to first change the format of the report to allow structured output instead of just an array)

List of mandatory properties:

Issue struct:

  • Category (should be probably renamed to ReportType): Values are SAST, DS, CS, DAST. This is necessary to correctly classify the vulnerability, to display it in the right area and use filters in dashboards.
  • Message (should be probably renamed to Name, and existing Name property dropped): This is the main text describing the vulnerability and display it in the UI.
  • CompareKey (probably deprecated before implementing this): This is mandatory to have the feedback feature working, at least until we rewrite code and move report artifact parsing on BE.
  • Scanner struct:
    • Id : Mandatory to identify the scanner (unique in DB)
    • Name: Necessary to be display scanner as id might not be a human friendly value.
  • Location struct: (should have at least one property, depending on report type) This is necessary to identify the vulnerability (file, line, docker layer, component, url, etc...) and distinguish it from other occurrences. Might as well be used to recognize vulnerability when code is updated.
  • Identifiers array: (should have at least one entry)
    • Type: Mandatory to identify the Identifier (unique in DB with Value)
    • Value: Mandatory to identify the Identifier (unique in DB with Type)
    • Name: Necessary to be displayed as Type + Value might not be a human friendly value.

What does success look like, and how can we measure that?

Invalid vulnerabilities are not included in the report, warnings are shown or errors reported.

Links / references

Edited by Olivier Gonzalez