Problem Validation: Progress Secure Report Format schemas beyond `release-candidate`

Problem to solve

The Security Report Format has been converted into a JSON schema (see security-report-schemas). The schema built is currently in a release-candidate phase. This phase reflects the lack of maturity and volatility of change happening to the schemas.

This issue attempts to capture the work required to mature the schemas to the point that they are no longer considered as a release-candidate. Once this is complete, schemas can be considered ready to expose to third parties for integration.

Intended users

• External Software Engineers
• External Product Managers
• Sasha (Software Developer)

Proposal

Suggested work that is required before schemas are considered ready for release:

1. An engineer knowledgeable of CS should verify that all fields are present, required fields added, and descriptions are accurate.
2. An engineer knowledgeable of DS should verify that all fields are present, required fields added, and descriptions are accurate.
3. An engineer knowledgeable of DAST should verify that all fields are present, required fields added, and descriptions are accurate.
4. An engineer knowledgeable of SAST should verify that all fields are present, required fields added, and descriptions are accurate.
5. The CI Templates project should be updated to verify the JSON created by an analyzer adheres to the pinned Secure Report Format version. #216901 (closed)
   • All analyzer pipelines should be executed with the above CI template check to verify that each analyzer conforms to the schema.
6. DAST end to end tests should verify that each JSON file created adheres to the pinned Secure Report Format version.
7. The Container Scanning documentation should be updated to refer to the JSON schema.
8. The Dependency Scanning documentation should be updated to refer to the JSON schema.
9. The SAST documentation should be updated to refer to the JSON schema.
10. The DAST documentation should be updated to refer to the JSON schema. #213337 (closed)
11. The verify-versions.sh script should be edited to remove -rc1.
12. The latest version (as defined by the most recent CHANGELOG entry) of the security-report-schemas should be re-released, but without the -rc1 suffix.
13. The Rails implementation should verify when parsing a Secure Report that it adheres to the schema #34654 (closed)
14. (nice to have) Examples should be added to every field in the JSON schema.
15. (nice to have) A one click release job should be added to the master security-report-schemas pipeline. This means everyone has equal opportunity and ability to release.
16. (nice to have) A Brown bag session should be scheduled to ensure Secure engineers have an opportunity to learn how to use and change the schemas. gitlab-org/secure/brown-bag-sessions#11 (closed)
17. The release.sh script should be edited to remove -rc1.

What is the type of buyer?

Gold/Ultimate

Is this a cross-stage feature?

This affects all of Secure.