[greysteil]

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.

[zdw]

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.

[veverkap]

At a previous employer, we used Terraform to manage GitHub teams/repos/permissions.

It worked ... okay. Might be worth a try for you?

[newman314]

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

[onei]

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.

[1] https://registry.terraform.io/providers/integrations/github/...

[d4mi3n]

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.

[xorcist]

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.

[mikewhy]

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

[1]: https://docs.github.com/en/developers/webhooks-and-events/we...

[H12]

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

[xevrem]

This is why we use GitLab over GitHub.

[Jenk]

> 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...

[greysteil]

I'll make sure the Actions PMs see this. I _think_ I heard from a colleague that there's progress here.

[jacobevelyn]

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!).

[greysteil]

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!)

[wolverine876]

> 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.

[samatman]

The Mythical Man-Month is probably older than you.

[burnished]

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.

[wolverine876]

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.

[plasma]

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.

[jacobparker]

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.

[plasma]

Thank you, looks like it’s still on preview but glad it’s being worked on.

[greysteil]

Feature requests always welcome! I'll pass it on to the Dependabot team.

[plasma]

Thank you

[asciimike]

Let me know if https://github.com/github/roadmap/issues/148 is in the right spirit of what you're aiming for.

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.

[plasma]

Yep, that looks good to me, thanks!

[newman314]

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).

[asciimike]

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

[newman314]

It's unclear if you are saying if that already works but yes that would be sufficient. =D

[asciimike]

It doesn't, and was meant as a question

[newman314]

In that case, yes, glob syntax would work well.

[dmitriid]

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.

[1] https://github.com/dependabot/feedback/issues/954#issuecomme... and the original issue: https://github.com/dependabot/dependabot-core/issues/1973

And why it doesn't fly: https://github.com/dependabot/dependabot-core/issues/1973#is...