[rficcaglia]

The initial reaction is to TL;DR as weak passwords and no MFA but I am equally/more concerned that the policy granted to vendors allows them to access more data than they really need, or the data they must have access could be better de-identified. For example they could hash/uuid the email and the git repo and branch info. Hacks are going to happen; no password or MFA will prevent it. Zero trust in your policy/schema design minimizes blast radius in these inevitable cases.

[pushpop]

The idea of treating email addresses as secrets is a nice idea in theory but given the plethora of databases where it’s already stored as a user name, including those that have already been compromised, and how email addresses are published in the git commits anyway, I don’t think it makes much sense hashing email addresses in practice.

Repository details are another interesting point though. They too are published openly in any git clones but I accept that some people’s repositories, including any local clones, would be private and kept secured from prying eyes. That said, what matters more there is access credentials, encryption at rest (for local clones), etc. So keeping the branch names and repository URIs secret feels a little redundant compared to the actual security benefit it brings. One might even say it’s security through obscurity, though I don’t personally think it offers up even enough benefit to fall under that category. That said, I’m happy to be convinced otherwise if you feel I’ve overlooked some important detail.