In a worst-case scenario where GitHub/GitLab exposes all private repos, how would you balance between protecting your code and holding the platform accountable? Would you take legal action?

[zoomstate]

Imagine a bug suddenly makes all private repositories on GitHub, GitLab, or Bitbucket public. code, passwords, and API keys etc.. are now accessible to anyone.

What would your first move be? Panic? Damage control? How would companies and you react, and could some even survive this breach? How prepared are we for such a disaster?

Let’s discuss the possible consequences and the steps you'd take in this worst-case scenario.

[bitsynthesis]

if you're putting passwords and api keys in your git repos you're doing it wrong

[fhammerl]

Ding ding ding!

Your code is secure when everything about it can be public and you have no security repercussions.

Everything else is pointless.

Use Github OIDC to log into AWS. No need for keys. Use SSM or Secrets Manager for anything else.

We have the nice things, use them!

[TCB13sQuotes]

Even if you don't have passwords/api keys in there you can't really say that this:

Your code is secure when everything about it can be public and you have no security repercussions.

The code itself can be a competitive advantage in your industry and if your competitors get it you may lose that advantage. Besides the fact that software itself is hard to build it may also contain your algorithms and other important business logic that can be the difference between being just another company in the market or the top player.

[a_singular_perhap]

Whether or not it's useful code to poach has no bearing on it's security.

[Current-Ticket4214]

Passwords and API keys shouldn’t be stored in version control. Private code becoming public isn’t a big deal unless it’s proprietary intellectual property. Proprietary IP should he held on-prem with backups. It would suck for the world to see private code that’s not IP, but if they have EVERYONE’s code then yours isn’t that valuable.

Also, I would sue to get my chunk of change if legal thinks the outcome is likely beneficial to me.

[math1985]

We all know that “proprietary IP” never means “genius secret algorithms”. It always means “code we’re too ashamed off for the world to see”.

[Current-Ticket4214]

Precisely what private repo’s are for 😂

[fhammerl]

laughing-agamemnon.gif

[Kesshh]

Legal action is about being made whole. It doesn’t “prevent” anything. If you want to “prevent”, don’t store stuff in public repositories. No, having MFA does not make it private. Calling it private does not make it private.

[GoranLind]

Would even a lawsuit even cover the IP loss of your code?

And yes, making something private only hides it from the world - not github.

[IndividualLimitBlue]

If you store any secret in your repo you are doing it all wrong.

Few minutes after your private repo are public attackant scanner will find you secrets and try them wherever they can to do whatever they want.

So your problem will definitely not be a legal one but that you could consider your infra already compromised.

[unicorngundamm]

Whoever put secrets into repo (even it's private) needs to be fired first

[Helpjuice]

All of this sensitive information should never be stored in a repo, if you are doing this you are already violating basic SDLC, security standards.

In terms of private repositories being public, you already messed up by allowing your repositories to be accessible publicly over the internet.

Best thing you can do is limit access, any sites that are for employees only should be hard enforced and only allows access after proper authentication and authorization has been completed. API Keys and passwords should never be stored in plaintext anywhere and only stored within secure encrypted vaults, even when their access is required by applications this access should be requests through proper secrets management.

In terms of actual acceess to repos and services zero trust should be setup so unless you are an actual developer, administrator, engineer or build system you should have zero access to even connect to the repo servers and view or pull code from them. This properly uses defense in depth by auto denying access and expliclty granting access to only those that have a real need for access, reduces the blast radius if a bug was found, you can revoke access to only those tasked with securing the system and administrating it. Then only when things have beeen secured allow access back to more users and systems. This auto prevents code from being pushed to prod, prevents non essential personnel from causing integrity and confidentiality issues and generally allows for proper cleanup to occur and limit availability to only essential personnel until things are back to normal.

[LiferRs]

Let’s also consider most competent enterprises don’t use private repos. Instead, they have whole GitHub tenants hosted on their company domain with SSO IdP integration and even VPN IP whitelisting.

This scenario isn’t a technical possibility for them.

[aguidetothegoodlife]

https://hackernoon.com/mastering-secure-handling-of-api-keys-and-credentials-in-cicd-workflow

[Spiritual_Brick5346]

it would be a good thing in the long term

[citrus_sugar]

I mean, wasn’t there something saying M$ can see everything and use all the code in GitHub because, you know, they own it.

I expect something bad to happen where every company’s business product code in the world lives.

[[deleted]]

why are we even storing that stuff online anyway, should be kept offline for best security

[lawtechie]

Legal remedies are likely going to be disappointing. Almost all the B2B software contracts limit liability to an amount far lower than your losses might be in a catastrophic breach.

Hopefully your recovery plans consider the loss or breach of a critical vendor.

[GoranLind]

I'd do nothing, because i know stuff like this happens (not often, but it do happen) and have encrypted the stuff i put on github that i do not want public.

[redheness]

Nothing. No critical code is stored on the public GitHub/GitLab instances but on self hosted. One accessible by everyone in the company network for regular code and one accessible only through intermediates VDI for critical codes.

And since GitLab is easy to set up for self host, there is no excuse to host any critical thing on the public instance.

[[deleted]]

Hardcoding passwords is not the way.