Summary
Security findings exist only as job output. A failing dependency audit or secret scan fails the build, which is correct, but the finding is not recorded anywhere durable: there is no inventory of what is currently open, no history of when a finding appeared or was resolved, and no way to triage or dismiss a false positive other than editing an ignore file and committing it.
Details
.github/workflows/audit.yml runs the dependency audit and the secret scan, and both communicate purely through exit codes and log output. Nothing is uploaded to the repository's code-scanning inventory, so a project has no view of its security posture over time - only a sequence of passing or failing builds.
Emitting findings in the standard static-analysis interchange format and uploading them puts them in the repository's security tab with history, per-finding state, and the ability to dismiss a false positive with a recorded reason instead of a committed ignore entry.
Two constraints are worth designing for. The upload depends on a repository entitlement that not every consumer project will have, so a missing entitlement must not turn into a build failure or - worse - mask a real finding. And the build must still fail on findings independently of whether the upload succeeded, so the gate does not become dependent on the reporting.
This is GitHub Actions only. CircleCI has no equivalent destination, so the two providers will be deliberately asymmetric here.
Acceptance criteria
- The dependency audit and the secret scan emit findings in the standard interchange format and upload them to GitHub code scanning under distinct categories.
- The build still fails on findings through a step that is independent of the upload.
- A repository without the required entitlement does not fail the build because of the upload, and does not lose the finding.
- The behaviour is fenced so projects that deselected a scanner do not receive its upload step.
- The asymmetry with CircleCI is stated in the documentation rather than left to be discovered.
- Documentation covers where findings appear and how to dismiss a false positive.
Summary
Security findings exist only as job output. A failing dependency audit or secret scan fails the build, which is correct, but the finding is not recorded anywhere durable: there is no inventory of what is currently open, no history of when a finding appeared or was resolved, and no way to triage or dismiss a false positive other than editing an ignore file and committing it.
Details
.github/workflows/audit.ymlruns the dependency audit and the secret scan, and both communicate purely through exit codes and log output. Nothing is uploaded to the repository's code-scanning inventory, so a project has no view of its security posture over time - only a sequence of passing or failing builds.Emitting findings in the standard static-analysis interchange format and uploading them puts them in the repository's security tab with history, per-finding state, and the ability to dismiss a false positive with a recorded reason instead of a committed ignore entry.
Two constraints are worth designing for. The upload depends on a repository entitlement that not every consumer project will have, so a missing entitlement must not turn into a build failure or - worse - mask a real finding. And the build must still fail on findings independently of whether the upload succeeded, so the gate does not become dependent on the reporting.
This is GitHub Actions only. CircleCI has no equivalent destination, so the two providers will be deliberately asymmetric here.
Acceptance criteria