> Yep, they had obtained access to the repo, like the burglar had obtained access to the garage. I'm not going to talk in analogies. There's no more depth at t

> Yep, they had obtained access to the repo, like the burglar had obtained access to the garage. I'm not going to talk in analogies. There's no more depth at the stage that the source code is compromised, regardless of how many credentials are put where. It's sort of a matter of opinion. I mean this is what I am saying by make-believe: everything you say is, quite literally, a bunch of analogies, because there isn't any actual hard evidence to any of it, it is wood carving traditions. Of course I agree that they're good practices, but man, there are unlimited good security practices, and only limited money and time. Another point of view is, it's easy to provide generalized, vendor-colored advice about credential security. You know, just buy AWS KMS whatever the fuck, right? It is hard to write software that accommodates arbitrary changes to authorization requirements & stories. There are a lot of commenters here giving these Sisense people a hard time, and I doubt they're stupid, more so that they are really unlucky. I feel like the comments miss the forest for the trees. Most startups have admin roles, and if you're using something like Next.js, Elixir, Ruby on Rails or Go, your application's API methods have ad-hoc, in-source policy enforcement and definitions. This is what happened here: the developer's GitHub credentials are an Admin role. It could happen in any scheme. Can you develop an application without an admin role? Not a SaaS. Now you should see why it's okay for Postgres to have all its source code open, but not your SaaS company's, for the purposes of security.