[Help Wanted] Determine attestation format for vuln scans #58
Description
This is a follow-up issue for the sigstore/cosign#442.
I thought it would be more appropriate to continue the discussion for the aforementioned issue, since the spec is non-cosign-related.
With @developer-guy, we are currently trying to determine a vuln scan spec, as far as we can do best. We can enrich the following brand-new attestation SPEC:
{
"_type": "https://in-toto.io/Statement/v0.1",
"subject": [
{
"name": "alpine",
"git_commit": "a1b2c3",
"digest": {
"sha256": "c201c331d6142766c866"
}
}
],
"predicateType": "SARIF",
"predicate": {
"timestamp": "1627564731",
"owner": {
"name": "<WHO_RAN_THIS_SCAN>"
},
"environment": {
"name": "GitHub",
"by": "<PIPELINE_ID>",
"type": "<CI/CD?> (i.e., GitLab Runner)",
"cluster": "us-east1-a.prod-cluster",
"namespace": "<namespace>"
},
"success": true,
"scanners": [
{
"name": "trivy",
"version": "0.19.2",
"db": {
"name": "trivydb",
"version": "v1-2021072912"
},
"timestamp": "1627564731",
"result": "<SARIF RESULT HERE?>"
},
{
"name": "dockle",
"version": "v0.3.15",
"timestamp": "1627564731",
"result": "<SARIF RESULT HERE?>"
}
]
}
}We called the predicateType as SARIF. But I think that name, not fits this type since the content is not in SARIF format. We may have to reconsider the name.
It's obvious that it's a bit hard to think of best practices during the implementation of the first version of the spec. It would be great if you maintainers get involved and give a hand to us to improve the overall structure. So we can easily implement the model into in-toto project in order to do validate and generate the attestation. Is that make sense to you? Thanks! We are waiting for your feedback about this.