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

Add govulncheck action #71

Merged
merged 3 commits into from Sep 14, 2022
Merged

Add govulncheck action #71

merged 3 commits into from Sep 14, 2022

Conversation

samcoe
Copy link
Contributor

@samcoe samcoe commented Sep 13, 2022

This PR adds an action for the new govulncheck tool to check for vulnerabilities in our dependencies.

@samcoe samcoe self-assigned this Sep 13, 2022
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL govulncheck! How does it compare to Dependabot security alerts, which we currently have enabled?

@samcoe
Copy link
Contributor Author

samcoe commented Sep 14, 2022

@mislav So there are two major difference from my understanding:

  1. govulncheck analyzes your codebase and only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions.
  2. It uses a different database of vulnerabilities to check against. I would guess that there is huge overlap between it and the dependabot one.

I mostly want to enable this side by side with dependabot to see if one catches vulnerabilities that the other does not. Long term I can see us deciding to use just one or the other.

@samcoe samcoe requested a review from mislav September 14, 2022 09:29
@@ -0,0 +1,28 @@
name: Vulnerability Check
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this has exactly the same triggers as the Code Scanning workflow, I would say that this could be folded in as a separate job under that workflow, rather than as a workflow of its own. At the end of the day, they both perform static analysis to find vulnerabilities

@@ -12,7 +10,7 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v3
with:
go-version: "1.18"
go-version: "1.19"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we still run our tests on 1.18 maybe it would make sense to continue running linter an govulncheck on 1.18 as well. Or do you think matching these versions doesn't matter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it makes much difference. I purposefully put the linter to 1.19 as there are new godoc features/rules in 1.19 that I wanted to start enforcing in this repo.

@samcoe samcoe enabled auto-merge (squash) September 14, 2022 17:42
@samcoe samcoe merged commit a7df5ee into trunk Sep 14, 2022
@samcoe samcoe deleted the govulncheck branch September 14, 2022 17:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants