-
-
Notifications
You must be signed in to change notification settings - Fork 1k
build: capture govulncheck results as Code Scanning alerts
#2084
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Kusari Analysis Results:
Combined security analysis shows no actual vulnerabilities or security concerns. Both dependency and code analyses found clean results. The single detection was correctly identified as a false positive - a commit-pinned GitHub Action reference representing security best practices, not an exposed secret. No dependency issues, code vulnerabilities, or workflow problems were detected across both analyses. Note View full detailed analysis result for more information on the output and the checks that were run.
Found this helpful? Give it a 👍 or 👎 reaction! |
|
@kusari-inspector feedback if we can get "Recommended Code Changes" being provided as: blocks, that'd be easier to accept changes! |
|
Thank you for your feedback! 📝 Your message has been submitted for review. |
1f5afda to
86cedaa
Compare
|
Kusari PR Analysis rerun based on - 86cedaa performed at: 2025-09-11T10:46:03Z - link to updated analysis |
Related to [0] and regular questions we've had in the past, we don't have a clear answer for "are we vulnerable to a CVE" in a way that our users are clearly able to determine, as well as "will oapi-codegen fix it". As a step towards answering the former, and leading towards the latter, we can start running `govulncheck` in CI as a way to ensure that we always have that information to hand. This will re-run on commits to HEAD, as well as on a schedule, to make sure we're aware of new CVEs. By producing this in SARIF format, we can then have this uploaded to GitHub's Code Scanning alerts, which are more straightforward to validate. The Code Scanning alerts page is gated to maintainers, but doesn't (currently) hide anything that can't be seen by someone running `govulncheck` themselves on the project. We also make sure to explicitly note what permissions are required to handle the workflow. [0]: oapi-codegen/governance#11
86cedaa to
af833ea
Compare
|
Kusari PR Analysis rerun based on - af833ea performed at: 2025-09-11T10:55:34Z - link to updated analysis |
Related to 0 and regular questions we've had in the past, we don't
have a clear answer for "are we vulnerable to a CVE" in a way that our
users are clearly able to determine, as well as "will oapi-codegen fix
it".
As a step towards answering the former, and leading towards the latter,
we can start running
govulncheckin CI as a way to ensure that wealways have that information to hand.
This will re-run on commits to HEAD, as well as on a schedule, to make
sure we're aware of new CVEs.
By producing this in SARIF format, we can then have this uploaded to
GitHub's Code Scanning alerts, which are more straightforward to
validate.
The Code Scanning alerts page is gated to maintainers, but doesn't
(currently) hide anything that can't be seen by someone running
govulncheckthemselves on the project.We also make sure to explicitly note what permissions are required to
handle the workflow.