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

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?

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

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`.

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

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.

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.

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.