Github Security Lab Announcement: Protecting All Code Together

We all have a collective responsibility to keep open source software secure—none of us can do it alone. Today on Github Universe we announced the Github Security Lab . A place where security researchers, maintainers and companies across the industry come together to share our belief that open source security is important to everyone. We are pleased to have initial partners contributing to this goal. Together, we provide tools, resources, awards, and thousands of hours of security research to help protect the open source ecosystem. As part of today's GitHub announcement, Security Lab is making CodeQLfreely available to anyone who can find vulnerabilities in open source code. CodeQL is a tool that many research groups around the world use to perform semantic code analysis, and we have used it ourselves to find over 100 registered CVEs (Common Vulnerabilities and Exposures) in some popular open source projects. We are also launching GitHub Advisory Database- A public recommendation database built on GitHub, plus additional data associated with packages tracked by the GitHub dependency graph. GitHub's approach to security covers the entire security lifecycle of open source projects. The GitHub Security Lab will help you identify and report vulnerabilities in open source projects, while maintainers and developers use GitHub to create patches, coordinate disclosures, and update dependent projects to have the vulnerability resolved.

GitHub Security Lab

The mission of the GitHub Security Lab is to inspire and empower the global community of security researchers to protect the world's code. Our team will lead by example by dedicating ongoing resources to finding and reporting vulnerabilities in critically important open source projects. Teamna has already released over 100 CVEs to detect vulnerabilities. Ensuring the security of open source projects in the world is not an easy task. First, scale: a single JavaScript ecosystem contains over a million open source packages. In addition, there is a shortage of security specialists, about 500 developers to one specialist. Finally, there is coordination: the world's security experts work in thousands of companies. GitHub Security lab and CodeQL will help with this. In this work we are joined by companies who donate their time and expertise to find and report vulnerabilities in open source projects. Everyone has pledged to contribute in their own way, and we hope others will join us in the future.

• F5
• Google
• HackerOne
• Intel
• OITactive
• JP Morgan
• LinkedIn
• Microsoft
• Mozilla
• NCC Group
• Oracle
• Trail of Bits
• Uber
• VMWare

To extend the possibilities, we are also making our collaborative code analysis engine CodeQL free for use in open source projects. CodeQL allows you to query code as if it were data. If you know a coding error that led to a vulnerability, you can write a query to find all variants of that code, destroying an entire class of vulnerabilities forever. See how to get started with CodeQL . If you are a security researcher or work on a security team, we need your help. Ensuring the security of open source projects in the world will require the work of the entire community. GitHub Security Lab will host events and share best practices to help everyone get involved. Follow the GHSecurityLab accounton Twitter for more details.

Improving security workflow in open source

As security researchers uncover more vulnerabilities, maintainers and end users need better tools to fix them. Today, the process of fixing new vulnerabilities is often temporary. 40% of new vulnerabilities in open source projects do not have an identifier in the CVE when they are announced, that is, they are not included in any public database. 70% of critical vulnerabilities remain unpatched 30 days after developers are notified. We're fixing it. Maintainers and developers can now work together directly on GitHub to ensure that new vulnerabilities are only disclosed when maintainers are ready, and developers can quickly and easily upgrade to a fixed version.

GitHub Security Advisories

With security tips, maintainers can work with security researchers on fixes in a private space, submit CVE requests directly from GitHub, and submit structured vulnerability details. Then, when they're ready to post a security advisory, GitHub will send out alerts for the affected projects.

Automatic security updates

Getting notified about vulnerable dependencies is helpful, but getting pull requests with fixes is even better. To help developers respond quickly to new vulnerabilities, GitHub creates automatic security updates (automated security updates) - pull requests that update a vulnerable dependency to a fixed version. Automatic security updates for the system were launched in beta on GitHub Satellite 2019 and are now mostly available and deployed to every active repository with security warnings enabled.

Scanning tokens

One of the most common mistakes is hardcoding tokens or credentials in a project. Within seconds of pushing a commit to GitHub, or switching a project to public, we scan it for formats from 20 different cloud providers. When we find a match, we notify the providers and they take action, usually invalidating the tokens and notifying affected users. And today we announced four new partners: GoCardless, HashiCorp, Postman and Tencent.

GitHub Advisory Database

We've made all the changes that maintainers make to the GitHub security advisories, as well as additional data, mapped to packages tracked by the GitHub dependency graph, available for free. Explore the new GitHub Advisory database in your browser, link directly to posts with CVE IDs in comments, or access data programmatically using the Security Advisory API endpoint. Author: Jamie Cool Original: Announcing GitHub Security Lab: securing the world's code, together Follow my romankh3 github account My other posts:

• How an interview test turned into an open-source library
• Technical interview questions
• How to find a job? Resume Distribution Tips
• professional burnout. How to resist?
• History of success. 20 hours of programming per week, master's degree and personal life