adding labs

Author: joshjohanning

_labs/README.md

@@ -0,0 +1,7 @@
+# Labs 🔬 👩‍🔬 🧪
+
+1. [Lab 1 - GitHub Advanced Security Feature Introduction](./lab1.md)
+2. [Lab 2 - Reviewing and Managing Security Alerts](./lab2.md)
+3. [Lab 3 - Hands-on with Code Scanning (blocking vulnerable code from entering codebase and Copilot Autofix)](./lab3.md)
+4. [Lab 4 - Hands-on with Dependency Review (blocking vulnerable dependencies from entering codebase)](./lab4.md)
+5. [Lab 5 - Hands-on with Secret Scanning (secret scanning with push protections)](./lab5.md)

_labs/lab1.md

@@ -0,0 +1,55 @@
+# Lab 1 - GitHub Advanced Security Feature Introduction
+
+Welcome! In this lab, you will be introduced to GitHub Advanced Security (GHAS) and its features. You will use the Juice Shop sample repository to enable the GHAS features, manage alerts, and learn how GitHub Advanced Security can keep vulnerabilities out of your code in the first place.
+
+## Exercise 1: Create the repository
+
+We need to provision our working copy of the repository in order to begin the labs!
+
+1. Navigate to URL: [https://github.com/joshjohanning-org/juice-shop-ghas-workshop](https://github.com/joshjohanning-org/juice-shop-ghas-workshop) TODO: update URL with universe repo
+2. Click on the **Use this template ▾** button.
+3. Make sure you have the **githubuniverseworkshops** organization selected.
+4. Name the repository **YOUR_USERNAME-juice-shop-ghas-workshop**.
+5. ❗️❗️ Make sure to check the box to **Include all branches**. The other branches are required in order to complete the workshop. ❗️❗️
+6. Click the green **Create repository** button to create the repository
+
+Once the repository is created, you will be automatically redirected to it.  Continue on to Exercise 2.
+
+## Exercise 2: Enabling the security settings
+
+In this exercise, you will be guided through the process of enabling the remaining GHAS features. Then you will be shown how to use the features to secure your code.
+
+### Exercise 2.1: Enable Dependabot
+
+1. We first want to turn on the security settings for the repository. Navigate to the **Settings** tab (the icon of the gear) in the repo.
+2. Click on the  **Code security & analysis** section.
+3. Although Dependabot isn't part of the GitHub Advanced Security product suite, it is still an important tool to discuss from an overall security posture. To enable Dependabot, we first have to enable the Dependency Graph. If it's not already enabled, enable the **Dependency Graph**. This allows Dependabot to ingest your package manifest files.
+4. Click the **Enable** button next to the **Dependabot alerts** setting. This feature will create alerts for vulnerable dependencies found in your repository.
+5. Optionally, enable Dependabot security updates. This will automatically create pull requests to update your vulnerable dependencies (if there is a non-vulnerable version to upgrade to). Note: there is a [maximum number of pull requests that this feature will create (10)](https://docs.github.com/en/enterprise-cloud@latest/code-security/dependabot/working-with-dependabot/troubleshooting-dependabot-errors#dependabot-cannot-open-any-more-pull-requests).
+
+### Exercise 2.2: Enable Code Scanning
+
+1. Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Code security & analysis** settings page.
+2. Underneath the GitHub Advanced Security | Code Scanning heading, click the **Set up** button in the **CodeQL analysis** row.
+3. There are two options: **Default** and **Advanced**. For this lab, we will use the **Default** setup which creates a workflow behind the scenes (i.e. you will not see it committed to the repo). You can use the Advanced option to manage your code scanning workflow as a GitHub Actions workflow YAML file committed to the repo.
+4. Select the **Default** option, review the settings. By default, we will scan the JavaScript code, use the default CodeQL queries (for highest precision), and scan the default branch on push, pull request, and on a weekly schedule.
+5. Click the **Enable CodeQL** button to save the settings and enable Code Scanning.
+6. Ensure that **Copilot Autofix** is enabled (in the Code Scanning --> Tools section).
+7. Optionally, configure the **Check runs failure threshold** - by default, a pull request will be blocked if there are any high or higher security alerts.
+
+> [!NOTE]  
+> You don't need a Copilot license in order to use the Copilot features with GitHub Advanced Security. However, Copilot can certainly be helpful in resolving issues in your IDE by using Copilot chat to explain the vulnerability and how to fix it.
+
+### Exercise 2.3: Enable Secret Scanning
+
+1. If it's not already enabled, click on the **Enable** button to enable Secret Scanning.
+2. Check the box to **Use AI detection to find additional secrets (beta)**. This feature uses AI to find secrets/passwords that may be in your code that don't correspond to a known provider pattern.
+3. Click the **Enable** button next to the **Validity checks** setting. This feature checks if the secret is still valid for [specific partners](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/introduction/supported-secret-scanning-patterns#high-confidence-patterns), such as AWS and, of course, GitHub. As an example, you can use this feature to check if a GitHub personal access token found in the repo is still valid and needs to be revoked.
+4. Click the **Enable** button next to the **Non-provider patterns** setting. This scans for patterns that don't correspond to partners but still have a common syntax, such as a MySQL or MongoDB connection string.
+5. Click the **Enable** button next to the "Push protection" setting. This feature will block pushes that contain high-precision secrets. You can use this [chart](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/introduction/supported-secret-scanning-patterns#supported-secrets) to determine which types of secrets would be blocked with secret scanning push protection enabled.
+6. Optionally, configure **Who can bypass push protection for secret scanning**. To not potentially interrupt developers' workflows, by default anyone with write access to the repository can manually bypass a blocked push that contains secrets (administrators will be notified of this, and it is also captured in the audit logs). You can change this to only allow select users/teams (or no one) to bypass secret scanning push protection.
+7. Note that you can define your own **Custom patterns** from this page to scan for secrets that don't correspond to a known provider pattern.
+
+## Summary
+
+Congrats! You have successfully enabled all of the security settings on your repository. In the next lab, we will review the alerts that have been created and how to manage them.

_labs/lab2.md

@@ -0,0 +1,77 @@
+# Lab 2 - Reviewing and Managing Security Alerts
+
+Now that we have all of the security feature enabled, let's review the security alerts that have been created and how to manage them.
+
+## Exercise 1: Reviewing Dependabot alerts
+
+1. Click the **Security** tab in the repo. This is where you can see and manage all of the security alerts for the repo.
+2. Click **Dependabot** under the **Vulnerability alerts** heading.
+3. You should see a number of Dependabot alerts with various severities. Click on one of the alerts to see more information about it.
+4. When reviewing a Dependabot alert, you can see the following information (see if you can locate this information in the alert you opened):
+   - The severity of the alert
+   - The package name and version that is vulnerable
+   - The severity of the vulnerability
+   - The CVE number
+   - The affected versions of the package
+   - The fixed version (if there is one - sometimes there isn't a non-vulnerable version to upgrade to)
+   - The dependency path (what file contains the vulnerable dependency)
+   - The alert description
+   - The alert recommendation (to upgrade or use a different package)
+   - The alert timeline (for example, it should show that Dependabot just recently opened the alert. Once you close an alert, it will show who and when closed it here too).
+5. You can manually close an alert by clicking on the **Dismiss alert** button in the upper right hand corner. It's not recommended to close alerts manually, but there may be times where this is helpful (for example, the code that contains the alert is not used).
+    - If you resolve an alert by upgrading to a non-vulnerable version, Dependabot will automatically close the alert!
+6. If there is a non-vulnerable package version to update to, you will see a **Create Dependabot security update** button to queue Dependabot to attempt to create a pull request automatically to upgrade the vulnerable dependency. With this feature, assuming your build and tests pass, you can merge the pull request to close the alert.
+    - TODO: Do we want to have them actually do this? or do you think showing/telling them about it is good. enough. Right now I think showing/telling is good enough. We can always add steps to have them do it if we need to lengthen the labs
+7. Go **back** to the prior page and let's take a look at the list of Dependabot alerts again.
+8. We can filter by **Package**, **Ecosystem**, **Manifest**, and **Severity**. For example, sometimes upgrading just one package can resolve multiple security alerts, so this can be a great way to prioritize fixes.
+9. If you put your cursor in the search box (should have `is:open` by default), there are additional filter options. Some of the common filter options are **scope** (runtime or development) and **has** (for example, `has:patch`).
+10. Update the search query to `is:open has:patch`. This will filter out all of the alerts that don't have a patch available and only show alerts where there is a non-vulnerable version to upgrade to.
+
+## Exercise 2: Reviewing Code Scanning alerts
+
+1. Under the **Security** tab in the repo, click on **Code scanning** to review the code scanning alerts.
+2. We should have a number of alerts. If you don't see any alerts yet, skip ahead to the next exercise and come back to this one. More than likely, the code scanning workflow hasn't finished yet (it takes between 2-5 minutes to run).
+3. If there are code scanning alerts, spend a few moments reviewing them. We can **filter/sort** by severity, tool, language, and a few other options, just like with Dependabot alerts.
+4. A common search/filter to use is using **Autofilter** to filter out the alerts with a **test** tag (code scanning violations found in test files). This can help you focus on the alerts that are more likely to be real vulnerabilities.
+5. To use the autofilter filter, paste this into the search box: `is:open branch:main autofilter:true` (or type/select it by hand).
+6. Scroll down and let's click on one of the SQL injection alerts. These can be found by searching for the title **Database query built from user-controlled sources**.
+7. After clicking into one of the alerts, we should notice a few things:
+   - The severity of the alert
+   - The CWE(s) of the alert with a hyperlink
+   - The tool that found the alert (CodeQL)
+   - The alert title
+   - The alert description
+   - More information on the alert, such as a recommendation and example of the vulnerability (and often additional resources to reference)
+   - The alert file path, line number, and code snippet
+   - The affected branch
+8. CodeQL works by scanning the sources and sinks; as an example, the source is the user input and the sink is the database query. Click on the **Show paths** link to review the vulnerability from the source to the sink. This can help you understand the vulnerability and track it throughout the application to better understand how to fix it.
+9. Oftentimes, there will be a lot of information to help understand the vulnerability and how to fix it. There should be a **Show more** expandable section that will show more information about the type of vulnerability you're working with.
+10. In the upper right-hand corner, there is a **Generate fix** button to use Copilot to generate a fix for the vulnerability. Click it! This is a great way to learn how to fix the vulnerability and to see how to fix it in the context of your code.
+11. It will take a little time to generate a suggestion.
+12. If you're happy with the suggestion, click the **Create PR with fix** button. This will create a pull request with the fix for the vulnerability. In a real world example, assuming your build and tests pass, you would merge the PR.
+13. The nice thing with code scanning alerts (just like Dependabot alerts) is that once you merge the code that resolves an alert, the alert will be automatically closed. This is because the alert is no longer present in the code. After merging the code into the default branch, a code scan will run and once it finishes, the alert will be closed. You can test this by merging the pull request we just created!
+14. If you did merge the pull request, check back on the list of code scanning alerts under the **Security** tab in the repo. Once the code scan finishes running, you should see one (1) **Closed** alert listed.
+    - #TODO: May have to flesh this out more (see comment: https://github.com/joshjohanning-org/universe2024-ghas-workshop/pull/1/files#r1760207693)
+
+> [!NOTE]  
+> You don't need a Copilot license in order to use the Copilot features with GitHub Advanced Security. However, Copilot can certainly be helpful in resolving issues in your IDE and Copilot chat can explain the vulnerability and how to fix it.
+
+## Exercise 3: Reviewing Secret Scanning alerts
+
+1. Under the **Security** tab in the repo, click on the **Secret scanning** --> **high confidence** option. This will show all of the high confidence secret scanning alerts.
+2. You should see a number of alerts. For example, there should be a **GitHub Personal Access token alert**. Click it.
+3. This alert shows where in the code the secret was discovered (if there were multiple locations, it would list them all).
+4. If a secret is found in the code, we would want to revoke manually in the designated service. It's recommended to revoke the secret instead of rewriting history because the secret was exposed and you don't know who may have seen it. If you rewrite history, the secret will still be valid and could be used by an attacker. Also, rewriting history modifies commit hashes and can make traceability more difficult.
+5. You can click on **Verify secret**. It will say it's not currently valid on github.com, but that doesn't mean it doesn't come from another GitHub instance (such as GitHub Enterprise Server).
+6. Go back to list of secret scanning alerts. Click on the **Google API key** alert.
+7. Click on **Verify secret** again. This time, it should say **secret inactive**. This is a good candidate to **Close as** --> **Revoked** (click the **Close as** button in the upper right to do so). Do this.
+8. Unlike Dependabot alerts and Code Scanning alerts, secret scanning alerts are not automatically closed when the secret is removed from the code - whether by a new commit or by rewriting history. This is because the secret was exposed and you don't know who may have seen it. So, you have to manually close the alert once you revoke the token.
+9. Navigate back to the **high confidence** secret alerts list.
+10. We can click **1 Closed** to see the alert we just closed.
+11. Click on the **Other** secret scanning alerts option. This will show all of the alerts that are not high confidence, such as generic passwords, keys, and things such as HTTP bearer authentication header tokens found in the code.
+12. Let's click into one of the **Password** alerts.
+13. Just like high confidence alerts, it shows where the secret was found in the code. The secret was found with AI, so it may or may not be a real secret or password. If it's not, we can close it manually and mark it as a false positive.
+
+## Summary
+
+Well done! You've learned how to review and triage alerts from Dependabot, code scanning, and secret scanning. And you even saw how you can use Copilot to automatically fix a code scanning alert. In the next lab, we are going to to get hands-on with code scanning, repository rulesets, and Copilot, to see how we can both prevent and fix vulnerabilities in our code base.