Introduction to GitHub Advanced Security

Prepearing for GitHub Advanced Security certification - Introduction to GitHub Advanced Security

What is GitHub Advanced Security?

GitHub Advanced Security is a powerful suite of tools and features that give you the ability to identify security vulnerabilities in your codebase and environment. These features enable you to secure your code at every step of the software development lifecycle. GitHub Advanced Security also includes implementing security best practices that help create a security-minded culture within your organization.

GitHub Advanced Security focuses on protecting your organization in three primary areas:

Supply chain
Code
Environments

Secure your software supply chain

The concept of a supply chain also applies to what happens during your software development lifecycle. Your workflow produces chunks of code that are then reviewed for quality assurance.

In the context of software development, supply chain also refers to the integration of any third-party or open-sourced software. These components are called dependencies, those need to be actively reviewed for vulnerabilities.

GitHub has automated features that flag these dependency vulnerabilities. These warnings alert specific team members to potential dangers and enable them to act accordingly. That allows you to automate the process that monitors and secures your project dependencies and searches for vulnerabilities.

The security overview

The security overview enables you to identify problematic repositories and understand how your dependencies impact the security of your code. You can also enable security features from the security overview. View, filter, and sort automated security alerts generated for your organization or a specific team. The overview also enables you to filter alerts by their level of risk so you can prioritize your response.

Dependency graphs

Dependency graphs enable you to acquire important insights into your project’s direct and indirect package dependencies and their current state. The graphs display a summary of manifest and lock files in the project’s ecosystem, repository, and packages. You can also see if dependencies are up-to-date and secure.

The dependency graph enables you to monitor any known issues within dependencies that may affect the security of your application. Once you activate the dependency graph, you have access to dependency reviews for both private and public repositories.

The GitHub Advisory Database

This provides information on the state of your dependencies. You can browse or search the GitHub Advisory Database for vulnerabilities in third-party solutions. This is useful because the packages that your project depends on also have other packages that they depend on.

It lists security vulnerabilities mapped to packages tracked by dependency graphs. Security threats appear in the GitHub Advisory Database ranked from low to critical. GitHub automatically updates this list regularly, using authoritative sources such as The National Vulnerability Database and the npm security advisories database.

Dependabot for automated dependency management

Dependabot detects vulnerable dependencies by first examining the project’s manifest file (such as the package.json file used in NodeJS). Next, Dependabot consults the GitHub Advisory Database to see if the detected dependencies have a flag that indicates they are out-of-date or vulnerable.


Find and fix security issues as you code

Code scanning

Code scanning is a static analysis of every git push. The scan happens at the same time as development and checks for common misconfigurations, errors, and vulnerabilities. GitHub alerts authorized developers in the affected repository if the system detects an issue. You will receive alerts about the state of your code and guidance with suggestions on how to fix any errors.

To use code scanning, you first have to enable it for your repository by completing these steps.

  1. Navigate to the Security tab.
  2. Click Code scanning alerts.
  3. Click Set up this workflow for CodeQL Analysis.

GitHub code scanning supports the following languages:

  • C
  • C++
  • C#
  • Java
  • JavaScript
  • TypeScript
  • Python
  • Go

Once you enable code scanning, the default workflow triggers scans:

  • when you push code to a specified branch
  • when a pull request is created for a branch
  • according to a schedule

You can monitor your code scanning workflow from the GitHub user interface. This workflow returns the following results:

  • the name of the file that contains the vulnerability
  • highlighted code lines depicting the actual line on which to find the code in question
  • an explanation of the problem
  • a recommendation on how to fix the problem
  • examples that model the corrected code
  • references to consult

Secret scanning

GitHub scans your entire Git history on all branches present in your GitHub repository. Secret scanning also takes place on a very granular level. You can use a regular expression to define a pattern that the system should use to search for secrets. Here is an example of pattern definition using a regular expression:

github_token_[a-zA-Z0-0]{15}

Features behind the scenes

  • CodeQL - The engine behind code scanning that treats code like data. When code scanning is active on your repository, CodeQL analyzes it without you needing to write any queries. Templates make it easy to output code scanning results on your repository.

  • Third-party tool integration - GitHub is flexible. Integrate optional third-party analysis tools that output SARIF data


Secure your automated workflow environment

Developers often use GitHub Actions or Microsoft Azure to automate or customize software development workflows. In workflows we specicy an environment in where code should execute. These environments are targets, and that target may be a runner that is similar to a VM. For the runner to execute code received by the workflow, it may need to use and environment secret.

GitHub uses protection rules, environment secrets, and wait timers to keep environment access secure and give you control

Feautre Use
Protection rules Administrators can set protection rules that specify reviewers that must approve workflow runs on an environment. The reviewers have read-only access to the repository. So, that they can approve or reject workflow runs without having permission to edit the code.
Environment secrets Systems such as GitHub Actions or Azure can execute a workflow on an environment. Workflow jobs can only access the environment that they reference using the secrets of the environment. A reviewer can approve access for the job if needed.
Wait timers In situations where you want to delay code deployment, you can set a timer that can wait up to 30 days before deployment takes place.

Tips:

  • Do not use structured data as a secret.
  • Register the secrets you use in workflows.
  • Use required reviewers to protect environment secrets. T

Tips to safely use runners

  • Use self-hosted runners only on private repositories.
  • Be cautious when using self-hosted runners on private or internal repositories. Anyone with read access can compromise the runner environment and gain access to secrets.

Licensing considerations

GitHub makes advanced security features such as dependency review, code scanning, and secret scanning automatically available free of charge for public repositories on GitHub.com.

To use GitHub Advanced Security features on private repositories, you’ll need a GitHub Advanced Security license(GHAS). GHAS is available with GitHub Enterprise Cloud or GitHub Enterprise Server. Each license for GHAS specifies a maximum number of accounts or seats.

Create an organizational culture around security

What it means to “shift left.” Develop an understanding of how shifting left helps secure your Software Development Life Cycle (SDLC)

Adopt a security mindset

Shift left

In the SDLC, shifting left means adopting security practices early. When development shifts left, everyone considers security when they contribute to the code. They integrate security into the design phase, making it easier to write secure code and policies.

Faulty security models

This table outlines traits regularly found in faulty organizational security models.

Facet Comment
Scope of team involvement Only a limited number of team members are responsible for security. The persons building the application aren’t the same involved in ensuring security. Security experts are outside of the development workflow.
Prioritization Security reviews and quality control are separate steps at the end of the development stage.
Documentation Security documentation is non-existent. Written standards and guidelines haven’t been established to granularly regulate what type of information enters the codebase and by whom. Subsequently, team members lack a common understanding of expectations and directives.
Platform configuration The development environment isn’t configured to align with and enforce established security guidelines.

The ideal security model

Ideally, everyone is responsible for securing the project within their scope of work. Policies exist for each phase of the operation to ensure code quality. Automation plays a significant role in creating an efficient workflow.

Facet Comment
Scope of team involvement Teams shift left. Each role from design to deployment is concerned with security.
Prioritization Throughout all stages of development, measures are in place to protect assets.
Documentation Standards and guidelines are in writing. Teams know the process to report bugs.
Tooling The development platform enforces standards and keeps code and environments secure.

Security policies

strong security culture needs documentation to define the persons or roles that can perform specific actions within a repository or branch. In GitHub, these documents are policies. Policies may require a code review before merging. They ensure that the code passes certain status checks. In GitHub, you store policy details in your repository, in the SECURITY.mdfile. This file will also include instructions on reporting any bugs or vulnerabilities found in the project.

Enforce policies

GitHub Advanced Security includes compliance and policy management features. Policies are organizational measures.


Responding to security alerts

Evaluate security alerts

  • Teams cannot always avoid errors, quick action reduces risks
  • You can reduce costs, retain customers, and protect your brand reputation when you avoid sensitive data leaks by quickly responding to security alert

Triage security alerts

When the system identifies a problem, it notifies your team with alerts highlighting the issue. This helps you to quickly identify the issue. Once GitHub flags a vulnerability in your codebase, analyzing the flaw is the next step.

In the image above, you control the code scanning process. If the scan has misunderstood your intent, you can dismiss the alert identifying a reason for the dismissal. Indicate if the scan has highlighted a false positive, code used in tests, or an irrelevant alert.

You can also interact with scanning alerts through pull requests. You can see details related to the alert if you have write permission to the repository. A check must pass before you can merge the pull request.

Manage security alerts

GitHub provides you with an overview of your repository alerts along with the triage functionality. This summary facilitates the prioritization of security alerts. Navigate to the security tab of your repository and select Code scanning alerts.

GitHub can also suggest fixes for errors in your code.

Use security advisories

Think of security advisories as a private forum that code maintainers use to discuss bugs or vulnerabilities found within their projects. When you use security advisories, you ensure that knowledge of any error or bug is not exposed to the public before you can fix it. After you resolve the problem, the security advisory is published back into the GitHub Advisory Database so that external parties affected by it can take any necessary steps.