osv-scanner
osv-scanner copied to clipboard
Build GitHub actions for running osv-scanner
For running osv-scanner
@oliverchang Now since osv-scanner is out, I was thinking of building a github action and found this issue. Adding a proposal for building Github action here for your feedback
- Build an docker container based Github action
osv-scanner-action
- For PR scanning use-cases, scan only Git commit SHA
- For full scanning use-cases, scan directory
- Use Github Checks API to annotate the lockfile with OSV results
Some plumbing code need to be written to integrate with Github PR scanning workflow.
Update: Mistook Git commit scan as checking for changes in the PR in target repo. Probably need to refactor a bit to scan lockfile changes only in the PR. This will be useful in incremental scans.
(Moving issue to the right repo)
Thanks for proposing this @abhisek! We're still trying to figure out all the necessary requirements for this action (and don't want to rush it), as we want this to go beyond the scope of just scanning (but also include tracking/remediation).
We're happy to accept contributions to make the necessary plumbing/PR changes for these pieces!
One of the key refactoring change that I would propose is to introduce the following inside PackageDetails
and have the parser retain this information.
type PackageDetailSource struct {
sourceFile, sourceLine string
}
It may not be trivial for XML / JSON files where an external format parser is used :(
Subsequently correlate the vulnerabilityResults
with input packages so that the final result can include a source file and line for each vulnerability. This will allow better consumption of results by annotating source lines in PR using Github (or equivalent) Checks API
@abhisek that sounds like a pretty huge complexity jump since you'd have to implement custom parsers for at least JSON, YAML, TOML, and XML.
I'd recommend checking out check-with-osv-detector
as prior art - its a straightforward composite action that pulls the binary from GH releases which is more lightweight than using a docker-based action; now that osv-scanner
is releasing binaries it should be pretty easy to create an action from that.
Hey, is this still the case? Has anybody implemented the gh-action yet?
We have an action in Kuma that does that - https://github.com/kumahq/kuma/blob/master/.github/workflows/update-insecure-dependencies.yaml#L42
Thanks @slonka! We're also looking at building officially workflows to run osv-scanner as part of GH Actions soon. @another-rex is the one owning this :)
Having existing examples of real users is super helpful!