6 ms·

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 s

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.

plasma 5y ago
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.
- greysteil 5y ago
  Feature requests always welcome! I'll pass it on to the Dependabot team.
  - plasma 5y ago
    Thank you
    - asciimike 5y ago
      Let me know if https://github.com/github/roadmap/issues/148 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 5y ago
        Yep, that looks good to me, thanks!
- jacobparker 5y ago
  For NuGet, consider using centralized package references: https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-package-versions 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 5y ago
    Thank you, looks like it’s still on preview but glad it’s being worked on.
zdw 5y ago
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 5y ago
  At a previous employer, we used Terraform to manage GitHub teams/repos/permissions. It worked ... okay. Might be worth a try for you?
  - newman314 5y ago
    Can you expand a bit more on how you achieved this? It sounds interesting.
    - onei 5y ago
      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/latest/docs https://registry.terraform.io/providers/integrations/github/...
Jenk 5y ago
> 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-private-packages/16621/31 https://github.community/t/github-token-cannot-access-privat...
- greysteil 5y ago
  I'll make sure the Actions PMs see this. I _think_ I heard from a colleague that there's progress here.
wolverine876 5y ago
> 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 5y ago
  The Mythical Man-Month is probably older than you.
  - burnished 5y ago
    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 5y ago
    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.
dmitriid 5y ago
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#issuecomment-640919061 https://github.com/dependabot/feedback/issues/954#issuecomme... and the original issue: https://github.com/dependabot/dependabot-core/issues/1973 https://github.com/dependabot/dependabot-core/issues/1973 And why it doesn't fly: https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-829787238 https://github.com/dependabot/dependabot-core/issues/1973#is...
newman314 5y ago
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 5y ago
  > 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 5y ago
    It's unclear if you are saying if that already works but yes that would be sufficient. =D
    - asciimike 5y ago
      It doesn't, and was meant as a question
      - newman314 5y ago
        In that case, yes, glob syntax would work well.
jacobevelyn 5y ago
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 5y 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!)

plasma 5y ago

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.

greysteil 5y ago
Feature requests always welcome! I'll pass it on to the Dependabot team.
- plasma 5y ago
  Thank you
  - asciimike 5y ago
    Let me know if https://github.com/github/roadmap/issues/148 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 5y ago
      Yep, that looks good to me, thanks!
jacobparker 5y ago
For NuGet, consider using centralized package references: https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-package-versions 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 5y ago
  Thank you, looks like it’s still on preview but glad it’s being worked on.

zdw 5y ago

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 5y ago
At a previous employer, we used Terraform to manage GitHub teams/repos/permissions. It worked ... okay. Might be worth a try for you?
- newman314 5y ago
  Can you expand a bit more on how you achieved this? It sounds interesting.
  - onei 5y ago
    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/latest/docs https://registry.terraform.io/providers/integrations/github/...

Jenk 5y ago

> 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-private-packages/16621/31 https://github.community/t/github-token-cannot-access-privat...

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

wolverine876 5y ago

> 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 5y ago
The Mythical Man-Month is probably older than you.
- burnished 5y ago
  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 5y ago
  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.

dmitriid 5y ago

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#issuecomment-640919061 https://github.com/dependabot/feedback/issues/954#issuecomme... and the original issue: https://github.com/dependabot/dependabot-core/issues/1973 https://github.com/dependabot/dependabot-core/issues/1973 And why it doesn't fly: https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-829787238 https://github.com/dependabot/dependabot-core/issues/1973#is...

newman314 5y ago

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 5y ago
> 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 5y ago
  It's unclear if you are saying if that already works but yes that would be sufficient. =D
  - asciimike 5y ago
    It doesn't, and was meant as a question
    - newman314 5y ago
      In that case, yes, glob syntax would work well.

jacobevelyn 5y ago

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