Is it wise to simply keep private repositories away from GitHub at this point? It seems the best way to avoid being drawn in with the rest as a target.
Internal bad actors? So location wouldn't matter?
This sounds like the equivalent of "Use MacOS because most viruses target Windows". Which some people do, and yes it probably lowers your risk, but there are ways to use Windows (and Github) securely.
If you're really paranoid about your source code, you should probably self-host your own instance of Github/Gitlab/etc (and lock it down through VPNs, IP white lists, etc) rather than using their cloud service.
This approach also gives you first hand access to logs that would expose internal bad actors, if that's included in your threat model.
No proprietary software you have no control over or ability to audit can ever be considered secure.
Going to respectfully elaborate on this specific point, with full awareness that it's not core to the discussion, and that my opinion is my own and highly subjective, and that I'm not fully disagreeing but wish to point out a nuance. There are too many ways to put hidden software on a Windows system, which makes it harder to use securely than my OS of choice, macOS.
It's more difficult to audit a Windows system than a macOS system. For example, background processes can be installed on Windows in dozens of ways. Go download AutoRuns (https://learn.microsoft.com/en-us/sysinternals/downloads/aut...) and look how many tabs it has. The docs even say "You'll probably be surprised at how many executables are launched automatically!". UAC mitigates this somewhat, but it lacks granularity; it's all-or-nothing so you'll click Allow without knowing what's actually going to happen. And then you have COM registration and win32 APIs that let applications get at other windows easily. Layer upon layer of legacy compatibility make the whole system feel like a mess - at least to me.
Using macOS securely is also quite involved of course - for example auditing Homebrew's behavior when it downloads half the open-source world just for one package. But when it comes to stuff running in the background, by comparison, macOS Ventura recently added a comprehensive list of launchd agents and other daemons that run at startup; each of which can be toggled (though the UI doesn't allow you to drill into them). It's all on one pane in System Settings, built into the OS, no need for Sysinternals' separate tools.
Using macOS securely is a lot easier, in my experience. There are ways to use Windows securely, but it's a lot harder, and (I think) that makes it not worth the trouble. Using macOS securely is a lot closer to just using macOS.
That said, for any OS, it goes without saying to only install trusted software. It's possible to cleanse both OSes fully of software you no longer want, but on Windows it always feels like surgery, whereas 90% of cleaning something from macOS is dragging the application bundle to the Trash.
> The incident involves threat actors gaining access to Slack's externally hosted GitHub repositories via a "limited" number of Slack employee tokens that were stolen.
> While some of Slack's private code repositories were breached, Slack’s primary codebase and customer data remains unaffected, according to the company.
There are "application credentials" or "API tokens" that get generated for various purposes and live long.
There are many programs that do not support "credential helpers", abd those would need you to input an API token that is generated usually just once and has almost always has enough permission to clone a repository (at a minimum).
The `hub` and `lab` CLI tools work exactly in this manner.
If you are familiar with intellij: certain plugins that integrate with github or gitlab also require the generation of an access token so that you can do API calls to see merge requests and such: https://docs.github.com/en/authentication/keeping-your-accou... & https://docs.gitlab.com/ee/user/profile/personal_access_toke...
Applications that support credential helpers are docker (for optionally authenticating with docker registries) and git itself.
But does it solve the problem? It prevents the keymatter from leaking, but the problem is that the API key was put somewhere sensitive and then stolen. Presumably you'd need access to be able to use the keymatter from any location where you'd normally need API keys: CI machines, developer workstations, production, etc.
Worse, if you have some machines (CI, HSM) that are accessed over network traffic and that traffic is secured with an API key, you are back to square one again, where a stolen API key allows for continuous access.
Would this help for auditing? No, not really. You can already have plenty of auditing and alerting to try to prevent exfiltration anywhere an API key is used.
In other words, probably not. It might help a little bit just by making exploitation harder, in optimal circumstances, but it doesn't fundamentally change the problem; if dev workstations or CI are compromised, you're going to have a bad time.
But then you lose convenience.
Slacked picked convenience and it led to the headline: "Slack's private GitHub code repositories stolen over holidays" and the top voted HN comment so far is: "Slack is selectively and deliberately limiting public access (discoverability) to the security breach announcements.".
The question is: was convenience worth it?
There are other tools. There are other ways to host. There are other ways to do CI/CD.
But it's less convenient.
It's a tradeoff.
* gitlab hosted internally * VPN needed to access gitlab * VPN requires a gsuite login, with 2FA * You can only login to a gsuite account on a employer-provided machine (so no access to anything on a non-employer machine, even email)
You'd have to steal a company laptop, or social engineer yourself into a building with a desktop machine, to even start to get near the code repository.
The "must login from a employer-provided machine" thing can be disabled on a per-user basis by remote policy (via an administrator), if needed.
How is this achieved?
The problem is that there are some resources where the benefit to the attacker goes up faster than the company can afford to cover, and the company has to cover all the attack avenues. You can imagine that the value of Slack's source code can be high to certain people, and it can be difficult to completely seal off something like that when source code by its nature pretty much has to be distributed to hundreds or thousands of people. (At least overall; any given source may not be that distributed, but there will be thousands with some sort of access.)
Major corporations basically have to act as if source compromise is inevitable. Best practices obviously include partitioning who can have access to what (perhaps the best practical argument against a one-company mono-repo, if de facto it has to be broken up by access permissions anyhow) and not including anything in the repo that is directly security catastrophic if it gets out (security secrets mostly), but this is still limiting blast radius rather than "solving" the problem.
It's a perfect storm of being extremely expensive to cover, in terms of money, internal process friction, and having a lot of heterogeneous vectors you need to cover, and for certain companies, being very high value to a number of different kinds of entities.
Being in GitHub specifically would only matter if GitHub was itself compromised. GitHub can not do very much about legit credentials being stolen through completely non-GitHub related means. (Most things, if not all things, that might leap to your mind will also block legitimate usage quite a bit. No matter what crazy thing you can imagine, someone's probably doing it somewhere and it's probably mission critical.)
I expect there have been a great deal more source code compromises than we've heard about.