Skip to content
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

Build GitHub actions for running osv-scanner #57

Closed
oliverchang opened this issue Sep 1, 2022 · 7 comments · Fixed by #432
Closed

Build GitHub actions for running osv-scanner #57

oliverchang opened this issue Sep 1, 2022 · 7 comments · Fixed by #432
Assignees
Labels
enhancement New feature or request

Comments

@oliverchang
Copy link
Collaborator

For running osv-scanner

@oliverchang oliverchang added the enhancement New feature or request label Sep 1, 2022
@andrewpollock andrewpollock changed the title Build GitHub actions Build GitHub actions for running osv-scanner Oct 18, 2022
@abhisek
Copy link
Contributor

abhisek commented Dec 14, 2022

@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.

@oliverchang oliverchang transferred this issue from google/osv.dev Dec 15, 2022
@oliverchang
Copy link
Collaborator Author

(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!

@abhisek
Copy link
Contributor

abhisek commented Dec 15, 2022

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

@G-Rath
Copy link
Collaborator

G-Rath commented Dec 15, 2022

@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.

@Dentrax
Copy link

Dentrax commented Feb 17, 2023

Hey, is this still the case? Has anybody implemented the gh-action yet?

@slonka
Copy link

slonka commented Jun 20, 2023

@oliverchang
Copy link
Collaborator Author

oliverchang commented Jun 20, 2023

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!

another-rex added a commit that referenced this issue Jul 31, 2023
This PR features:

- Refactors the format flag's internal logic so that we can don't need
to repeat the format types so much, and we can test when we add a new
format entry if we forgot anything.
- Adds a new format "sarif", which returns a SARIF report (closes #216 )
- Adds a Github Action `action.yaml` and it's specialized dockerfile
`action.dockerfile`. This docker image runs a bash script wrapping
osv-scanner, first by preprocessing the input so the last argument will
be split by new line, allowing the workflow user to pass in multiple
directories/files they wish to scan. The script also changes exit codes
127 and 128 to 0 as they contain errors that the user can't really do
anything about.
- Adds two reusable workflows using this new github action for this repo
- Reusable PR workflow, for using to check if PRs introduce new
vulnerabilities.
- Reusable Scheduled workflow, for use to regularly check for new vulns
applying to your existing vulns.
- Adds an experimental flag: `--experimental-diff`, which will only
output the difference between a previous run and this run of the
osv-scanner. This is for use in the PR workflow.
- Sorts the grouped ID output.

Closes #57 

Currently the reusable workflow has to point to a specific action which
cannot be relative (otherwise it would point to the wrong action when
reused in another repo). This means right now it's pointed to this
fork/branch instead of the master branch, this will need to be updated
once this PR is merged.

Example of what workflow sarif output looks like:

![image](https://github.com/google/osv-scanner/assets/106129829/fc7a0ac4-f3d8-4524-93ba-7b03dd0313cd)

Here is an example of the PR reusable workflow working:

another-rex/scorecard-check-osv-e2e#1

That PR adds an additional vulnerability, which causes it to fail. You
can see that only the new vuln is showing up in the code scanning
report:
https://github.com/another-rex/scorecard-check-osv-e2e/security/code-scanning/1


TODO after this PR is merged:
- Change links that point to this PR branch to point to main (and/or a
tagged commit of main)
- Add support for annotations
- Add documentation (this is for later, as we want to dogfood it in our
own repos first before broadcasting this widely)

---------

Signed-off-by: Rex P <rexpan@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants