Proposal: Version and release Secure Report Schemas independently of each other
Problem to solve
The Secure Report Schemas contain schemas for Secure, including DAST, SAST, Dependency Scanning, Container Scanning and Secrets Detection. Each of these schemas depends on a single Secure Report Format base schema.
All Secure schemas are released at the same time, with the same version. The impact of this design means that a single change to one schema requires all schemas to be released with a new version, even if some schemas actually have no changes.
For example:
- A new optional field is added to DAST.
- The version of the schema is incremented in the base schema to
3.1.0
. -
scripts/distribute.sh
is called, which will recreate the entiredist
folder, creating new schemas for DAST, SAST, CS, DS, and SD. - The schemas are released at version
3.1.0
. - SAST, CS, DS and SD are released as versions
3.1.0
even though they contain no changes.
This is confusing to third parties who are only interested in one kind of schema. They will be notified of a new release, only to discover that nothing has changed.
Also, different Secure schemas have different levels of maturity. For example, SAST has been around a long time and is likely much more mature than a new schema like Fuzzing. Releasing schemas independently of each other means one schema could be considered "General Availability", while another schema is considered "Release Candidate" #215595.
Intended users
Proposal
- Create a new group
Secure Report Schemas
. - Create a new project for each Schema, and a project for the Base schema.
- Each project would essentially be a copy of the current project.
- Scripts/CI templates could be used to make managing multiple projects easy (similar to
ci-templates
). - Each project would have its own CHANGELOG and Releases page.
Documentation
The README should be updated with instructions.
Availability & Testing
What is the type of buyer?
Is this a cross-stage feature?
Yes. Will communicate in Slack.