Add action to export code scanning alert to a SARIF file

[alcaeus]

The new code-scanning-export action allows exporting open and dismissed code scanning alert to a SARIF file, which we can then submit as a release artifact. The action makes a best effort to fill in tool information along with the rules, and adds suppression elements to all dismissed alerts.

To test this action, you can use the following two steps in a GitHub Actions job:

- name: "Export SARIF file from code scanning alerts"
  uses: "alcaeus/drivers-github-tools/code-scanning-export@export-code-scanning-report"

- name: "Attach generated SARIF file to build artifacts"
  uses: actions/upload-artifact@v4
  with:
    name: code-scanning-alerts.json
    path: code-scanning-alerts.json
    retention-days: 3

In my case, I ran the steps directly after uploading the SARIF file from an external tool. Note that the tool can only produce results if analysis of the code scanning report has completed (which is the default when uploading a SARIF file to Code Scanning). In case of using CodeQL in GitHub Actions, add the two steps after running the github/codeql-action/analyze action.

If the artifact is successfully uploaded, you can use a validator (e.g. Microsoft's SARIF Validator) to validate that the file is valid. If the action failed or if the generated SARIF report is invalid, please report back so we can add the responsible alert to our test suite.

Note that in my case the validator complained about the tool not having a informationUri property. This is not exposed in our alerts, but it may be in yours in which case we can add it to the report.

TODOs:

• npm run lint currently reports errors (see CI pipeline)
• Update the README
• Test with some other tools and add tests for their reports

[blink1073]

Should the dist folder be added to .gitignore?

[alcaeus]

The dist folder is needed to actually run the GitHub action - maybe it should just be removed from the pre_commit check.

[blink1073]

maybe it should just be removed from the pre_commit check.

SGTM

[blink1073]

Can you point to a run where you're testing this? I tried with winkerberos and it doesn't seem to be finding the ref I just uploaded.

blink1073/winkerberos#26
https://github.com/blink1073/winkerberos/actions/runs/9270093082/job/25502292926?pr=26

[baileympearson]

I'm seeing similar behavior. It seems like, even though the repo has dismissed codeql alerts, the alerts are not returned by the github API.

Example when I specify ref: main: https://github.com/mongodb/node-mongodb-native/actions/runs/9276917785/job/25525053266?pr=4124
Example when I use the current PR: https://github.com/mongodb/node-mongodb-native/actions/runs/9276879879/job/25524932613?pr=4124

(I cat the file in the asdf step)

I'm going to test further tomorrow on a fork, I think it may work if I grab all codeql alerts for a given release tag instead of the current PR.

Update:

Grabbing alerts for a tag did not work. I'm going to instead grab alerts for the target release branch, since in Node's workflow we'll have already run CodeQL scans on each commit to the target branch.

[baileympearson]

Working great for BSON: mongodb/js-bson#695 (also tested with the driver, and non-empty reports are generated for branches where we have dismissed codeql alerts)

[blink1073]

Working great for BSON: mongodb/js-bson#695 (also tested with the driver, and non-empty reports are generated for branches where we have dismissed codeql alerts)

Great! I'll give it a try with Winkerberos tomorrow

[blink1073]

I'm still getting an empty sarif file on publish, will have to do some more debugging on a fork of this branch.

[blink1073]

It works with pymongo! I just pushed a commit that should fix CI, and made the logs print at info level.

[blink1073]

Thank you!

[alcaeus]

Thanks for testing and fixing issues, @blink1073! Did you get it to work for a tag ref as well or only for a branch ref?

[blink1073]

Did you get it to work for a tag ref as well or only for a branch ref?

I didn't try tag, I think using the branch ref makes more sense unless we explicitly wait on the scan result for the tag.

[alcaeus]

I didn't try tag, I think using the branch ref makes more sense unless we explicitly wait on the scan result for the tag.

Thanks for adding that last part - I may have just found out why it didn't work for y'all. The project I'm testing this with uploads a SARIF report to code scanning using the github/codeql-action/upload-sarif action. By default, that action only returns when the uploaded file has finished processing. When we then go to fetch a report for the tag ref, we can get the up-to-date result.
I assume that since y'all are using CodeQL for scans you don't have results yet at the time of running this action, which would result in an empty SARIF report. If we're confident that the latest checked branch ref will yield the same result as the tag ref, I think it's fine to generate the report from the branch ref. If not, the workflow using this action would have to wait until the CodeQL scan has finished.

[blink1073]

I think we can merge and iterate at this point, I'll attempt to run from a tag once mongodb/mongo-python-driver#1651 is merged.

[alcaeus]

@baileympearson I've left the branch in my fork in place since you seem to be using it in js-bson. Let me know when you've changed that to main so I can remove the obsolete branch.