We use Dependabot to secure GitHub
github.blog
github.blog
The other problem that I have is there is no easy way (probably for good reason due to potential abuse) to manually trigger Dependabot. So Dependabot might run once a day or not do so for quite a while.
I have found a workaround for this since it appears that Dependabot does reliably trigger when .github/dependabot.yml is updated. One quick hack to insert a commented timestamp later... I now have a way to make sure Dependabot runs when I do want it to.
https://github.com/dependabot/dependabot-core/issues/390 upvote and/or implement it as a fork and run it in an Action.
> The other problem that I have is there is no easy way (probably for good reason due to potential abuse) to manually trigger Dependabot. So Dependabot might run once a day or not do so for quite a while.
There is, it's just hidden in https://github.com/:org/:repo/network/updates > click "last updated ..." and then click "Check for Updates" and it'll start a manual run.
As a side note, automerge is... complicated. I've always felt that having it means that people will be mad when it does something bad (e.g. automerges the inevetible npm credential theft update), and they'll be mad if it doesn't exist because they're so sick of the unending stream of PRs, so you're kind of damned either way. At this point, I fall on the side of "let people do the unsafe thing so they shut up about not being able to do so" but that's not the side the security team generally falls on.
Disclosure: one time PM on Dependabot
> The other problem that I have is there is no easy way (probably for good reason due to potential abuse) to manually trigger Dependabot.
One of the announcements at BUILD this week was that Dependabot was getting added to a list of "Push protection" tools in GitHub Advanced Security so that it would run at least every push (and also optionally block pushes that don't address Dependabot concerns). Though it will be paywalled behind GitHub Advanced Security.
It’s so easy to end up depending on a behaviour which is a bug.
The short answer is that the Dependabot team can't support all the ecosystems people want without hiring a dozen engineers who have expertise in those ecosystems. The best choice IMO is to move to a model where the community (and ideally the package manager maintainers) can implement their own updaters (ideally using the package manager directly, so support for yarn whatever can just be "update the yarn Dependabot updater to use the newest version of the yarn updater" without the Dependabot team having to care). GitHub even has a platform for running untrusted code, so...
Disclosure: was once my problem, no longer :)
Reading between the lines from comments in that thread, it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic to do in-place lockfile updates behind the scenes. I'm sure it is nice to avoid checking out the whole repo, but it would also multiply the maintenance workload exponentially.
https://github.com/thepwagner/action-update being an example of this (and showing go, docker)
> it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic
The entire maintenance burden of dependabot is "reimplement logic that package managers already do to determine the update strategy." Using package managers functionality for this would indeed make this a lot easier, though even then package manager support for specific things might not be universal.
That said, it's possibly easier to go to the package manager and say "we'd like to implement/for you to implement feature X that will enable Dependabot as well as the underlying functionality Dependabot was missing, that your users probably already want" than the opposite problem of people asking Dependabot to write a bunch of ruby to re-implement something that already exists.
FWIW, I don't think security updates are turned on by default anymore, so new repos won't have this problem.
That's the problem it tried to update dependencies without touching nix which would messed up the build. It assumed it knew how to update it, but did it wrong.
For example, the Globus @ Stanford web site (https://globus.stanford.edu) uses GitHub Pages (repo at https://github.com/stanford-rc/globus.stanford.edu). I have a Gemfile in the repo: When I want to test changes locally, I use Bundler to install everything I need, and to launch Jekyll. Even though the Gemfile isn't used 'in production', Dependabot still warns me, so that I don't run older, vulnerable software on my laptop.
At the same time, I can't be sure if Dependabot is picking up dependencies for my Python project.
In my latest project (https://github.com/stanford-rc/globus-group-manager), I'm using pyproject.toml to hold all of the Python dependencies for the project, something that Setuptools is now supporting experimentally (woot!). I've configured Dependabot, and it has picked up my repo's `pyproject.toml` file, but I can't tell if it has actually cataloged my Python dependencies.
Looking around the web also does not give me a clear answer. For example, https://github.com/dependabot/feedback/issues/57 is titled "pyproject.toml support", but it refers specifically to Poetry (and indeed, Poetry v1 is listed as supported at https://docs.github.com/en/code-security/dependabot/dependab...). But Setuptools is not.
https://github.community/t//2576 asks about Setuptools support, and has been pretty dormant. I thought setup.cfg was supported after https://github.com/dependabot/dependabot-core/pull/3423, but another project of mine (https://github.com/stanford-rc/mais-apis-python/network/depe...) doesn't show anything for setup.cfg.
To be clear, I am very glad that Dependabot exists! I'm also glad to see it being used heavily inside GitHub. I hope this helps Dependabot expand to include more coverage for new and existing ecosystems.