🎉 Welcome to security strategy essentials!

In this course, you'll learn how to build and host a secure repository in GitHub. A secure repository is important for many reasons, including:

• Prevents exposing sensitive data
• Enforces secure development best practices
• Guards against unintended access rights and permissions

In this course you will learn how to:

• Opt-in to security alerts for private repositories
  • Note: Vulnerability monitoring and security alerts are enabled by default for public repositories that are not forks.
• Fix vulnerable dependencies when notified by a security alert
• Automate security fixes with Dependabot
• Follow security best practices to protect sensitive data by using a .gitignore file
• Remove sensitive data and files committed to a repository

New to GitHub?

For this course, you'll need to be comfortable with the GitHub Flow. If you need a refresher on the GitHub flow, check out the the Introduction to GitHub course.

Step 1: Your project on GitHub Pages

This project is centered around a memory game that will be deployed with GitHub Pages.

⌨️ Activity: Enable GitHub Pages

1. Click the Settings tab in your repository.
2. Scroll down to GitHub Pages and set your default branch as the source, usually main.

Turning on GitHub Pages creates a deployment of your repository. I may take up to a minute to respond as I await the deployment.

Return to this issue for my next comment.

Sometimes I respond too fast for the page to update! If you perform an expected action and don't see a response from me, wait a few seconds. Then refresh the page for your next steps.

Adding a security policy

Just like most repositories have a README.md file to provide instructions on how to contribute to the repository, a SECURITY.md file highlights security related information and instructions on how to handle security related issues and best practices.

This gives collaborators the important security information they need, but it also documents a place where maintainers can think about how they should deal with security disclosures, updates, and general security practices within this repository.

What should I include in my security policy?

Just like a README.md file, it really depends on your repository and the requirements and workflows. Here are a few common topics that are documented in a security policy:

• Supported versions
• How to responsibly report a security vulnerability
• Security related configuration
• Known security gaps and future enhancements

Step 6: Add a SECURITY.md file

1. Navigate to the Security tab
2. Click on Security Policy located in the left sidebar
3. Click the Start Setup button
4. Commit the template security policy to the new branch as selected darzu84-patch-1
5. Commit the new file and create the pull request

Alternatively, you could also create a new file in the root directory called SECURITY.md, write up a quick security policy, and open a pull request.

I'll respond in your pull request with next steps.

Nice work

Congratulations @darzu84, you've completed this course! You can see your published memory game on GitHub Pages with the updated wolverine image.

When considering the security of your repository, consider the installed applications, like me. Every app installed on your repository has access to some of your data. Even if it is harmless (like me), 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.

In summary

We learned how to:

• Enable vulnerable dependency detection for private repositories
• Detect and fix outdated dependencies with security vulnerabilities
• Automate the detection of vulnerable dependencies with Dependabot
• Add a security policy with the a SECURITY.md file
• Remove a commit exposing sensitive data in a pull request
• Keep sensitive files out of your repository by leveraging the use of a .gitignore file
• Remove historical commits exposing sensitive data deep in your repository

What's next?

Want to learn more options to secure your repository? Check out the documentation for security alerts, as well as some GitHub apps for security that might help you keep your code safe.

Keep Learning

Want to keep learning? Feel free to check out our other courses.

I won't respond to this issue, go ahead and close it when finished.

Sensitive data elsewhere in the repository contents

Often sensitive data is buried deep in a repository's history. The process for removing these files and commit data is a bit tricker and more involved.

In our repository's history, there is a reference to a .env file with sensitive information. We've since added a .gitignore to prevent this from happening in the future, but it doesn't modify any previously committed references from the history.

There are a few things we need to think about and take into consideration before we start altering our historical content. But for now, let's start with identifying the commit in question by going through our commit history.

Step 12: Find historical reference to a previous .env file

1. Navigate to the Code tab of the repository and click on the commits link directly under the Code tab
2. Scanning through the commit history, locate the commit that added the .env file
3. Copy and paste the commit SHA ID as a comment in this issue

I'll respond below when you add your comment to this issue.

Automated dependency updates with Dependabot

Manually going through your dependencies for alerts and outdated versions is tedious work. Let's automate this process!

Meet Dependabot

Dependabot alerts you and creates pull requests to keep your dependencies secure and up-to-date!

How does Dependabot work?

Dependabot is the actor for GitHub's automated security updates.

1. GitHub uses the dependency graph and security alerts to scan your repository and notify you of potential dependency updates
2. If any dependencies are out-of-date, Dependabot opens a pull request to update each one
3. If tests pass, and the updated version looks good, you simply merge the pull request

Configuring Dependabot security updates

You can enable automated security updates for any repository that uses security alerts and the dependency graph. You can disable automated security updates for an individual repository or for all repositories owned by your user account or organization. GitHub will automatically enable automated security updates in every repository that uses security alerts and the dependency graph.

Here, we have a security alert on the debug dependency. Clicking on debug will show you the pull request created by Dependabot to update the dependency. We just updated to 2.6.9 but Dependabot noticed we are still outdated.

If you navigate to your closed pull requests, you'll notice Dependabot has done its job and is trying to bump, or update, the version of debug.

Close this issue when done

I'll respond below when you close the issue.

Finding vulnerable dependencies

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, but has the potential to cause integration issues, so GitHub alerts you of the safest next-version of a dependency.

This repository has some existing dependencies which will need updating to stay secure.

GitHub's security alerts for vulnerable dependencies

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 vulnerabilities for a number of supported languages and their associated package ecosystems, including RubyGems, NPM, Python PIP, Maven, and .NET.

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 and it's possible to configure specific teams or individuals to get these important notifications.

GitHub never publicly discloses identified vulnerabilities for any repository.

Step 2: Find this repository's vulnerable dependencies

Use Dependabot alerts to identify a vulnerable NPM dependency.

⌨️ Activity: Identify the suggested version update

1. Click the Security tab in your repository.
2. On the left hand navigation bar, click Dependabot alerts.
3. Follow the instructions to enable Dependabot alerts, if they're not already enabled.
4. Click on the debug alert.
5. Take note of the suggested version.
6. Comment in this issue with the suggested update version.

GitHub Enterprise Server only: This is all possible on GitHub Enterprise through GitHub Connect. It may take up to an hour to refresh the alerts and make them visible. After waiting a reasonable amount of time, if you are still not seeing the yellow bar in the Dependency Graph, you may want to contact your administrator. In the mean time, to move along with the course, we'll give you a hint - the recommended upgraded version is 2.6.9.

Return to this issue for my next comment.