4 ms·

I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there

I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there is. And yet... stuff like grouping has only been recently added. Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen https://github.com/github/evergreen

8organicbits 3y ago
I've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation. A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again. [1] https://github.com/ralexander-phi/license_approval https://github.com/ralexander-phi/license_approval
- dimitrios1 3y ago
  It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.
  - bluGill 3y ago
    These are proplems github customers have.
  - cqqxo4zV46cp 3y ago
    “Uncover” meaning “believe the same stuff that I believe, based on 20 year old tech history that everyone knows already”. There’s no secret here.
  - viraptor 3y ago
    Would you like to spell them out? It's not exactly clear if you're thinking of the same ideas as other people, a conspiracy to take over the world, or something in between.
- jacques_chester 3y ago
  GitHub has the advantage of a low barrier to entry for their tools. A lot of their features are inferior to special-purpose tools, but they can expect high usage because a lot of users shrug and live with it.
playingalong 3y ago
Why? Just like with AWS SaaS offerings: All they need to do is have something basic, satisfying 80% customers, requiring little maintenance on their end.
chuckadams 3y ago
I just want to be able to browse the dependencies of my repo with a web UI. Show me a tree of dependencies in my repo, filter for ones that are outdated, expand them to show what would be in a dependabot PR (the keen description it generates that contains all the release info and links to changelogs and whatnot). Then let me open a PR (or tell dependabot to do so) with the click of a button, or ignore it with another. The current workflow where dependabot just spams an endless stream of PRs is not optimal. I don't need any new features from dependabot, I just want a better UI.
Tainnor 3y ago
Last time I tried (which is >2y ago, so things might have improved), dependabot seemed like an afterthought for GitHub. For example, at some point GitHub introduced a change that prevented CI builds triggered by forks from accessing secrets in CI variables. This made sense from a security perspective (although I would have a preferred a hard failure instead of variables silently being set to empty), but it also applied to all Dependabot PRs, which I have to assume wasn't intended behaviour. It really seemed like different teams at GitHub weren't talking to each other. An issue was opened about this and got quite heated, but wasn't really resolved (except for some ugly workarounds) before it was locked for becoming too uncivil. I wonder if they fixed it since.
- asciimike 3y ago
  Oh yes, https://github.com/dependabot/dependabot-core/issues/3253 https://github.com/dependabot/dependabot-core/issues/3253. I wouldn't go so far as saying it was locked because it was too uncivil, mostly just because "additional commentary wasn't adding value" ;) Your read on the situation is spot on, and no, it doesn't look like it's been "fixed" (mostly because "fixing it would re-introduce the same potential vulnerability).
  - Tainnor 3y ago
    I think it would be possible to fix it properly and without security risk by allowing pipeline authors to allowlist dependabot and/or specific forks for accessing secrets.

8organicbits 3y ago

I've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation. A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again. [1] https://github.com/ralexander-phi/license_approval https://github.com/ralexander-phi/license_approval

dimitrios1 3y ago
It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.
- bluGill 3y ago
  These are proplems github customers have.
- cqqxo4zV46cp 3y ago
  “Uncover” meaning “believe the same stuff that I believe, based on 20 year old tech history that everyone knows already”. There’s no secret here.
- viraptor 3y ago
  Would you like to spell them out? It's not exactly clear if you're thinking of the same ideas as other people, a conspiracy to take over the world, or something in between.
jacques_chester 3y ago
GitHub has the advantage of a low barrier to entry for their tools. A lot of their features are inferior to special-purpose tools, but they can expect high usage because a lot of users shrug and live with it.

playingalong 3y ago

Why? Just like with AWS SaaS offerings: All they need to do is have something basic, satisfying 80% customers, requiring little maintenance on their end.

chuckadams 3y ago

I just want to be able to browse the dependencies of my repo with a web UI. Show me a tree of dependencies in my repo, filter for ones that are outdated, expand them to show what would be in a dependabot PR (the keen description it generates that contains all the release info and links to changelogs and whatnot). Then let me open a PR (or tell dependabot to do so) with the click of a button, or ignore it with another. The current workflow where dependabot just spams an endless stream of PRs is not optimal. I don't need any new features from dependabot, I just want a better UI.

Tainnor 3y ago

Last time I tried (which is >2y ago, so things might have improved), dependabot seemed like an afterthought for GitHub. For example, at some point GitHub introduced a change that prevented CI builds triggered by forks from accessing secrets in CI variables. This made sense from a security perspective (although I would have a preferred a hard failure instead of variables silently being set to empty), but it also applied to all Dependabot PRs, which I have to assume wasn't intended behaviour. It really seemed like different teams at GitHub weren't talking to each other. An issue was opened about this and got quite heated, but wasn't really resolved (except for some ugly workarounds) before it was locked for becoming too uncivil. I wonder if they fixed it since.

asciimike 3y ago
Oh yes, https://github.com/dependabot/dependabot-core/issues/3253 https://github.com/dependabot/dependabot-core/issues/3253. I wouldn't go so far as saying it was locked because it was too uncivil, mostly just because "additional commentary wasn't adding value" ;) Your read on the situation is spot on, and no, it doesn't look like it's been "fixed" (mostly because "fixing it would re-introduce the same potential vulnerability).
- Tainnor 3y ago
  I think it would be possible to fix it properly and without security risk by allowing pipeline authors to allowlist dependabot and/or specific forks for accessing secrets.