5 ms·

I don't think I have ever accepted a pull request from Dependabot. I think that was already a stupid thing to do. Now it's even more obvious that you shouldn'

I don't think I have ever accepted a pull request from Dependabot. I think that was already a stupid thing to do. Now it's even more obvious that you shouldn't accept a PR. Dependabot is a useful tool to find vulnerable dependencies, so that you can update them yourself.

JohnFen 3y ago
Are people accepting pull requests without actually reviewing the code being contributed?? That seems like the larger problem...
- sdflhasjd 3y ago
  There are projects that automatically merge dependabot PRs...
  - mistrial9 3y ago
    projects with underpaid and outsourced contractors by any chance?
    - MiguelX413 3y ago
      More likely, simply open-source projects.
  - earthling8118 3y ago
    Funnily enough I'd assume that those projects would be immune to this type of attack unless the automation is absolutely terrible.
  - oalders 3y ago
    Presumably an automated merge would be checking something like > if: github.event.pull_request.user.login == 'dependabot[bot]'
    - turboponyy 3y ago
      No, the automated workflow would be something like this: - Run dependabot workflow (outputs: $pr_number) - Automerge $pr_number
- Karellen 3y ago
  If dependabot is part of GitHub's own infrastructure, and the last 100 pull requests it sent were good, some maintainers might think it trustworthy. I'm pretty sure there are maintainers of Linux that Linus has been working with for long enough that he trusts them to the point that doesn't feel the need to examine every one of their commits. Also, he can't check every commit closely. Linux 6.5 merged 13,561 commits over 9 weeks[0], which is in excess of 200 commits per day - and that was a small release. Learning to trust regular contributors is one of the things that makes OSS work as scale. Edit: Of course, Linus makes sure that stuff he merges from trusted contributors is actually from them, either because it's from a repo he knows they control, or it's GPG-signed and the signatures are checked. The problem is failing to confirm that commits come from the trusted source you think they're from, not failing to examine the commits themselves. [0] https://lwn.net/Articles/941675/ https://lwn.net/Articles/941675/
  - EGreg 3y ago
    There should be an actual green checkmark for Dependabot and others
    - funcDropShadow 3y ago
      Dependabot should sign it's PRs with a gpg signature. And web interface could get support to check those signatures. That is way more trustworthy than a random green flag in some web ui that changes all the time.
- deathanatos 3y ago
  It seems like these are being pushed directly, using stolen credentials. (I.e., attackers are just leaking more credentials & compromising the repo. They're just hiding behind dependabot's good name by spoofing it.)
prepend 3y ago
I’ve accepted a bunch of dependabot PRs but I always review the change they make. Sometimes I modify or reject depending on the change. All the ones I remember are just version bumps to address some vulnerability. I thought dependabot commits were signed though. So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me.
- deathanatos 3y ago
  > I thought dependabot commits were signed though. … nothing stops a dependabot impersonator from signing their commit. (edit: the OP is rather confused on this point. While the commit could be signed, I don't know that in this case it could be signed in a way that Github would give it the green (Verified) bauble. The prose says the commit is signed, but the screenshot seems to suggest they're not. (Though they almost covered up the relevant area…)) You'd still have to notice that it's not coming from the real dependabot > So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me. Short of hovering over the user's icon¹ (which should go to the app, not to a user) or reading the contest of the commit … I don't think a good impersonation would look different from the real deal in the history. (Note that as others note: the commits here are already merged, via stolen PATs. You'd be trying to distinguish a malicious commit in your history from the real deal.) ¹actually, maybe they can't spoof the icon, since it's coming from a stolen PAT + the commit data isn't going to link up due to trying to spoof the name, which is why it's blank in the screencap. So that's a bit more of a giveaway, but I still think most people would be hard-pressed to notice.
- hedora 3y ago
  Version bumps are often enough to own a repository. There are plenty of examples of a quickly pulled version that introduces a security hole, and a few where the maintainer [account] pushes then immediately hides a malicious point release.
  - prepend 3y ago
    Certainly. But that’s two vulnerabilities and usually by different groups. So that’s a pretty sophisticated group to pwn a package and the submit all the dependabot version bumps. Not impossible, but less likely. And I don’t blindly accept version bumps as I read the associated CVE and see if I need it. And I think it’s pretty rare for major packages to get compromised. When pandas or numpy get breached, I think I’ll hear about it way before I accept a depdabot PR to change my version.
turboponyy 3y ago
I don't understand this sentiment. The majority of Dependabot's commits that I've seen are 1 or 2 line diffs that just bump a version number in a workflow file. Why wouldn't you want to accept those after a quick review?
- oceanplexian 3y ago
  Speaking as someone with SRE experience that thinking keeps me up at night. Bumping version numbers isn’t like auto updating your phone. How was the new version tested? Did it go through some sort of QA process? What subtle behavior changes are going to inpact your application or downstream dependencies? Did the license change in the new version? Are there performance regressions? Was the library hacked, and the new version introduced an exploit into your application?

JohnFen 3y ago

Are people accepting pull requests without actually reviewing the code being contributed?? That seems like the larger problem...

sdflhasjd 3y ago
There are projects that automatically merge dependabot PRs...
- mistrial9 3y ago
  projects with underpaid and outsourced contractors by any chance?
  - MiguelX413 3y ago
    More likely, simply open-source projects.
- earthling8118 3y ago
  Funnily enough I'd assume that those projects would be immune to this type of attack unless the automation is absolutely terrible.
- oalders 3y ago
  Presumably an automated merge would be checking something like > if: github.event.pull_request.user.login == 'dependabot[bot]'
  - turboponyy 3y ago
    No, the automated workflow would be something like this: - Run dependabot workflow (outputs: $pr_number) - Automerge $pr_number
Karellen 3y ago
If dependabot is part of GitHub's own infrastructure, and the last 100 pull requests it sent were good, some maintainers might think it trustworthy. I'm pretty sure there are maintainers of Linux that Linus has been working with for long enough that he trusts them to the point that doesn't feel the need to examine every one of their commits. Also, he can't check every commit closely. Linux 6.5 merged 13,561 commits over 9 weeks[0], which is in excess of 200 commits per day - and that was a small release. Learning to trust regular contributors is one of the things that makes OSS work as scale. Edit: Of course, Linus makes sure that stuff he merges from trusted contributors is actually from them, either because it's from a repo he knows they control, or it's GPG-signed and the signatures are checked. The problem is failing to confirm that commits come from the trusted source you think they're from, not failing to examine the commits themselves. [0] https://lwn.net/Articles/941675/ https://lwn.net/Articles/941675/
- EGreg 3y ago
  There should be an actual green checkmark for Dependabot and others
  - funcDropShadow 3y ago
    Dependabot should sign it's PRs with a gpg signature. And web interface could get support to check those signatures. That is way more trustworthy than a random green flag in some web ui that changes all the time.
deathanatos 3y ago
It seems like these are being pushed directly, using stolen credentials. (I.e., attackers are just leaking more credentials & compromising the repo. They're just hiding behind dependabot's good name by spoofing it.)

prepend 3y ago

I’ve accepted a bunch of dependabot PRs but I always review the change they make. Sometimes I modify or reject depending on the change. All the ones I remember are just version bumps to address some vulnerability. I thought dependabot commits were signed though. So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me.

deathanatos 3y ago
> I thought dependabot commits were signed though. … nothing stops a dependabot impersonator from signing their commit. (edit: the OP is rather confused on this point. While the commit could be signed, I don't know that in this case it could be signed in a way that Github would give it the green (Verified) bauble. The prose says the commit is signed, but the screenshot seems to suggest they're not. (Though they almost covered up the relevant area…)) You'd still have to notice that it's not coming from the real dependabot > So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me. Short of hovering over the user's icon¹ (which should go to the app, not to a user) or reading the contest of the commit … I don't think a good impersonation would look different from the real deal in the history. (Note that as others note: the commits here are already merged, via stolen PATs. You'd be trying to distinguish a malicious commit in your history from the real deal.) ¹actually, maybe they can't spoof the icon, since it's coming from a stolen PAT + the commit data isn't going to link up due to trying to spoof the name, which is why it's blank in the screencap. So that's a bit more of a giveaway, but I still think most people would be hard-pressed to notice.
hedora 3y ago
Version bumps are often enough to own a repository. There are plenty of examples of a quickly pulled version that introduces a security hole, and a few where the maintainer [account] pushes then immediately hides a malicious point release.
- prepend 3y ago
  Certainly. But that’s two vulnerabilities and usually by different groups. So that’s a pretty sophisticated group to pwn a package and the submit all the dependabot version bumps. Not impossible, but less likely. And I don’t blindly accept version bumps as I read the associated CVE and see if I need it. And I think it’s pretty rare for major packages to get compromised. When pandas or numpy get breached, I think I’ll hear about it way before I accept a depdabot PR to change my version.

turboponyy 3y ago

I don't understand this sentiment. The majority of Dependabot's commits that I've seen are 1 or 2 line diffs that just bump a version number in a workflow file. Why wouldn't you want to accept those after a quick review?

oceanplexian 3y ago
Speaking as someone with SRE experience that thinking keeps me up at night. Bumping version numbers isn’t like auto updating your phone. How was the new version tested? Did it go through some sort of QA process? What subtle behavior changes are going to inpact your application or downstream dependencies? Did the license change in the new version? Are there performance regressions? Was the library hacked, and the new version introduced an exploit into your application?