top of page
Search
Writer's pictureNathan

GitHub Advanced Security

Updated: Feb 10

 

GitHub Advanced Security, or GHAS, is a collection of features and tools to help you maintain secure and high quality code in your GitHub repositories. In this post, I will go over 5 features of GHAS: Dependency Graph, Dependabot, Dependency Review, Code Scanning, and Secret Scanning.


Public repos have access to all 5 of these features, while private/internal repos have access to only some of these features. If you want to use all of these features in private/internal repos then you can purchase GHAS licenses (this requires that you also use GitHub Enterprise). As we go through each feature, I'll make sure to discuss the licensing requirements for each one.


If you have a GitHub Organization or use GitHub Enterprise, then you can control some of these settings in a centralized manner. However, for the purposes of this blog post, I will only talk about these settings on a per-repository basis.



 

Dependency Graph


Dependency Graph identifies the dependencies in your repository. It does this by scanning for well-known manifest files and/or lock files used by many popular languages. Some examples include Rust, PHP, Dot Net, Go, Java, and more.


You can also use the Dependency Graph to export a Software Bill of Materials (SBOM) for your repo.


Dependency Graph is available for all public and private repositories.


How to enable

Repo Settings tab > Code security and analysis > Dependency Graph

  • For public repositories, Dependency Graph is always enabled.

  • For private repositories, Dependency Graph can be enabled or disabled.


How to use/view

Repo Insights tab > Dependency graph > Dependencies tab

  • This will show you all of the dependencies that have been discovered.

  • From here you can also export an SBOM by clicking on the Export SBOM button. This will export a JSON file using the SPDX format.


Important Links


 

Dependabot


Dependabot scans your code to detect insecure dependencies as well as malware (but malware scanning is currently in beta).


Dependabot will compare your dependencies against the GitHub Advisory Database, which is a list of dependencies and their vulnerabilities that is curated by a dedicated team at GitHub. The team will update this list regularly, using sources such as the National Vulnerability Database, the NPM Security Advisories Database, security advisories reported on GitHub, and more.


Dependabot is available for all public and private repositories. However, on private repositories, some advanced features like reachability analysis and auto-triage rules require a GHAS license.


There are 3 features of Dependabot that we will discuss below:


1. Dependabot Alerts


Dependabot Alerts will inform you when it finds insecure dependencies in your Dependency Graph.


How to enable

Repo Settings tab > Code security and analysis > Dependabot alerts

  • Note: Dependency Graph must be enabled first before you can enable Dependabot Alerts.


How to use/view

Repo Security tab > Dependabot.

  • Automated e-mail alerts will also be sent out.


2. Dependabot Security Updates


Dependabot Security Updates will automatically raise Pull Requests to update any of your dependencies that have known vulnerabilities.


How to enable

Repo Settings tab > Code security and analysis > Dependabot security updates

  • Note: Both Dependency Graph and Dependabot Alerts must be enabled first before you can enable Dependabot Security Updates.

  • This will open PRs for every Dependabot Alert. If you need more fine-grained control, then you can leave Dependabot Security Updates disabled, and instead use custom Auto-Triage Rules. But, don't forget that Auto-Triage Rules requires a GHAS license for private/internal repos.

  • You can configure some settings for Dependabot Security Update in the dependabot.yml file (more on this file below).


How to use/view

  • Each Dependabot Security Update will have a matching Dependabot Alert that you can view. If you merge code that contains the fix, then the corresponding Dependabot Alert is marked as resolved.

  • You can also interact with the PRs that are opened.


3. Dependabot Version Updates


Dependabot Version Updates will automatically raise Pull Requests in order to keep your dependencies updated to the latest version. This happens even if there are no known vulnerabilities in the version you currently use.


How to enable

Repo Settings tab > Code security and analysis > Dependabot version updates

  • When you click Enable, you will be guided through the process of creating a new file in your repo called .github/dependabot.yml and the settings in this file will be used to configure Dependabot Version Updates.

  • Dependabot Version Updates support many different types of packages, such as Cargo, Docker, Gradle, NPM, and more. Your repo must also contain a manifest and/or lock file for each of these types of packages.

  • You also have the option of using the evergreen action in a GitHub Workflow. This action will scan your repos, and for any repos that don't have a dependabot.yml file, it can automatically open a PR to create it.


How to use/view

Repo Insights tab > Dependency graph > Dependabot tab.

  • You can also interact with the PRs that are opened.


Important Links


 

Dependency Review


This allows you to catch insecure dependencies in your code at every pull request.


Dependency Review is available for all public repositories. For private repositories, you must have a GHAS license.


How to enable

  • Note: Dependency Graph must be enabled first for Dependency Review to work.

  • If you have Dependency Graph enabled, then Dependency Review is automatically enabled.

    • Dependency Review supports the same list of languages and package managers as Dependency Graph.

  • You also have the option of using the dependency-review-action in a GitHub Workflow. This action will scan your PRs for any changes to dependencies. It will raise an error if your PR is introducing any vulnerabilities or invalid licenses.


How to use/view

  • Go to a Pull Request > Files Changed tab > click the Rich Diff button on a supported manifest or lock file

    • This shows which dependencies were added, removed, or updated.

    • It also shows vulnerability data for these dependencies.

  • Use the GitHub Action as detailed above.


Important Links


 

Code Scanning


Code Scanning analyzes the actual code in your repository to find security vulnerabilities and/or coding errors. This is accomplished by running a supported scanning tool. The tool can run via GitHub Actions, which can be triggered however you like (on PRs, on a schedule, etc). Then, you can use the upload-sarif GitHub Action to upload the results to GitHub. There are other ways to accomplish this without using GitHub Actions, but I won't be going over them in this post.


One of the more popular scanning tools is GitHub's own CodeQL Analysis tool. This tool treats your code as data. In effect, it will read your code and create a database based off of it. Then, you can run CodeQL queries against that database. You have the option of writing your own CodeQL queries, or you can use standard CodeQL queries that have been written by GitHub researchers and community contributors.


Code Scanning is available for all public repositories. For private repositories, you must have a GHAS license.


How to enable

Repo Settings tab > Code security and analysis > Code scanning.

  • Under Code Scanning there will be 2 options. One will help you setup a GitHub Workflow for the previously mentioned CodeQL Analysis tool. The other option will take you to a list of GitHub Starter Workflows that run various different 3rd-party scanning tools.

  • If you chose the CodeQL option, then it will help you create a GitHub Workflow with the following default filename .github/workflows/codeql-analysis.yml.


How to use/view

Once the scanning tool runs and uploads its results, you can view the findings from your Repo's Security tab > Code scanning.


Important Links


 

Secret Scanning


Secret Scanning scans your code for well known types of secrets. It scans the entire Git history on all branches. It also scans issue descriptions and comments.


Secret Scanning is available for all public repositories. For private repositories, you must have a GHAS license.


Secret Scanning automatically scans for secrets that match patterns which are defined by various service providers. While you can create your own custom patterns for Secret Scanning, it is important to note that this requires a GHAS license.


GitHub also notifies the service provider who issued the secret. The service provider can then take any appropriate action like revoking the secret, issuing a new secret or reaching out to you directly depending on the associated risks to you or them.


How to enable

Repo Settings tab > Code security and analysis > Secret scanning

  • You can exclude folders from being scanned by creating a file named .github/secret_scanning.yml with the necessary values.


How to use/view

Repo Security tab > Secret scanning

  • Automated e-mail alerts will also be sent out.


Important Links


Sub-feature: Push Protection


Another feature of Secret Scanning is Push Protection. This prevents secrets from being pushed to your repository.


How to enable

Repo Settings tab > Code security and analysis > under Secret scanning, you will see Push Protection

  • Note: Security Scanning must be enabled first before you can enable Push Protection.


How to use/view

  • To proceed when a push is blocked, contributors must either remove the secret(s) from the push or, if needed, bypass the protection.

    • If you bypass the protection and allow a secret to be pushed, then an alert is created in the repo's Security tab.

    • If you bypass the protection and specify "will fix later" then a notification will also be sent to repository administrators.


 

Conclusion


That was a quick overview of the 5 main features of GitHub Advanced Security. I don't normally write about GitHub related topics, so let me know if you enjoyed this and if you'd like to see more on the subject.


 

Sources


616 views

1 Kommentar


Leandro Lopez
Leandro Lopez
14. Nov. 2023

Great summary! Looking forward to more GitHuh blogs. CodeQL can be a blog on its own.

Gefällt mir
bottom of page