Maintain a secure repository by using GitHub best practices

By Madis Kõosaar
github certification administration security

Prepearing for GitHub Administration certification - Maintain a secure repository by using GitHub best practices

Table of Contents

How to maintain a secure GitHub repository

The importance of a secure development strategy

  • There is a general knowledge problem
  • Code must be created correctly and securely

  • Applications must comply with rules and regulations

  • Shift Left early in the development lifecycle.
  • Shifing left is about making all of security more developer-centric, and giving developers security feedback where they are.

Communicate a security policy with SECURITY.md

  • Developers looking to report or address security issues look for a SECURITY.md file in the root of a repository in order to responsibly disclose their concerns
  • To give people instructions for reporting security vulnerabilities in your project, you can add a SECURITY.md file to your repository’s root, docs, or .github folder.
  • Read more from here

GitHub Security Advisories

  • Allow repository maintainers to privately discuss and fix a security vulnerability in a project
  • repository maintainers can publish the security advisory to publicly disclose the security vulnerability to the community
  • By publishing security advisories, repository maintainers make it easier for their community to update package dependencies and research the impact of the security vulnerabilities
  • GitHub stores the published advisories in the Common Vulnerabilities and Exposures (CVE) list

Creating a default community health file

  • such as:
    • CONTRIBUTING.md
    • CODE_OF_CONDUCT.md

Keep sensitive files out of your repository with .gitignore

  • .gitignore is a file that contains a list of files and folders that should be ignored by Git

Remove sensitive data from a repository

  • It should be assumed that any data committed to GitHub at any point has been compromised. Simply overwriting a commit isn’t enough to ensure the data will not be accessible in the future. For the complete guide to removing sensitive data from GitHub, see Removing sensitive data from a repository.

  • Tools that can be used:
    • BFG Repo-Cleaner
    • git filter-repo
    • Warning: If you run git filter-repo after stashing changes, you won’t be able to retrieve your changes with other stash commands. Before running git filter-repo, we recommend unstashing any changes you’ve made. To unstash the last set of changes you’ve stashed, run git stash show -p git apply -R
  • Fully removing the data from GitHub:
    • Contact GitHub Support, asking them to remove cached views and references to the sensitive data in pull requests on GitHub.
    • Tell your collaborators to rebase, not merge, any branches they created off of your old (tainted) repository history
    • After some time has passed and you’re confident that the BFG tool / git filter-repo had no unintended side effects, you can force all objects in your local repository to be dereferenced and garbage collected with the following commands (using Git 1.8.5 or newer):
  $ git for-each-ref --format="delete %(refname)" refs/original | git update-ref --stdin
  $ git reflog expire --expire=now --all
  $ git gc --prune=now
   Counting objects: 2437, done.
   Delta compression using up to 4 threads.
   Compressing objects: 100% (1378/1378), done.
   Writing objects: 100% (2437/2437), done.
   Total 2437 (delta 1461), reused 1802 (delta 1048)

Branch protection rules

  • can create a branch protection rule to enforce certain workflows for one or more branches
    • requiring an approving review
    • passing status checks for all pull requests merged into the protected branch

The workflows that protect the branch can be leveraged to:

  • Run a build to verify the code changes can be build
  • Run a linter to check for typos and conformation to the internal coding conventions
  • Run automated tests to check for any behavior changes of the code
  • Etc.

Add a CODEOWNERS file

  • To use a CODEOWNERS file, create a new file called CODEOWNERS in the root, docs/, or .github/ directory of the repository, in the branch where you’d like to add the code owners.
  • CODEOWNERS files must be under 3 MB in size.
  • A CODEOWNERS file over this limit will not be loaded
  • To reduce the size of your CODEOWNERS file, consider using wildcard patterns to consolidate multiple entries into a single entry.
  • Can assign individual team members or entire teams as code owners to paths in your repository.
  • code owners are then required for pull request reviews on any changes to files in a path that they are configured for.
* Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

*  Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocatt git

Automated Security

Detect and fix outdated dependencies with security vulnerabilities

Repository dependency graphs

  • One default feature every repository enjoys are dependency graphs
  • GitHub scans common package manifests, such as package.json, requirements.txt, and others

Automated dependency alerts

  • GitHub provides automated dependency alerts for security vulnerabilities using Security Advisories

Automated dependency updates with Dependabot

  • Scans for dependency alerts and creates pull requests so that a contributor can validate the update and merge the request.

Automated code scannin

  • Can use code scanning to detect and fix security vulnerabilities
  • Code scanning has several benefits;
    • you can use it to find, triage, and prioritize fixes for existing problems or potential security vulnerabilities.
    • useful to help prevent developers from introducing any new security problems into the code.
  • Another advantage to code scanning is its ability to use CodeQL

Secret scanning

  • Looks for known secrets or credentials committed within the repository
  • By default, secret scanning occurs on public repositories and can be enabled on private repositories by repository administrators or organization owners.