I can’t really put my finger on what about dependabot makes me avoid it (and feel a little cranky), but I feel validated. If I got into the habit of satisfying the bot, I can also imagine falling for this.
For me it’s the incessant blind version-bumping of indirect dependencies. I do not (and will not consider trying to) understand the internals of all my dependencies, so I cannot understand whether it is safe to bump a package they depend on. Also after reviewing hundreds of dependabot PRs I have never seen a fix for an issue we were actually vulnerable to. So I consider it useless noise [0].
I dismiss all dependabot PRs that don’t apply to my direct dependencies, without even looking at them. I have decided to trust those dependencies to do the right thing. This is obviously very imperfect, but in this way I get actual work done, and I sleep just fine at night.
[0] I understand that this is partly a fault with CVEs and other functionings of the security ecosystem.
I try to keep my test suites comprehensive enough that, if the tests pass, I can safely apply the Dependabot bump.
I also try to stick to dependencies with development processes that I trust, which reduces the risk of something bad slipping in. This is a lot easier in Python (where most of my projects have a dozen or so dependencies) compared to JavaScript (where everything seems to quickly end up with 100+ dependencies even for a basic project).
Isn’t this 100% GitHub’s fault? They’re allowing malicious actors to impersonate them on their own platform. Shouldn’t this expose GitHub to litigation?
The attack began with the attackers somehow obtaining their targets’ personal GitHub access tokens, which Checkmarx has no insight into.
So, first the attackers somehow get the credentials from the user via some out of band mechanism. At this point, they are already able to do pretty much anything that the user can do. Possibly they have a limited-access token, but they can at least post PRs impersonating the repo owner. At that point, the PR appears to come from a bot that you’ve given trust to and so you trust it.
The real question is how did they get the PATs. If that’s a GitHub vulnerability, that’s bad. If that’s users leaking their credentials then users need to not do that, just as they also need to not leak their SSH private keys.
This is honestly a genius way to do it. I’d totally fall for this.
I can’t really put my finger on what about dependabot makes me avoid it (and feel a little cranky), but I feel validated. If I got into the habit of satisfying the bot, I can also imagine falling for this.
For me it’s the incessant blind version-bumping of indirect dependencies. I do not (and will not consider trying to) understand the internals of all my dependencies, so I cannot understand whether it is safe to bump a package they depend on. Also after reviewing hundreds of dependabot PRs I have never seen a fix for an issue we were actually vulnerable to. So I consider it useless noise [0].
I dismiss all dependabot PRs that don’t apply to my direct dependencies, without even looking at them. I have decided to trust those dependencies to do the right thing. This is obviously very imperfect, but in this way I get actual work done, and I sleep just fine at night.
[0] I understand that this is partly a fault with CVEs and other functionings of the security ecosystem.
I try to keep my test suites comprehensive enough that, if the tests pass, I can safely apply the Dependabot bump.
I also try to stick to dependencies with development processes that I trust, which reduces the risk of something bad slipping in. This is a lot easier in Python (where most of my projects have a dozen or so dependencies) compared to JavaScript (where everything seems to quickly end up with 100+ dependencies even for a basic project).
Same here. No way I am going to let my commits be dictated by a bot.
The whole idea of grabbing a bunch of rapidly changing dependencies and expect everything to work, it’s a very broken one.
I can’t link to it because I have since made my account private, but on April 19, 2021, I tweeted:
Isn’t this 100% GitHub’s fault? They’re allowing malicious actors to impersonate them on their own platform. Shouldn’t this expose GitHub to litigation?
The key bit in the article is this:
So, first the attackers somehow get the credentials from the user via some out of band mechanism. At this point, they are already able to do pretty much anything that the user can do. Possibly they have a limited-access token, but they can at least post PRs impersonating the repo owner. At that point, the PR appears to come from a bot that you’ve given trust to and so you trust it.
The real question is how did they get the PATs. If that’s a GitHub vulnerability, that’s bad. If that’s users leaking their credentials then users need to not do that, just as they also need to not leak their SSH private keys.
Expose… Microsoft… to litigation? BAHAHAHAHA
Interesting that GitHub doesn’t require / verify the signature from their online key on a commit with dependabot’s identity as the committer.
This is an old bug, Github doesn’t seem interested in fixing it.
[Comment removed by author]