Are the github's authors aware of Go's modules Vulnerability db?
Bringing supply chain security features to the Go community
21–30 of 72 posts
Re: Bringing supply chain security features to the Go community
#22meh. well that disappointing, its basically dependabot / graph and advisories.
Well, yeah, the title says they are "bringing supply chain security features to Go" - so Go gets the same features other languages already have, no new exciting stuff to be expected here...
Re: Bringing supply chain security features to the Go community
#23Are 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.
Re: Bringing supply chain security features to the Go community
#24GitHub'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…
> PM for security products
Please, please, _please_, add organisation scope to github action tokens (GITHUB_TOKEN in actions). It is painful that we have to create a PAT to access packages from within an organisation.
https://github.community/t/github-token-cannot-access-privat...
Re: Bringing supply chain security features to the Go community
#25GitHub'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 "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.
Re: Bringing supply chain security features to the Go community
#26Earlier 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…
At a previous employer, we used Terraform to manage GitHub teams/repos/permissions.
It worked ... okay. Might be worth a try for you?
Re: Bringing supply chain security features to the Go community
#27GitHub'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 "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.
PM for security products at GitHub here.
Totally agree. The good news is that I think GitHub is in a position to fix this - expect progress in the next 12 months.
One change that's needed here is data for each vulnerability on whether it's ever relevant in development. The advisory database that powers GitHub's security alerts (and npm audit, and NuGet audit) now has a dedicated curation team and is ready to curate more ecosystems and more information.
That data then needs to be hooked up with GitHub's security alerting logic. That shouldn't be too difficult - we already detect whether a dependency is used in development or production, and the team here is growing.
Finally, for this to work we'd need a new UI concept for vulnerabilities you aren't affected by. We're already working on functionality with a very similar requirement (one that tells you whether you're using the vulnerable function within a dependency).
I can't make promises, but I can say that GitHub has an increasing amount of energy. Expect progress :-)
Re: Bringing supply chain security features to the Go community
#28Earlier 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…
> PM for security products Please, please, _please_, add organisation scope to github action tokens (GITHUB_TOKEN in actions). It is painful that we have to create a PAT to access packages from within an organisation. https://github.community/t/github-token-cannot-access-privat...
I'll make sure the Actions PMs see this. I _think_ I heard from a colleague that there's progress here.
Re: Bringing supply chain security features to the Go community
#29I got few notifications yesterday for our golang projects. I was pleased to see less noisy alerts as compared to React based UI we have. It is terrible to say the least for npm projects.
Would love to know if dependabot creates noisy alerts for other languages too.
Re: Bringing supply chain security features to the Go community
#30GitHub'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"?
This seems like good motivation to prune your dependencies if they’re getting out of hand. Of course, easier said than done, but at an ecosystem level maybe it will help?
In the case of NPM, the only way to not have your dependencies be “out of hand”, is to not use NPM.
/s (but also, for realsies)