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
- Find a way to validate presence of some properties in the go structs reported by the analyzers
- 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 toReportType
): 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 toName
, and existingName
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 withValue
) -
Value
: Mandatory to identify the Identifier (unique in DB withType
) -
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