RE: has anyone bothered to read this "Git is a security risk"?

> -----Original Message-----
> From: Jason Pyeron 
> Sent: Tuesday, April 14, 2020 4:59 PM
> To: 'Git Mailing list' <git@vger.kernel.org>
> Cc: 'Robert P. J. Day' <rpjday@crashcourse.ca>
> Subject: RE: has anyone bothered to read this "Git is a security risk"?
> 
> Yes. It is a FUD tool to sell their product/service.
> 
> > -----Original Message-----
> > From: git-owner@vger.kernel.org <git-owner@vger.kernel.org> On Behalf Of Robert P. J. Day
> > Sent: Tuesday, April 14, 2020 4:14 PM
> > To: Git Mailing list <git@vger.kernel.org>
> > Subject: has anyone bothered to read this "Git is a security risk"?
> >
> >
> > https://twitter.com/blubracket/status/1250123442600513547
> 
> They claim 5 risks.
> 
> Risk #1 - Secrets in code.
> Risk #2 - Malicious code from unauthorized open source.
> Risk #3 - Your business, network and infrastructure blueprint exposed through code.
> Risk #4 - Sensitive code and PII on public code sharing websites.
> Risk #5 - IP theft.
> 
> With a SALES PITCH at the end
> 
> "
> BluBracket can help.
> 
> While software development has changed dramatically and software
> has grown in importance, the ways we secure code have not. This has to
> change. BluBracket is the first comprehensive security solution for code
> in the enterprise. We deliver the insights and control enterprises need
> to keep code safe. Contact us for an exploration of how we can help,
> including an audit of your production environments for secrets in code
> and other vulnerabilities.
> "
> 
> In short by using FUD, the reader is more likely to buy their product which will alleviate your fears,
> uncertainty, and doubt around GitHub, Inc. and Git technology.
> 
> They have 10 specific attacks on Git/Github in their paper, I have listed them below. In square
> brackets ([]) I have added meaning where needed. The "Git" contextual quotes are as follows:
> 
> 1. "A decade ago, companies didn’t worry much about code security. ... GitHub had only just begun ...
> code and coding environments today represent the biggest unmanaged and unmonitored risk to enterprise
> security"
> 
> 2. "Between Google and Github searches, these secrets [keys, password, etc.] are a gold mine for
> hackers"
> 
> 3. re-quote from How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories
> Network and Distributed Systems Security (NDSS) Symposium 2019 “We find that not only is secret
> leakage pervasive — affecting over 100,000 repositories — but that thousands of new, unique secrets
> are leaked every day.”
> 
> 4. "In 2018, for instance, hackers mirrored the popular Linux distribution Gentoo’s Github
> repositories and replaced them with a malicious backdoor that would erase files."
> 
> 5. "In 2019, hackers attempted a similar exploit against Ubuntu’s Github repositories."
> 
> 6. "Recently, an AWS engineer published a 1G repository to Github containing a treasure trove of PII,
> including bank statements, customer correspondence, drivers’ licenses, and multiple key pairs and
> tokens."
> 
> 7. "there is so much valuable information now on Github, hacker groups have automated searches"
> 
> 8. "hacker posted details about it [Capital One breach] in a public Github repository. Github was
> recently sued over their role in this incident"
> 
> 9. " This [the finding of sensitive data in a repository] generally is inadvertent because Git makes
> it so easy to share code"
> 
> 10. "
> 
> But unfortunately, Git is the wild west. Right now security teams have little
> to no visibility into where this important enterprise asset lives.
> 
> While visibility is a huge issue, code proliferation is another. Git was
> developed for open source projects, not the enterprise. By default, everyone
> has access to everything. A contractor can download all the code in that
> repository, not just the section he is working on. With one click, he can then
> upload your code to his or her own personal repository.
> 
> There are currently no repeatable, scalable ways to lock down access or even
> track and monitor behavior. And if an insider wants to take code and sell it
> or use it at a competitor, there is currently no way of even being notified that
> your code has been published. By default, Git proliferates code.
> 
> "
> 
> In my opinion, as a cyber-security SME, software developer, git user and developer, etc... numbers 1
> through 8 have nothing to do with Git or Git related technologies/services. Bashing what one can do
> with GitHub.com is also silly, do not put your sensitive code on someone else's server.
> 
> Numbers 9 and 10 have a bit more merit, if only measured using the most sensitive measuring
> instruments. It is no more easy to be carless with your data stored in a git repository than
> subversion, than CVS, DVDs, portable hard drives, laptops in a café, etc. It is just data, you can
> copy it. 10 is a real concern but not because of git, but because of poor training, bad
> trustworthiness between the organization and worker, etc. I will recite an event that happened where I
> work many years ago.
> 
> Manager: Did you take DoD source code home without permission?
> Employee: excuse, avoids question, more excuses
> Manager: Let me be clear, you are fired. I need the answer to the question, did you take controlled
> DoD source code home with you?
> Employee: no.
> 
> Git is not a source of the problem, human resource management and cyber security hygiene are. We
> failed to cultivate a responsible employee, with a work ethic. The employee decided to telework
> without authorization (play hooky) claiming to work. But the git repository for that project was not
> accessible from home... Our Git was secure...
> 
> **SIGH**
> 
> 
> --
> Jason Pyeron  | Architect
> PD Inc        |
> 10 w 24th St  |
> Baltimore, MD |
> 
> .mil: jason.j.pyeron.ctr@mail.mil
> .com: jpyeron@pdinc.us
> tel : 202-741-9397
> 
> 
>