Summary
When uploading multiple SARIF files to GitHub Code Scanning (e.g., one per validated OSCAL document), each file needs a unique runs[].automationDetails.id so they are treated as separate analyses. Without this, uploads overwrite each other and alerts from earlier files get closed.
Current Behavior
oscal-cli (and the underlying metaschema-java SARIF generation) does not include automationDetails in the SARIF output. This requires post-processing with jq to inject it before uploading to GitHub.
Expected Behavior
The SARIF output should include a unique automationDetails.id per run, derived from the validated file path or name. For example:
{
"runs": [{
"automationDetails": {
"id": "oscal-validation/content/nist/NIST_SP-800-53_rev5_catalog/"
},
...
}]
}
The id field is interpreted as category/run-id by GitHub. The category portion (before the final /) determines which analysis group the results belong to.
Context
Summary
When uploading multiple SARIF files to GitHub Code Scanning (e.g., one per validated OSCAL document), each file needs a unique
runs[].automationDetails.idso they are treated as separate analyses. Without this, uploads overwrite each other and alerts from earlier files get closed.Current Behavior
oscal-cli (and the underlying metaschema-java SARIF generation) does not include
automationDetailsin the SARIF output. This requires post-processing withjqto inject it before uploading to GitHub.Expected Behavior
The SARIF output should include a unique
automationDetails.idper run, derived from the validated file path or name. For example:{ "runs": [{ "automationDetails": { "id": "oscal-validation/content/nist/NIST_SP-800-53_rev5_catalog/" }, ... }] }The
idfield is interpreted ascategory/run-idby GitHub. The category portion (before the final/) determines which analysis group the results belong to.Context