Did you know that most open source projects take over half a year to remediate dependencies that contain known vulnerabilities? Of course, this comes as little surprise, when considering the nature of open source software development: a small team of maintainers is already busy with managing the introduction of new features and updates to the core project, and even keeping on top of all bugs in a side project can already be a time consuming task. We have looked at this situation, and thought about how we can make help maintainers keep on top of things; how to identify and fix such dependencies. What we came up with is Dependabot, your smart robot assistant that will keep an eye on your dependencies for you and keep you on top of things. It can even open pull requests to make it as easy as possible to update to these new versions of your dependencies! Of course, our Dependabot is just a tool - but we are already seeing temendous impact for people using it: instead of taking more than 180 days, Dependabot users get their dependencies patched in just 40.
This is just one example where we have looked at software security, and thought about how we could make it a bit smarter. Let's have a look what else we came up with, and how you can get started securing your software projects today.
You already know the dependency graph from the lab, and you have just learned about Dependabot's impact. So let's show you how to add Dependabot to our current project and make sure that our rocket webpage does not rely on any vulnerable packages. To enable Dependabot, go to the repository settings, select "Code Security and Analysis" and choose from the options presented under the category "Dependabot":
- Dependency Graph: This feature is often relied upon by integrations and features such as the very powerful dependency review action and allows you to e.g. submit your own dependency information that goes beyond what our automations can retrieve, allows you to query the network of transitive dependencies and many other features
- Version Updates: If you enable this feature, Dependabot will automatically start creating Pull Requests to keep you packages up to date. This will not be limited to patching insecure versions, but instead try to generally keep you packages up to date. You can further configure the amount of PRs that dependabot will automatically open at any one time, as to not risk overwhelming you with new PRs for your bigger projects.
- Dependabot Security Updates: At first glance, this feature behaves much like the version updates, since it opens Pull Requests to update dependencies in the current repository. However, there are some noteable differences that make it far more useful to get actively vulnerable dependencies fixed. Pull Requests opened from this feature will contain information about the detected vulnerability and it's exploitability to give developers an instant overview of the context and severity of the detected problem. Also this feature only opens new PRs for fixing know vulnerabilities in your dependencies.
As you can see, this was incredibly easy to set up for your repository. If you have multiple repositories that you want to use these features in, we offer you similar settings inside of your organisation to immediately secure all of your repositories to the same degree. If that's not the definition of a quick win, I don't know what is!
In addition to these settings, you can configure more granular options for your repository, such as further languages used, including subdirecotries for dependency retrieval or the use of a proxy to retrieve the dependency sources at runtime. These settings are configured in the dependabot.yml file, and you can read up on the syntax and capabilities in our docs.
You can get an overview of all detected vulnerable versions in the security tab, when selecting "Dependabot". There you also have the ability to filter down your search by severity of the vulnerability, package ecosystem and many more. To get a more global understanding across your repositories, you can also find this dependency overview in your team, organisation and enterprise layers to aggregate all findings across all repositories that you have access to.
Our dependency submission API allows you to enhance Dependabot's information source, the dependency graph, by further information. This allows to build use cases that communicate company-internal dependencies and relations to Dependabot, but also to easily add support for transitive dependency checking in ecosystems where this would originally not be the case, such as Maven (here is an example for a dependency submission action).
Tokens are a convenient way to authorize with our many different cloud services. They allow easy handling of a single String to authorize as a user and control services and infrastructures. However, this ease of use also makes them an excellent target for malicious actors that want to abuse our infrastructure for less noble causes. By the nature of tokens, it often happens that a developer quickly hard-codes one into a static variable to test out some of their code without having to pass the token along the call stack. Whilst convenient, this can lead to forgetting to remove the token before committing the code, and thus to leaking the secret token on pushing to a repository. The broader group of users which have access to the repo cannot be as stringently controlled or may not be as highly authorized as the original user, and thus the integrity of the token's access may be compromised. Even if the developer notices their mistake and removes the token, simply committing a version without it will not make it disappear: by the nature of git's version history, every changed version will be kept in the repository tree and can read again. This is not a purely theoretical scenario: according to the Verizon Data Breach Investigation Report 2022, a whole 80% of web app related breaches have been contributed to by stolen credentials.
Now that we are all properly afraid, let's actually start working on a solution to this problem! As the world's largest developer platform, we at GitHub have gone and talked to a wide variety of token sources, such as manufacturers, vendors and cloud service providers. Together with these partners, we have actively changed many of these token patterns to become uniquely identifyable. Equipped with the knowledge of the generation patterns of all of these hundreds of different kinds of tokens, we are now able to automatically scan and alert for any leaked tokens across your entire repoistory's commit history. However, we have not stopped at alerting you for these leaked tokens. Instead, we have partnered with the largest token issuers, like AWS, Azure, GCP and many more, to automatically revoke tokens detected in publicly visibile repositories across GitHub. As such, we have effectively eliminated the damage potential of such accidential publications!
To not only have this powerful feature for all your open source projects, let's go ahead and enable for our Rocketdex repository! For that, just go to the repository settings, find "Code Security and Analysis" in the left side menu and go to the category "Secret Scanning". There you can find a simple "Enable" button, by which you can immediately start scanning your repository for any known token formats. It really is that easy!
To review the scan results, just go to the repository's security tab and select "Secret scanning alerts". If you have any findings in there that you do not consider critical, as you have already revoked them or are explicitly sure that you want to keep them visible, you can dismiss them using the green button in the top right corner.
Below, you will discover additional options:
Once you have managed to clean up all detected tokens in your repository, you will want to keep it as clean as it is today. The help you with that, we offer the feature of push protection. Once you activate it, developers will not be able to push commits that have idenftified high-confidence secrets in them. The developer will be presented with a rejected push and a remote message containing a unique URL that they can follow to explicitly override push protection (if they know what they are doing!). Of course, this override will also be logged.
If you have any patterns that we do not take natively into account, such as credit card numbers or email adresses or even just tokens that you issue in your own format, we offer you the ability to define secret patterns across your entire organisation or even enterprise. We will ask for a couple of examples of such a secret during pattern creation, to make sure that your pattern selects what it's supposed to and our dry run feature allows you to make sure you will not be selecting too liberally and overwhelming your security teams with false positive findings.
Since it's that easy to enable secret scanning, and it helps eliminate the number one attack vector, we recommend to activate it across all of your repositories as soon as possible. To do so, you can again find a simple button in the organisation settings - one warning though: do not turn this feature on on a Friday afternoon! We regularly see customers find hundreds of leaked tokens accross their repositories after first starting off secret scanning. As you can imagine, that would make for a fun weekend!
If you go ahead and enable these features on our Rocketdex repository right now, we can make sure no predecessor of ours has accidentially leaked any token into our repo before. As such, we can rest easy when we open Rocketdex up to the public later on! 🚀
You've seen the power of CodeQL and our Code scanning integration in the lab already. Let's look at CodeQL a little deeper: An insufficiently sanitized SQL query parameter can lead to a world of pain for the database admins quite easily, or in the web context we could have overlooked an insecure embedding of external content. For these cases, where a deeper understanding of the functionality and relations in our code is required, we have come up with our static code analysis suite CodeQL. Our system integrates neatly into your Pull Request workflow, and displays you all scan results directly at your fingertips in the GitHub UI. That is a huge difference to the spreadsheets of doom that security teams have sent via email in the past, or the external platforms that developers would have to navigate to to discover their code scanning results.
We have found that making security more pleasant to use for developers actually helps make our code more secure: usually, fix rates for found vulnerabilities max out at ca. 45%, even 3 months after their initial detection. With our approach, 70% of found security vulnerabilities are usually remediated within the lifecycle of a single pull request. Let that sink in!