Securing your Workflows
A secure repository is important for many reasons.
- Prevents exposing sensitive data
- Enforces secure development best practices
- Guards against unintended access rights permissions
In this Wiki you will learn how to:
- Opt-in to vulnerability alerts for private repositories
- Note: These security settings are default for public repositories that are not forks.
- Detect and fix vulnerable dependencies when notified by a vulnerability alert
- Follow security best practices to protect sensitive data by using a
.gitignorefile
Security vulnerabilities can cause a range of problems for your project or the people who use it. A vulnerability could affect the confidentiality, integrity, or availability of a project. Sometimes vulnerabilities aren't in the code you write, but in the code your project depends on. Staying up-to-date with the most recent versions is the best line of defense.
This repository has some existing dependencies which will need updating to stay secure.
This repository is a Node.js project utilizing NPM. Because of that, the package.json defines this repository's dependencies. For our time together, we'll be focusing on these JavaScript dependencies. Keep in mind that different programming languages may have different dependency files. You might work with a Gemfile, Gemfile.lock, *.gemspec, requirements.txt, pipfile.lock, or other files.
How can we know these dependencies are secure? It's not always easy, but GitHub is watching out.
You may notice some alerts from GitHub about this repository. You may get an email, or see a yellow bar warning you about the package.json file.
GitHub tracks public vulnerabilities in Ruby gems, NPM, Python, Java, and .Net packages.
GitHub receives a notification of a newly-announced vulnerability. Next, we check for repositories that use the affected version of that dependency. We send security alerts to a set of people within those affected repositories. The owners are contacted by default. But, it's possible to configure specific teams or individuals to get these important notifications.
GitHub never publicly discloses identified vulnerabilities for any repository.
Use GitHub's security alerts to identify a vulnerable NPM dependency.
- Click the Insights tab in your repository
- On the left hand navigation bar, click Dependency graph
- Scroll down until you see a yellow bar highlighting the dependency named
debug, and click on the right hand side of the yellowdebugsection - Take note of the suggested version
Next, we'll go through the GitHub Flow to make some changes.
Note: Before doing this with real world code, make sure that the upgraded package works with your code. Good unit tests and CI (continuous integration) will help you update with confidence.
Now that you know the recommended version, it's time to edit the package.json file. You'll upgrade the package to a non-vulnerable version.
- Within this pull request, go to Files changed
- Click the pencil in the right upper corner to edit the
package.jsonfile - Fix the vulnerability by updating to the latest version of the dependency that you took note of earlier
- Scroll down, and commit your change
From time to time, there are files you don't want Git to check in to GitHub. You may want to ignore files that contain sensitive credentials or information which should not be pushed to your repository. There are a few ways to tell Git which files to ignore.
Git uses a file called .gitignore to decide which files and directories to ignore when committing. Keep files containing sensitive data, like configuration or env files, out of your repositories. This is one way to promote security best practices.
The .gitignore file can, and should, be committed into your repository. By sharing this file and making it part of your code, it will also help others. Other users that contribute to the repository will also avoid committing sensitive data. There are many examples of .gitignore files available for you to use in your own repositories. You can find them in the gitignore repository.
When considering the security of your repository, consider the installed applications. Every app installed on your repository has access to some of your data. Even if it is harmless, it is a good idea to periodically check and prune the list of installed apps and integrations on your repositories. Look for things like active use, or permissions giving more access than necessary.
Follow the guidelines in GitHub's documentation to review authorized OAuth and GitHub Apps.