Best practice would be to store such keys in an encrypted state, to prevent such breaches from non-production datasource access, or _even_ direct production database access.
Best practice would be to store such keys in an encrypted state, to prevent such breaches from non-production datasource access, or _even_ direct production database access.
Anyone experience with losing an entire DC to flooding?
edit: I just Googled it (lol) and this DC has to be brand spanking new (https://cloud.google.com/blog/products/infrastructure/google...), apparently they just opened it last June. Google must be livid with the contractors who built the place for it to get flooded so soon.
Restoration is hard when health and safety are in question. Good luck to these ops folks <3
[1] https://www.datacenterknowledge.com/archives/2008/06/01/expl...
I’m becoming more and more convinced that they’re preparing for a global recession.
I posed such an Ask HN a while ago, before the Microsoft layoffs, where the general takeaway was that there’s no indication for a recession.
However, after the 10+12K layoffs by the giants, and constant news about smaller layoffs by smaller companies (in the 100s per announcement), I think the situation becomes at once clearer and bleaker.
We shall survive.
Many unanswered questions.
- Github alerted Okta about the access, they were not able to detect this themselves (https://docs.github.com/en/organizations/keeping-your-organi...)
- It only says "access to code repositories" (it does not say anything about the level of that access, it might as well mean write access, capability to trigger actions etc.)
- Not relying on the confidentiality of source code is great, but malicious CD workflow actions would still be a risk if attackers had that level of access.
- No information about the entry point for compromise.
I doubt their 'commitment to transparency'.
For example, I trialed major security vendor's enterprise product. They required their app be granted Admin on the GitHub org. All they needed to do was create issues, PRs, and read source code for analysis. There are scopes for that.
I was eventually on a call with a principle engineer in this company, who kept saying they needed this permissions, and I kept showing him the API docs that showed that wasn't so. Eventually he said, "well, we won't _use_ all those permissions, so just give them to us anyway, because it's easier this way." Sure, I'll give you the ability to change all my code, add/remove users, drop repos... etc, and trust that some day, when you're hacked, someone will not use those over granted permissions maliciously?
Security is hard. Be careful what permissions you give your 3rd party GitHub integrations.
At this point it appears that they found more credentials on the internal network and owned SSO, MFA and AD giving admin access to everything.
That's my hangup. The fact that admin/root level accounts can be accessed with "credentials" alone, rather than only via SSO/MFA/Yubikey. Were these service accounts, what happened to least privilege?
We need your help to scale up our cloud based, AI testing software startup and put our 40M Series C raise to work.
We’re a 100% serverless operation built on Google Cloud Platform that rapidly develops and deploys features on a CI/CD model. Seven years in, we’re a Gartner recognized industry player and growing our engineering ranks to keep building out our platform.
Our open positions:
- Software Engineer - Mobile Infrastructure (Onsite / Hybrid US)
- Software Engineer - Integrations Team (Remote India)
Our stack is built with modern Java 17, TypeScript, and Infrastructure as Code
Drop me (an engineer), any questions joe at-symbol mabl.com, and checkout our careers site [1]. We can’t wait to work with you.
[1] https://www.mabl.com/join-the-team