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 right for you.)
Dependabot doesn't support grouped updates yet but we hear the feedback and the team wants to work on them. Most of the investment in Dependabot recently gone towards improving our infrastructure and improving the experience for security updates. 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.
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 frequently inadequate - there's no CI focused "Let these users write to the repo and change hooks" permission level - all CI systems that self-manage hooks need full Admin rights.
The other code hosting I actively use is Gerrit, and the ability to hierarchically control what groups have specific permissions on multiple repos is far simpler and easier to use, from an admin perspective.
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. You can manage repo permissions, people and teams, all centrally and in code. Super useful for tracking changes (the GH audit logs are a bit lacking in my experience) and identifying discrepancies between the expected and actual configurations.
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.
Puppet and Ansible are great for this type of things. If you want a new repo for your group, you make a pull request for our management repo.
There are a bunch of access rights, hooks and tokens that need to be set up in a certain way depending on the type of repo, and Ansible regularly makes sure no one deviates from the intended configuration.
Github (or Bitbucket or Gitlab) isn't different from any other software in this regard.
Does GitHub have "system level" webhooks like gitlab? That's what I've done previously, so when anyone creates a repo, it's configured as the org expects.
This page[1] seems to mention organization level hooks that receive repository created events, if making your team edit a terraform/puppet/ansible/chef repo to simply create a repo seems overkill to you
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.
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:<our-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 <dependency> 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!).
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!)
> 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.
That book is an incredible read for anyone, even just the first couple chapters, but the central thesis is "you probably cannot pay any amount of money to make an over-due software development (or many other kinds of development) project be an on-time project", and not "there is no point in growing a team to solve bigger problems faster". You can't hire another orchestra to help play the same song faster, but you can hire another orchestra for more music over a longer time.
Yes, I thought of that, and it's a relevant point IMHO. But while hiring 10,000 people off the street won't improve things, GitHub hardly has its hands tied; they know how to get things done if they want to. We're talking about adding some basic features. Somewhere in GitHub and Microsoft, there probably are some additional highly productive developers who could be assigned to the project.
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.
PS: I think you should highlight dependabot updates on the Security tab in GitHub repo, I thought it was on before (but was actually just the security notices) because dependabot itself is hidden away in Insights -> Dependency graph -> Dependabot which was a bit surprising.
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.
I think that what will get implemented will be a bit broader (covering version updates and security updates) and will allow for grouping by manifest, language, vulnerability, and potentially arbitrary labeling in the config file.
While we are on the feedback train, please consider making the Docker dependabot action more intelligent.
Right now, I have a monorepo with multiple Dockerfiles in subdirectories.
I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies.
Also, multi-stage Dockerfile configs seem to confuse Dependabot where it'll submit a pull request to update the "AS build" but not the image to be used for packaging...
I really like the promise/premise of Dependabot, just want it to be easier to use (and edit across multiple repos).
> I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies.
Glob syntax in `directory` would be sufficient, yes?
A must: allow Dependabot to merge PRs automatically. The reason to refuse this is frankly ridiculous [1]. For JS projects Dependabot is little less than a spammer, and the ability to automatically merge minor/patch versions is a must. Having to rely on third-party actions to do this is probably a larger security risk than letting people decide what PRs they want to automerge.
Part of that is the Node / JS ecosystem that churns out libraries for every tiny thing. The Go ecosystem is a lot more streamlined; adding dependencies is frowned upon, building small libraries is frowned upon, etc.
That said, if it's just version bumps then they should be bundled. But what about security issues? Those need to be fixed and updated asap.
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 "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.
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 :-)
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?
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.
The git log command has a --perl-regexp flag [0], which allows you to filter commits that match a Perl-style regular expression. I guess in that situation you could specify a regular expression that excludes dependabot in --author.
If typing --perl-regexp gets old, you can always alias it or add a repo/global config option via grep.patternType [1]. Or you can create an alias for adding the less-powerful --invert-grep [2].
Exactly what you want to have: get a bot merge fixes for security issues prepared by another bot without any human oversight. Then let Copilot add features to your software automatically as well.
You could probably use a GitHub Action and check the API for author of the pull request if you want to require additional verification. If have done something similar with auto accepting docs-only pull requests in the past.
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.
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!
I 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.
Had the same issue for Diem a while ago (I don’t work there anymore) and we ended up looking into software to manage dependencies in Rust. Check out https://github.com/diem/whackadep
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!
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...
Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?