The current common format has been created from scratch, and will evolve a lot with time and as we add new features in GitLab. Vendors are starting to use this format, and will suffer from these changes, some of them could be breaking changes. We already have a versioning in place, but I wonder if there a format out there that would be "standard" (supported by an org like NVD, Mitre, or OWASP).
This issue is a placeholder to start discussions on this topic, and gather our findings.
SARD/Testsuite does not have any standard result format, in spite of the fact that this is exactly the type of project that should have a standard reporting format.
Vulntology is not relevant for our work.
OSCAL is to describe Access Controls - not vulnerabilities.
Retire.js has a format, but the format is proprietary to retirejs. It is not very detailed. GitLab currently covers all the fields that RetireJS has in its reports.
@plafoucriere I'm not sure we'll ever find a replacement for the common format but we can try
The main reason for me is that we're building that format to fulfill some needs that are specific to GitLab. This means sooner or later we'll need to superset that standard, or be blocked by it.
Also, I think that our features (and thus the corresponding report format) are going beyond the usual reporting capabilities. Mainly, we not only need to share a status at a given point in time, but we need data that allow us to e.g. track vulnerabilities over time and to be able to aggregate them in a consistent way, whatever how heterogeneous the scanners are.
Finally, when reviewing formats, we should distinguish these made to report known vulnerabilities from these made to report occurrences of these vulnerabilities in the context of a project. It's subtle but there is a difference. E.g. https://github.com/RetireJS/retire.js/blob/master/repository/jsrepository.json is for the former, while we need the later.
@plafoucriere I'm not sure we'll ever find a replacement for the common format but we can try
I'm not sure either, I just don't want to wake one year from now discovering something was kind of standard, used by a lot of companies in the security space, and could have saved us a lot of questions and work :)
The main reason for me is that we're building that format to fulfill some needs that are specific to GitLab. This means sooner or later we'll need to superset that standard, or be blocked by it.
Perhaps that is an avenue worth investigating rather than to be avoided. If indeed there is an existing standard for reporting vulnerability occurrences that's similar to ours, I could see using that as a base and having GitLab extensions. It might increase 3rd-party adoption if there's a spec they may already be using or that we could point to as an accepted industry practice.
Of course there may be too many unique cases we're handling for that to be feasible. In that instance, perhaps we eventually define our own standard for vulnerability instance reporting? If there's truly some unique value in our common report format, I can see trying to push for that to be an open standard of cross-tool vuln reporting.