Vulnerabilities in third-party libraries and software are extremely common and could be used to compromise the security of systems using the software. Over the last several years approximately 4500 CVEs have been published per year. Only some of these vulnerabilities are relevant to GitHub, but it can be quite a challenge to keep track of these on a day-to-day basis.
Our applications use a large number of third-party and open source libraries and software. It is no secret that GitHub is built on Rails, and that we take full advantage of the tremendous number of gems published by the Rails community. Each of these gems may introduce a flaw that could impact the security of GitHub. But, it isn’t just Ruby libraries we need to concern ourselves with. We also use software such as HAProxy, Nginx, libgit2, and many others to help make GitHub possible.
Fortunately, GitHub contributes to a large number of the projects that we rely on. This helps us keep track of critical vulnerabilities in these components. However, we also rely on following mailing lists, word of mouth, and other manual means of keeping track of vulnerabilities. Regardless of how we are made aware of a vulnerability, the way we deploy at GitHub lets us put a fix in place as quickly as possible.
More about using components with known vulnerabilities from OWASP’s Top 10:
Virtually every application has these issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.
|2||500 pts Ben Cox Weak user SSH keys|
|3||500 pts hnw Weak user SSH keys|
|4||100 pts Egor Homakov Facebook Connect on Speaker Deck|