This feels... ...ridiculous in this day and age.
People play make believe about this stuff. “The practice I feel strongly about, it’s secure. And the other guy is a moron.” The XZ crisis shows how little credential isolation matters. Maybe even at Google, you could work there and feel very strongly about their security practices, and then governments have access to everything anyway, at the front end proxies or whatever. It’s important to pay attention to security, but I think programmer resources should focus on “cheating,” not “security.”
For a tortured analogy, let's say you keep your guns in a gun-safe in your garage, and then hang the key for the safe in the garage. With a sign saying "gun safe key".
Not leaving the safe key out in the open doesn't guarantee your guns are impervious, of course, a sufficiently motivated and skilled burglar willing to put time and effort into breaking open the safe would be able to access your guns.
But, that takes time. And it makes noise. Both of which increase the chance of being caught.
But if the key is right there? Easy as.
Yep, they had obtained access to the repo, like the burglar had obtained access to the garage.
But if the AWS secrets weren't just hanging on the wall, then progressing from Gitlab compromise to S3 compromise would a) be harder and b) take longer, both of which increase the chance of discovery.
Just saying, if you care about the security of your guns and/or customer data, don't leave the key hanging about in plain sight as a good first step.
Make them compromise multiple things, not just one thing.
I'm desperately trying to work encryption at rest into this analogy. Um... trigger locks?
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.