Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing supply chain security features to the Go community

github.blog

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Bringing supply chain security features to the Go community

#51

Post by jacobevelyn »

greysteil wrote: post #13
leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

Thanks for all the hard work, greysteil! Long-time Dependabot user here and a big fan (currently in the throes of updating many repos to GitHub-native Dependabot).

I've reported all this in the past, but since we're giving feedback in this thread, some big pain points for us are:

1. The lack of a way to view all Dependabot security alerts/security PRs (across repos) in one place. With Old Dependabot, we could do a GitHub Issues search like `is:open is:pr label:security org:` and see them all, and actually built quite a lot of automation around PRs with the `security` label. But New Dependabot has no way to configure security PRs to get the `security` label, so it's easy to miss vulnerabilities when you have two dozen repos, and our automation no longer works. :/

2. Dependabot reporting `No security update is needed as is no longer vulnerable` when in fact there are multiple versions of the dependency, including vulnerable ones, in our yarn.lock file. (Webpack has a lot of transitive dependencies!)

3. Dependabot can't update a vulnerable version of, say, rails, because rails requires the same version of activerecord, even though these are essentially the same project. (I get the sense this is being worked on as "grouped dependency updates"?)

P.S. Just wanted to clarify: feedback is love. I wouldn't be writing this if we didn't find Dependabot valuable (Old Dependabot was actually the reason we moved to GitHub years ago!).

Re: Bringing supply chain security features to the Go community

#52

Post by lmas »

doctor_eval wrote: post #14
playcache wrote: post #10

meh. well that disappointing, its basically dependabot / graph and advisories.

Well maybe it’s meh if you already had it, but as a Go shop this is the first time we’ve been able to access these features so now I’m in party mode!

Yeah same for me. Seen it being used for npm and friends and been wanting some for Go too, for a long time now! I love graphs and dependency monitoring!

Re: Bringing supply chain security features to the Go community

#53

Post by greysteil »

jacobevelyn wrote: post #51
greysteil wrote: post #13

Earlier quoted context omitted.

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

Thanks for all the hard work, greysteil! Long-time Dependabot user here and a big fan (currently in the throes of updating many repos to GitHub-native Dependabot). I've reported all this in the past, but since we're giving feedback in this thread, some big pain points for us are: 1. The lack of a way to view all Dependabot security alerts/security PRs (across repos) in one place. With Old Dependabot, we could do a Gi…

Thanks for the feedback Jacob, and for all the support over the years. I'm going to pass those three on to the Dependabot team, who are best placed to think through solutions.

(FWIW, I'm sure we can think of something to fix (1) which balances security and usability - it just needs some thinking. (2) sounds like a bug to me - I'm sure the team will want to look at that. And (3) is a tricky case where Dependabot's Ruby logic needs to be able to unlock a dependency's "parent" or peers in order to make security fix (e.g., rails in the case where the vulnerability is in activerecord). Entirely possible but hard!)

Re: Bringing supply chain security features to the Go community

#54

Post by dmitriid »

starefossen wrote: post #5
leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

The amount of pull requests from dependency updates can become more manageable if you enable GitHub’s Auto Merge feature[1] [1] https://docs.github.com/en/github/collaborating-with-pull-re...

You can't enable granular auto merges: I'm fine with auto merging minor/security update PRs from dependabot. Not anything else. You can't set up that.

Re: Bringing supply chain security features to the Go community

#55

Post by ikiris »

greysteil wrote: post #23
kardianos wrote: post #21

Are the github's authors aware of Go's modules Vulnerability db? https://golang.org/design/draft-vulndb

We are, and we're talking to them. In an ideal world we would have loved to have merged the databases. I expect the two databases will move in sync. The GitHub advisory database is licensed as CC BY 4.0 (i.e., attribution only), so we actively encourage others, including the Go Vulnerability Database, to pull from it.

https://xkcd.com/927/

Can you.... not?

Re: Bringing supply chain security features to the Go community

#56

Post by d4mi3n »

onei wrote: post #48
newman314 wrote: post #41

Earlier quoted context omitted.

Can you expand a bit more on how you achieved this? It sounds interesting.

There's a GitHub provider for Terraform [1]. I tried it out on a GitHub Enterprise instance last year and found it a little awkward because they didn't have support for the latest GH APIs and the version before was missing a bunch of features. When I looked recently, they seemed to have got past that. The principle is broadly the same as other Terraform workflows: import existing config and update it when you need to…

We did something similar to this at an org I worked at. We'd pull users from specific groups from our identity provider (Okta) and use that to provision corporate accounts to a Github Enterprise instance.

One big downside to this approach is Github teams often don't line up 1-to-1 with an organization's reporting structure, so you don't really ever get away from needing to manually manage user-team memberships, but it does remove the need to onboard/offboard users manually.

Re: Bringing supply chain security features to the Go community

#57

Post by hakre »

leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

it was easy: block the user.

then it got harder: create one branch that blocked the dependabot branch.

then it got harder again: create 00 00 00 - FF FF FF branches (let it run with parallelism and over night).

github support is not helpful on this.

Re: Bringing supply chain security features to the Go community

#58

Post by dane-pgp »

gherkinnn wrote: post #4
leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

Here's some information on these "vulnerabilities": https://overreacted.io/npm-audit-broken-by-design/ As far as I'm concerned, there's no need for Dependabot to create PRs. The notifications in the security tab are enough. Mark the unnecessary ones as benign.

And here's the HN discussion on that thought-provoking post:

https://news.ycombinator.com/item?id=27761334

Re: Bringing supply chain security features to the Go community

#59

Post by H12 »

zdw wrote: post #18
greysteil wrote: post #13

Earlier quoted context omitted.

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

It would be wonderful if there were bulk editing of Dependabot settings across multiple repos. The weakest part of GitHub is the lack of bulk administrative edits (repo settings, not code changes) across multiple repos. This affects group (team) permissions as well - having to add a new team to multiple repos with specific permissions is a manual slog and hard to audit. Even the expanded permission categories are fre…

I'd love it if there was more org-level functionality in general, for both content and configuration.
Post reply on HN