6 ms·

I don't get it. If github declines the push then the blob must have already crossed the internet? The message says to remove the secret from the commit but the

I don't get it. If github declines the push then the blob must have already crossed the internet? The message says to remove the secret from the commit but the actual action to take would be to rotate the secret since it's been exposed to github, no?

nickelpro 3y ago
Better than it being exposed to the entire world Also I feel fairly confident Github/MS aren't about to change their business model to become a blackhat hacking collective
- darthbanane 3y ago
  Yeah definitely better than allowing the push. But I feel they should also at least recommend rotating the secret
  - minedwiz 3y ago
    My team checked out the similar thing they're pushing in ADO (https://learn.microsoft.com/en-us/azure/defender-for-cloud/azure-devops-extension https://learn.microsoft.com/en-us/azure/defender-for-cloud/a...). The messages from that thing do tell you to rotate, though AFAIK not having looked that far into it just breaks the build, not proactive push detection.
- 7znwjshsus 3y ago
  That's not the risk. The risk is that Github has lackluster permissions and audit trailing and an employee could leak and sell keys. Or that they log keys and someone hacks their logs. Rotating the secret is 100% the correct thing to do in this case.
  - prepend 3y ago
    I’m not that worried about this. I mean, Microsoft runs azure and they have security protocols, that you can audit and show to your auditors, that reduce the risk of sysadmins snooping on vms, blob storage and anything else they could scan for keys. I think the risk of a GitHub employee introducing malicious code to scan memory and dump any tokens found for exhilaration is lower than the risk of my own employee or myself doing that. Rotating the secret seems like a waste of resources in this situation.
glitchc 3y ago
A Github PAT being exposed to Github is not the problem. That is, in fact, intended behaviour. A Github PAT being exposed to the internet is something else entirely, and likely to be an accident in most cases. That's what thd protection's for.
- darthbanane 3y ago
  For PAT ok but surely this also scans for aws credentials etc, or is it really just about PATs?
  - bmitc 3y ago
    What's worse: them being scanned and prevented or being committed into the public repository without anyone's knowledge?
    - darthbanane 3y ago
      Yeah I'm not saying this is not a net positive. I just don't understand why the recommendation reads like all is good as long as one amends the commit and nothing just happened.
      - bmitc 3y ago
        That makes sense. I think it's just an extra step of protection, kind of like an alert that someone may have seen your ATM pin, so it's probably best to rotate it. But, your pin wasn't posted on the Internet.
awesome_dude 3y ago
I think that the main benefit here is that the credentials aren't published for all and sundry to see. The scanner has seen the credentials, yes, and it's then up to the individual to decide if that credential should be considered "compromised" or not (seeing as the Github scanner has seen that credential) It's a step up from - oh sh*t everyone can see it and the user isn't even aware that they did the dumb
- darthbanane 3y ago
  I agree but according to their goal of empowering developers with security awareness they should make it more clear that this is a server-side check and that the credentials were exposed in plain text, just not to the general public. The screenshot says just amend the commit and all's good
tetha 3y ago
I agree. I'd say this offers two good things though: First off, it very directly informs you by interrupting your workflow. The secret doesn't go out and nothing happens - your dang git push doesn't work for some reason. This means you notice the leak earlier. And additionally, it limits the exposure of the secret, which buys you time for the rotation. If you find some important credential in a public repository on the internet a few days or weeks after it was exposed, it's time to scramble to rotate the secret and spend the next few days picking up the pieces and putting systems back together. If the secret has been exposed to a somewhat reputable entity or an entity you have a business relationship with, you can most likely take a day to plan the rotation and executed it. We've had this a few times during on-prem maintenance of customer systems or support calls with customers. Copy the wrong thing, paste the wrong thing, whoops we have the password for the superuser of your database cluster. It certainly enforces a rotation of that password, but with the business relationship there, it doesn't have to happen head over heels.

nickelpro 3y ago

Better than it being exposed to the entire world Also I feel fairly confident Github/MS aren't about to change their business model to become a blackhat hacking collective

darthbanane 3y ago
Yeah definitely better than allowing the push. But I feel they should also at least recommend rotating the secret
- minedwiz 3y ago
  My team checked out the similar thing they're pushing in ADO (https://learn.microsoft.com/en-us/azure/defender-for-cloud/azure-devops-extension https://learn.microsoft.com/en-us/azure/defender-for-cloud/a...). The messages from that thing do tell you to rotate, though AFAIK not having looked that far into it just breaks the build, not proactive push detection.
7znwjshsus 3y ago
That's not the risk. The risk is that Github has lackluster permissions and audit trailing and an employee could leak and sell keys. Or that they log keys and someone hacks their logs. Rotating the secret is 100% the correct thing to do in this case.
- prepend 3y ago
  I’m not that worried about this. I mean, Microsoft runs azure and they have security protocols, that you can audit and show to your auditors, that reduce the risk of sysadmins snooping on vms, blob storage and anything else they could scan for keys. I think the risk of a GitHub employee introducing malicious code to scan memory and dump any tokens found for exhilaration is lower than the risk of my own employee or myself doing that. Rotating the secret seems like a waste of resources in this situation.

glitchc 3y ago

A Github PAT being exposed to Github is not the problem. That is, in fact, intended behaviour. A Github PAT being exposed to the internet is something else entirely, and likely to be an accident in most cases. That's what thd protection's for.

darthbanane 3y ago
For PAT ok but surely this also scans for aws credentials etc, or is it really just about PATs?
- bmitc 3y ago
  What's worse: them being scanned and prevented or being committed into the public repository without anyone's knowledge?
  - darthbanane 3y ago
    Yeah I'm not saying this is not a net positive. I just don't understand why the recommendation reads like all is good as long as one amends the commit and nothing just happened.
    - bmitc 3y ago
      That makes sense. I think it's just an extra step of protection, kind of like an alert that someone may have seen your ATM pin, so it's probably best to rotate it. But, your pin wasn't posted on the Internet.

awesome_dude 3y ago

I think that the main benefit here is that the credentials aren't published for all and sundry to see. The scanner has seen the credentials, yes, and it's then up to the individual to decide if that credential should be considered "compromised" or not (seeing as the Github scanner has seen that credential) It's a step up from - oh sh*t everyone can see it and the user isn't even aware that they did the dumb

darthbanane 3y ago
I agree but according to their goal of empowering developers with security awareness they should make it more clear that this is a server-side check and that the credentials were exposed in plain text, just not to the general public. The screenshot says just amend the commit and all's good

tetha 3y ago

I agree. I'd say this offers two good things though: First off, it very directly informs you by interrupting your workflow. The secret doesn't go out and nothing happens - your dang git push doesn't work for some reason. This means you notice the leak earlier. And additionally, it limits the exposure of the secret, which buys you time for the rotation. If you find some important credential in a public repository on the internet a few days or weeks after it was exposed, it's time to scramble to rotate the secret and spend the next few days picking up the pieces and putting systems back together. If the secret has been exposed to a somewhat reputable entity or an entity you have a business relationship with, you can most likely take a day to plan the rotation and executed it. We've had this a few times during on-prem maintenance of customer systems or support calls with customers. Copy the wrong thing, paste the wrong thing, whoops we have the password for the superuser of your database cluster. It certainly enforces a rotation of that password, but with the business relationship there, it doesn't have to happen head over heels.