Live data from Hacker News

Bringing supply chain security features to the Go community

github.blog

31–40 of 72 posts

Re: Bringing supply chain security features to the Go community

#31
post #11

Earlier quoted context omitted.

The "biggest" problem in the JavaScript ecosystem (NPM) is that dependadabot doesn't know how to discriminate between dependancies and devDepandancies. I don't really care if jest includes a package that has a regex issue. It's not production code. I do care if babel introduces a backdoor, but somehow they're treated with equal importance.

It depends, attacks via build pipelines can be devastating.

Yep.

Unfortunately it’s not clear cut that we don’t have to worry about devDependencies vulnerabilities.

Re: Bringing supply chain security features to the Go community

#32
post #19

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"?

I also get a lot of spam from dependabot because of prereleases, I wish they would fix this bug: https://github.com/dependabot/dependabot-core/issues/2547 As others have pointed out, you can opt for daily / weekly or monthly updates, I'll stick to monthly until they fix this bug.

Hmmm, it's been a long time since I worked on Dependabot Core, but I think I can fix that one - we just need to special case `native-mt` as a version type (as opposed to applying standard Maven version comparison rules on it). I'll try and get a PR in today and will tag you.

Update: https://github.com/dependabot/dependabot-core/pull/4077

Re: Bringing supply chain security features to the Go community

#33

Earlier quoted context omitted.

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.

The PRs are really helpful when you do actually want to update.

You can have Dependabot create a PR by hitting a button somewhere in the vulnerability details.

Re: Bringing supply chain security features to the Go community

#34

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

I was also wondering about this — I feel like it was just a couple of weeks ago that I read about the Go team's new unified vulnerability schema/Open Source Vulnerabilities (OSV) database

Definitely a step in the right direction on both ends, though!

https://osv.dev/list

https://security.googleblog.com/2021/06/announcing-unified-v...

https://opensource.googleblog.com/2021/02/launching-osv-bett...

Re: Bringing supply chain security features to the Go community

#35
post #15

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…

HN is great, can I chime in with some feedback too, for NuGet I’m seeing Dependabot open separate PRs for the same dependency that’s out of date in the one repo that has multiple projects that relate to each other (they reference one another in csproj files). They thus also need to be updated together, but I wish one PR was opened to update the dependencies in all projects at once, instead of multiple PRs I to merge.…

For NuGet, consider using centralized package references: https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-...

You get one file defining the set of all packages used in your repo (or some subset of your repo, etc.) and Dependabot will update this file directly. Individual projects can choose to use a package but won't specify the version.

It requires that your projects are all in sync with package versions but (1) that sounds like what you want (2) it's usually the best thing.

Re: Bringing supply chain security features to the Go community

#36
post #18

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…

This is why we use GitLab over GitHub.

Re: Bringing supply chain security features to the Go community

#37

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…

> The team is still relatively small (it's 7 people), and supporting a service like this at GitHub scale is hard, but we're keen to keep improving.

While I empathize with your team regarding their apparent workload, that's only because they (probably) don't control hiring. GitHub isn't a struggling startup; it's not a non-profit; it's a mature, sizeable organization whose owner has over a trillion dollars in assets. If the team is too small to do a job, it's not because you lack personnel, it's GitHub's choice not to do it. You're GitHub, owned by Microsoft; GitHub doesn't care about these issues enough to staff them.

EDIT: Removed something provocative.

Re: Bringing supply chain security features to the Go community

#38

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"?

I usually ignore those and bundle a bunch in a single PR.

The worst I found was another team which merges in depandabot PR's one by one. Their git history isn't pleasant to look through :(

Re: Bringing supply chain security features to the Go community

#39

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"?

Yup, my PR review requested page is near useless because of all of the dependabot PRs.

Re: Bringing supply chain security features to the Go community

#40

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…

> The team is still relatively small (it's 7 people), and supporting a service like this at GitHub scale is hard, but we're keen to keep improving. While I empathize with your team regarding their apparent workload, that's only because they (probably) don't control hiring. GitHub isn't a struggling startup; it's not a non-profit; it's a mature, sizeable organization whose owner has over a trillion dollars in assets.…

The Mythical Man-Month is probably older than you.
Post reply on HN