Make scan.messages in secure report schema optional
Problem to solve
A scan.messages
required field was introduced to the secure report schemas as part of Add a scan object to the json schema, however, we're currently publishing reports without populating this field. There's an issue to populate the scan.messages
field: Add scan.messages to SAST, CS, DS reports, but we're still in the process of deciding what information to add. In the meantime, we should update the secure report schemas so the scan.messages
field is an optional property, which will allow our reports to adhere to the defined schema.
Intended users
User experience goal
The secure reports generated by our analyzers should adhered to the secure report schema
Proposal
Expand for old proposal
-
Add new
Messages
member to theScan
Go struct defined in report.go in the common/issue package.- MR link goes here
-
Add
messages
to the Config exposed by common/command package, and update the run command to leverage this struct when generating the report.- MR link goes here
-
Upgrade the
common
dependency in analyzer projects depending oncommon/command
, and release versions.-
SAST
-
security-code-scan
- MR link goes here
- Release link goes here
-
[flawfinder](MR link goes here
- MR link goes here
- Release link goes here
-
brakeman
- MR link goes here
- Release link goes here
-
eslint
- MR link goes here
- Release link goes here
-
spotbugs
- MR link goes here
- Release link goes here
-
gosec
- MR link goes here
- Release link goes here
-
bandit
- MR link goes here
- Release link goes here
-
phpcs-security-audit
- MR link goes here
- Release link goes here
-
sobelow
- MR link goes here
- Release link goes here
-
pmd-apex
- MR link goes here
- Release link goes here
-
kubesec
- MR link goes here
- Release link goes here
-
java-gradle
- MR link goes here
-
security-code-scan
-
Dependency Scanning
-
bundler-audit
-
analyzer
- MR link goes here
- Release link goes here
-
tests
- MR link goes here
- Release link goes here
-
analyzer
-
retire.js
- MR link goes here
- Release link goes here
-
gemnasium-python
-
analyzer
- MR link goes here
- Release link goes here
-
tests
- MR link goes here
-
analyzer
-
gemnasium-maven
-
analyzer
- MR link goes here
- Release link goes here
-
tests
- MR link goes here
-
analyzer
-
bundler-audit
-
SAST
-
Upgrade projects that don't depend on
common/command
-
SAST
-
secrets
- MR link goes here
- Release link goes here
-
nodejs-scan
- MR link goes here
- Release link goes here
-
secrets
-
Dependency Scanning
-
gemnasium
-
analyzer
- MR link goes here
- Release link goes here
-
tests
- MR link goes here
-
analyzer
-
gemnasium
-
Container Scanning
-
klar
- MR link goes here
- Release link goes here
-
klar
-
Fuzzing
-
gitlab-cov-fuzz
- MR link goes here
- Release link goes here
-
gitlab-cov-fuzz
-
SAST
Make the scan.messages
field optional
in the Secure Report Schemas
Availability & Testing
To be tested as part of QA, when comparing generated reports with expected ones.
What does success look like, and how can we measure that?
An empty scan.messages
array will be output in secure reports
What is the type of buyer?
GitLab Ultimate Enterprise Edition
Is this a cross-stage feature?
Yes, this issue covers all analyzer projects except DAST.
Links / references
gitlab-org/security-products/security-report-schemas!47 (comment 422406506)