Add an Analyzer object to the Secure Report Format
Problem to solve
When adding the Scanner object to the report format generated by our analyzers, there was confusion about whether or not the information about the analyzer itself would be relevant. Today, there is no way to report the analyzer version that generated a given Finding for instance.
Intended users
User experience goal
Proposal
We need to ask ourselves if there is real value to add information about the analyzer in the report.
-
List the benefits of having information about the analyzer and which property exactly - Benefits are described in detail in the related issue #329157 (closed)
-
Investigate what would be the impact of adding an analyzerfor the whole architecture- The MR gitlab-org/security-products/security-report-schemas!74 (merged) requests input from the Architecture Council, which has representatives from each Secure group
-
Validate how much this would conflict with the proposal to Extend the Secure Report Format to allow multiple scanners:#235390 - These should be entirely separate changes as they represent separate concepts. The
scan.scannerfield will not be modified with this change, any changes can be covered by #235390. - There is a duplication/error here where
scan.scanner.vendoris incorrectly set toGitLabfor many GitLab analyzers. This error will not be fixed in this issue. - If the proposal to allow multiple scanners means that there is a
MODELchange to the Secure Report Format, then it might be worth making thescan.analyzerfield required.
- These should be entirely separate changes as they represent separate concepts. The
-
Propose an update of the JSON schemas
Further details
Here is a proposal of what could be the report structure:
-
scan.analyzer.id, representing the ID of an analyzer (e.g.dast) -
scan.analyzer.name, representing the name of an analyzer (e.g.GitLab DAST) -
scan.analyzer.version, representing the version of an analyzer (e.g.1.34.0) -
scan.analyzer.url, representing the URL where to find more information about an analyzer -
scan.analyzer.vendor.name, representing the name of the vendor (e.g.GitLab)
Some real examples:
dast
"scan": {
"analyzer": {
"id": "gitlab-dast",
"name": "GitLab DAST",
"url": "https://docs.gitlab.com/ee/user/application_security/dast/",
"version": "1.50.0"
"vendor": {
"name": "GitLab"
}
}
}
Gemnasium
In this case, scanner and analyzer are redundant since they are both mixed in the same project.
"scan": {
"analyzer": {
"id": "gitlab-gemnasium",
"name": "Gemnasium",
"url": "https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium",
"version": "2.13.0"
"vendor": {
"name": "GitLab"
}
}
}
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
- groupcomposition analysis @gonzoyumo @NicoleSchwartz
- groupdynamic analysis @sethgitlab @derekferguson
- groupstatic analysis @twoodham @tmccaslin
- groupthreat insights @thiagocsf @matt_wilson
- ~"group::fuzz testing" @sethgitlab @stkerr
Links / references
Edited by Cameron Swords