Being downvoted bc of why? I literally said THE MOST obvious purposefully and left out the 20+ other things that a good security researcher would hunt down in this - each to allow compromise of the company, build process, downstream or someone using enterprise.
I am not advocating it - I am making people aware that is what leaks mean.
[I randomly picked 20. Because it's usually a lot of options when you have source code access]
Your comment amounts to "Github's security team should be making sure the dependencies in their Gemfile don't have vulnerabilities". Which is an obvious and pointless statement, yes, of course github's security team should make sure github's code doesn't have vulnerabilities. That's the most important duty of their job.
The fact that the Gemfile has been leaked changes nothing about what the security team should be doing.
Your comment doesn't really contribute to discussion because it's not presenting novel information, and it's misleading because, per the reasons above, their security team's priorities goals/responsibilities/behaviors/etc aren't really impacted by this, and your comment sorta implies otherwise.
Good discussion - I respectfully disagree. It increases downstream risk to GH enterprise, and means the risk flows to security team setup at on-prem clients, whom often have no security team - or a few security engineers possibly. And they're looking at lots of things besides on-prem solutions.
That's what I was getting at. It means this list - has more avenues & more options for on-prem risk. For someone who has internal network access to lateral subnet (small example). Because one who chose to can start analyzing methods for privileged code access. CISOs would want to add additional review of the surrounding on-prem network and hardware. Just my thoughts.
I still don't understand what you're suggesting a couple comments up. You said "They need to protect their Gemfile". What did you mean by "protect their gemfile"? It's already out there.
> It increases downstream risk to GH enterprise
I disagree with that. People have been able to de-obfuscate and read github enterprise's source code for pretty much as long as github enterprise has existed. Researching security vulnerabilities in it is not really any different.
> Because one who chose to can start analyzing methods for privileged code access.
As above, people already could do this; the deobfuscated GHE code is pretty easy to get your hands on. And the chance of there being a remotely exploitable vuln that exfiltrates code or gives you an admin account.. well, that seems to remain at "pretty unlikely".
If this were to logically follow, than no one would run Gitlab, an open source equivalent, because the source code is available for people to "analyze methods". However, I have a similar level of respect for github and gitlab's security teams, and I tend to think the security of both of them is pretty decent, irrespective of whether the code is leaked, open source, or proprietary.
> CISOs would want to add additional review
I also disagree with that understanding. A CISO in the past would have already decided "We trust github's security practices enough to run GHE here and put our code in it." The fact that the code has leaked changes that not-a-wit. The CISO still trusts github's security practices, and those practices haven't changed.
I've now realized I need to be less obfuscating in my suggestions on HN. Literal appears to be the only way. I was suggesting around the corners for people to begin connecting further dots.
