5 ms·

>What we built is a rules engine, which is essentially a server-side git-hook platform. Isn't it too late once it is committed to github? It seems like this wo

>What we built is a rules engine, which is essentially a server-side git-hook platform. Isn't it too late once it is committed to github? It seems like this would be much more useful as a service running as a precommit hook on each workstation. Probably harder to ship/monetize that but as far as actually solving the problem wouldn't that be better?

ldthorne 7y ago
Agreed that it's too late in that the key is compromised at that point, but a notification before you release to production that you've accidentally committed it allows you to roll the key (hopefully) before any bad actors find it.
shimont 7y ago
Initially, we started as a CLI tool, but as you said, it is part of the problem, how do you make sure all of your developers are using the CLI/pre-commit hooks? This is why we choose to integrate on the pull-request level. It is not perfect, but at least your plain text secrets will not be merged into master and go in onto your developer's laptops and your servers(less). :) We try to find a balance between perfect and achievable in an easy way for our customers
- lasryaric 7y ago
  But it’s already in the git objects and therefore accessible to anyone who clones the repository? I am not 100% sure about that. Can someone confirm?
  - shimont 7y ago
    We educate our customers on how to delete the branch and remove it from history: https://docs.datree.io/docs/do-not-include-secret-files https://docs.datree.io/docs/do-not-include-secret-files
    - ben509 7y ago
      I think you're miseducating your customers. If creds leak, rotate those creds. Then, you check your logs to make sure there was no intrusion. "Rotate the creds" gives the absolute best guarantee that they're useless. Three words I can explain to a nervous manager. "What if someone got ahold of those creds?" "Well, boss, here's the window in which it could have happened, and let's go over these logs together to see if it did." Scrubbing the repo? I'm skeptical that you're getting rid of anything without push --force, and you sure as heck aren't running `git gc --prune` on the remote system, let alone `bfg`.
      - shimont 7y ago
        I totally agree! you should rotate the keys! we explain how to get rid of it in terms of Git. This is in addition to rotating it. Sorry for not being clear
ThePhysicist 7y ago
As far as I know Github has their own technology for blocking code pushes that contains e.g. AWS secrets. I think it happened a lot that people pushed such secrets to the platform and Github's streaming API makes/made it really easy for adversaries to catch those and start abusing them within seconds.
- eyarz 7y ago
  you are right but blocking secretes is only a subset of what our engine can do. also, as far as I know, the secret blocking feature github is offering is ONLY for public repos.

ldthorne 7y ago

Agreed that it's too late in that the key is compromised at that point, but a notification before you release to production that you've accidentally committed it allows you to roll the key (hopefully) before any bad actors find it.

shimont 7y ago

Initially, we started as a CLI tool, but as you said, it is part of the problem, how do you make sure all of your developers are using the CLI/pre-commit hooks? This is why we choose to integrate on the pull-request level. It is not perfect, but at least your plain text secrets will not be merged into master and go in onto your developer's laptops and your servers(less). :) We try to find a balance between perfect and achievable in an easy way for our customers

lasryaric 7y ago
But it’s already in the git objects and therefore accessible to anyone who clones the repository? I am not 100% sure about that. Can someone confirm?
- shimont 7y ago
  We educate our customers on how to delete the branch and remove it from history: https://docs.datree.io/docs/do-not-include-secret-files https://docs.datree.io/docs/do-not-include-secret-files
  - ben509 7y ago
    I think you're miseducating your customers. If creds leak, rotate those creds. Then, you check your logs to make sure there was no intrusion. "Rotate the creds" gives the absolute best guarantee that they're useless. Three words I can explain to a nervous manager. "What if someone got ahold of those creds?" "Well, boss, here's the window in which it could have happened, and let's go over these logs together to see if it did." Scrubbing the repo? I'm skeptical that you're getting rid of anything without push --force, and you sure as heck aren't running `git gc --prune` on the remote system, let alone `bfg`.
    - shimont 7y ago
      I totally agree! you should rotate the keys! we explain how to get rid of it in terms of Git. This is in addition to rotating it. Sorry for not being clear

ThePhysicist 7y ago

As far as I know Github has their own technology for blocking code pushes that contains e.g. AWS secrets. I think it happened a lot that people pushed such secrets to the platform and Github's streaming API makes/made it really easy for adversaries to catch those and start abusing them within seconds.

eyarz 7y ago
you are right but blocking secretes is only a subset of what our engine can do. also, as far as I know, the secret blocking feature github is offering is ONLY for public repos.