From c6ced86764d7608124a587cf78cdebd9665fb641 Mon Sep 17 00:00:00 2001 From: Tiago Pascoal Date: Fri, 25 Apr 2025 13:47:55 +0100 Subject: [PATCH 1/5] Fix org name --- README.md | 2 - _labs/lab1.md | 64 +++++++++++++++++--------------- _labs/lab2.md | 97 ++++++++++++++++++++++++------------------------ _labs/lab3.md | 67 ++++++++++++++++----------------- _labs/lab4.md | 61 +++++++++++++++--------------- _labs/lab5.md | 29 +++++++-------- _labs/lab6.md | 23 +++++------- _labs/lab7-ec.md | 1 - _labs/lab8-ec.md | 1 - 9 files changed, 170 insertions(+), 175 deletions(-) diff --git a/README.md b/README.md index 809ce80..afcd3bd 100644 --- a/README.md +++ b/README.md @@ -16,8 +16,6 @@ - **What you'll learn**: Here at GitHub, we like to say that "found means fixed." That's because when issues are found they can more easily be fixed. In this workshop you'll dive into a repository filled with security alerts and begin to remediate them using GitHub Advanced Security (GHAS) and Dependabot, effectively maintaining code integrity. You'll also encounter and resolve a few security issues using Copilot Autofix. The end goal? To learn and develop strategies to motivate your developers to turn reactive fixes into proactive security habits. -See [requirements](_labs/requirements.md) to see what is needed to run this lab. - --- ## Workshop Labs diff --git a/_labs/lab1.md b/_labs/lab1.md index 58591c5..ff706a5 100644 --- a/_labs/lab1.md +++ b/_labs/lab1.md @@ -12,14 +12,21 @@ Welcome! In this lab, you will be introduced to GitHub Advanced Security (GHAS) ## Creating the repository -In this exercise, you will create a repository with code from which you can work to test the GHAS capabilities. - -1. Navigate to `https://github.com/github-samples/securing-your-code` in your browser. -2. Click the green **Use this template** button in the upper right corner of the page. -3. Create a new repository in our organization by choosing Owner in the dropdown (either personal or organization). -4. Give the repository a unique name **my-ghas-workshop-repo-**. Click the green link below for inspiration on a unique repo name 😉. -5. Make sure you switch it to visibility to **Public** if using a personal account if using an organization check the notes in [requirements](./requirements.md) for visibility. Now click **Create repository**. -6. The page will refresh after a few seconds where you can now see the code we will be working with. +In this exercise, you will create a repository with code from which you can work to test the GHAS capabilities. + +> [!NOTE] +> For your convenience we have already filled in your username and password in the instructions, but you can always see them on the resources tab. + +1. [] Navigate to +++https://github.com/enterprises/skillable-events/sso+++ +2. [] Click on the green **Continue** button when the **Single sign-on to Skillable Events** page appears +3. [] Enter the your username +++@lab.VirtualMachine(Win11-Pro-Base-VM).Username+++ +4. [] Enter your password +++@lab.VirtualMachine(Win11-Pro-Base-VM).Password+++ +5. [] Navigate to +++https://github.com/github-samples/securing-your-code+++ in your browser. +6. [] Click the green **Use this template** button in the upper right corner of the page. +7. [] Create a new repository in our organization by choosing **Microsoft-Build-2025** in the owner dropdown. +8. [] Give the repository a unique name **lab303-**. Click the green link below for inspiration on a unique repo name 😉. +9. [] Make sure you switch it to visibility **Private** so your work does not conflict with other attendees! Now click **Create repository**. +10. [] The page will refresh after a few seconds where you can now see the code we will be working with. ## Enabling the security settings @@ -31,12 +38,11 @@ Although Dependabot isn't part of the GitHub Advanced Security product suite, it Dependabot and Dependency Graph should already be turned on for your repository. If not, follow the steps below. -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 **Advanced Security** section. -3. Ensure the Dependency Graph is enabled (scroll down to **Code Security** group). This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependency Graph** setting. To enable Dependabot, we first have to enable the Dependency Graph. This allows Dependabot to ingest your package manifest files. - - Note: If using a public repository you cannot disable dependency graph. -4. Ensure the Dependabot alerts are enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependabot alerts** setting. This feature will create alerts for vulnerable dependencies found in your repository. -5. Click the **Enable** button next to the **Dependabot security updates** setting. +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 **Advanced Security** section. +3. [] Ensure the Dependency Graph is enabled (scroll down to **Code Security** group). This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependency Graph** setting. To enable Dependabot, we first have to enable the Dependency Graph. This allows Dependabot to ingest your package manifest files. +4. [] Ensure the Dependabot alerts are enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependabot alerts** setting. This feature will create alerts for vulnerable dependencies found in your repository. +5. [] Click the **Enable** button next to the **Dependabot security updates** setting. - 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). @@ -49,12 +55,12 @@ Once you are done turning on Dependabot features, the next thing we will need to ### Exercise 2: Enable Code Security -1. Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Advanced Security** settings page. -2. Ensure **Code Security** is enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable **Code Security**. -3. Underneath the **Code Security | Tools** heading, click the **Set up** button in the **CodeQL analysis** row. +1. [] Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Advanced Security** settings page. +2. [] Ensure **Code Security** is enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable **Code Security**. +3. [] Underneath the **Code Security | Tools** heading, click the **Set up** button in the **CodeQL analysis** row. > [!NOTE] -> If you do not see the **Code security** heading you have likely not created your repo with Public visibility if using a personal account or in a Organization which has GitHub Advanced Security licenses. Go back to the beginning of this lab and ensure you choose the right owner or repository visibility. +> If you do not see the **Code scanning** heading on the **Code security** page after enabling **Code Security** - you have likely not created your repo in the proper Organization. Go back to the beginning of this lab and ensure you choose **Microsoft-Build-2025** value from the dropdown as the new repository **Owner** when you choose **Use this template**. 4. There are two options: **Default** and **Advanced**. Select the **Default** option and review the settings. - For this lab, we will use the **Default** setup, which creates a managed Actions workflow (i.e. you will not see a codeql.yaml file committed to the repo). The Advanced option can be used to manage your code scanning workflow as a GitHub Actions workflow YAML file committed to the repo. The **Default** option is a great option to get started quickly to enable code scanning in a repository without needing to commit any additional code. @@ -65,14 +71,14 @@ Once you are done turning on Dependabot features, the next thing we will need to ![image](images/lab-1-2-1.png) -5. Click the **Enable CodeQL** button to save the settings and enable Code Scanning. +5. [] Click the **Enable CodeQL** button to save the settings and enable Code Scanning.
![image](images/lab-1-2-2.png)
-6. Ensure that **Copilot Autofix** slider is enabled as **On |** (in the **Code Security --> Tools** section). +6. [] Ensure that **Copilot Autofix** slider is enabled as **On |** (in the **Code Security --> Tools** section).
@@ -82,19 +88,19 @@ Once you are done turning on Dependabot features, the next thing we will need to > [!NOTE] > You do not 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. -7. Optionally, configure the **Check runs failure threshold** (in **Protection Rules** section) - by default, a pull request will be blocked if there are any high or higher security alerts _once_ you configure a branch ruleset. +7. [] Optionally, configure the **Check runs failure threshold** (in **Protection Rules** section) - by default, a pull request will be blocked if there are any high or higher security alerts _once_ you configure a branch ruleset. ### Exercise 3: Enable Secret Protection -1. Ensure that Secret Protection is enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable **Secret Scanning**. -2. 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 Azure, 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. -3. Click the **Enable** button next to the **Non-provider patterns** setting. This scans for patterns that do not correspond to partners but still have a common syntax, such as a MySQL or MongoDB connection string. -4. Check the box to **Scan for generic passwords**. This feature uses AI to find secrets/passwords that may be in your code that do not correspond to a known provider pattern. -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**. +1. [] Ensure that Secret Protection is enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable **Secret Scanning**. +2. [] 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 Azure, 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. +3. [] Click the **Enable** button next to the **Non-provider patterns** setting. This scans for patterns that do not correspond to partners but still have a common syntax, such as a MySQL or MongoDB connection string. +4. [] Check the box to **Scan for generic passwords**. This feature uses AI to find secrets/passwords that may be in your code that do not correspond to a known provider pattern. +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**. - By default, as to not interrupt developers' workflows, 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). - In Private and internal repositories in organizations using GitHub Enterprise Cloud with GitHub Advanced Security enabled, you can change this to only allow select roles/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 do not correspond to a known provider pattern. +7. [] Note that you can define your own **Custom patterns** from this page to scan for secrets that do not correspond to a known provider pattern.
@@ -105,4 +111,4 @@ Once you are done turning on Dependabot features, the next thing we will need to 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. -➡️ Head to the next [lab](lab2.md). + diff --git a/_labs/lab2.md b/_labs/lab2.md index aaa8d8f..dbd3077 100644 --- a/_labs/lab2.md +++ b/_labs/lab2.md @@ -4,22 +4,22 @@ Now that we have all of the security feature enabled, let's review the security ## 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. +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.
![alt text](image.png)
-3. You should see a number of Dependabot alerts with various severities. Click on one of the alerts to see more information about it. +3. [] You should see a number of Dependabot alerts with various severities. Click on one of the alerts to see more information about it.
![image](images/lab-2-1-2.png)
-4. When reviewing a Dependabot alert, you can see the following information (see if you can locate this information in the alert you opened): +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 @@ -38,21 +38,21 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-1-3.png)
-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). +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. Go back a page and return to the list of Dependabot alerts. -7. Click on the **Command Injection in marsdb** alert. You will note that this alert does not have a non-vulnerable version to upgrade to. +6. [] Go back a page and return to the list of Dependabot alerts. +7. [] Click on the **Command Injection in marsdb** alert. You will note that this alert does not have a non-vulnerable version to upgrade to. - If this were a real application, you would need to evaluate your risk to keeping this package in place, migrate to a different package, or write the functionality in-house. -8. Go back a page and return to the list of Dependabot alerts. -9. Click on the **Verification Bypass in jsonwebtoken** alert. This alert *does* have a non-vulnerable version to upgrade to. -10. If Dependabot has finished running, you should see a **Review security update** button attempt. If you see it, click it. +8. [] Go back a page and return to the list of Dependabot alerts. +9. [] Click on the **Verification Bypass in jsonwebtoken** alert. This alert *does* have a non-vulnerable version to upgrade to. +10. [] If Dependabot has finished running, you should see a **Review security update** button attempt. If you see it, click it. - If you don't see it, skip to the next step. You can return to this step later after Dependabot finishes its initial run. - Review the PR that Dependabot created by clicking on the **Review security update**. - In the **Files changed** tab, you should see it upgrading the **package.json** file. - Back on the **Conversation** tab, you can see that the compatibility score is pretty low - this is an indication that you would likely going to have to make code changes to accept this PR. - Dependabot security updates is a great feature because assuming your build and tests pass, you can merge the PR and automatically close the alert. -11. Navigate **back** to the **Dependabot** alerts page and let's take a look at the list of Dependabot alerts one final time. -12. 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. +11. [] Navigate **back** to the **Dependabot** alerts page and let's take a look at the list of Dependabot alerts one final time. +12. [] 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. - Note that if you click the package dropdown, one package has 6 alerts associated with it (all linked to the same PR). - This is a great place to start if you are looking to start prioritizing which alerts to fix first. - Reviewing the **Critical** and **High** security alerts is another great place to start when prioritizing. @@ -62,8 +62,8 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-1-4.png)
-13. 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`). -14. 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. +13. [] 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`). +14. [] 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.
@@ -71,16 +71,16 @@ Now that we have all of the security feature enabled, let's review the security
-15. Auto-triage your alerts allows you control over how Dependabot opens pull requests, ignores false positives and snoozes alerts. Navigate to the **Settings** tab (the icon of the gear) in the repo and then **Advanced Security** left sidecar, scroll to **Dependabot**, then find **Dependabot rules** underneath **Dependabot alerts**. +15. [] Auto-triage your alerts allows you control over how Dependabot opens pull requests, ignores false positives and snoozes alerts. Navigate to the **Settings** tab (the icon of the gear) in the repo and then **Advanced Security** left sidecar, scroll to **Dependabot**, then find **Dependabot rules** underneath **Dependabot alerts**. -16. Add a rule to snooze any alerts that do not have a fix available. Choose the "gear" icon and select the **New rule** button. Name the rule `Snooze when no patch available`, add a target metadata for all npm packages: `ecosystem:npm` and ensure the **Dismiss Alerts - Until patch is available** is selected. Next, select **Create rule**. +16. [] Add a rule to snooze any alerts that do not have a fix available. Choose the "gear" icon and select the **New rule** button. Name the rule `Snooze when no patch available`, add a target metadata for all npm packages: `ecosystem:npm` and ensure the **Dismiss Alerts - Until patch is available** is selected. Next, select **Create rule**.
![image](images/lab-2-1-6.png)
-17. Navigating back to the **Security** tab / **Dependabot** under the **Vulnerability alerts** heading. You will see **1 Closed** heading. Select this to find your alert **Command Injection in marsdb** without any fix has now been **Dismissed** as **auto-dismissed**. The audit log will note **Repository rule created and Snooze when no patch available was applied** +17. [] Navigating back to the **Security** tab / **Dependabot** under the **Vulnerability alerts** heading. You will see **1 Closed** heading. Select this to find your alert **Command Injection in marsdb** without any fix has now been **Dismissed** as **auto-dismissed**. The audit log will note **Repository rule created and Snooze when no patch available was applied**
@@ -89,25 +89,25 @@ Now that we have all of the security feature enabled, let's review the security ## 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). +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).
![image](images/lab-2-2-1.png)
-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 **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). +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 **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).
![image](images/lab-2-2-2.png)
-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: +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) @@ -122,18 +122,18 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-2-3.png)
-8. Click on the **Show paths** link to review the vulnerability from the source to the sink. +8. [] Click on the **Show paths** link to review the vulnerability from the source to the sink. - CodeQL works by scanning the sources and sinks; as an example, the source is the user input and the sink is the database query - This can help you understand the vulnerability and track it throughout the application to better understand how to fix it. -9. Click on the **Show more** expandable section near the bottom of the page. +9. [] Click on the **Show more** expandable section near the bottom of the page. - This will show more information about the type of code vulnerability you're working with, how to avoid it, and how to fix it. -10. Right below the alert title on the right hand side, there is a **Generate fix** button. Click it! +10. [] Right below the alert title on the right hand side, there is a **Generate fix** button. Click it! - This uses the AI power of Copilot to generate a fix for the vulnerability. - 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 (30-60s) to generate a suggestion. Wait for it to finish. -12. If you're happy with the suggestion, click the **Commit to a new branch** button. -13. Accept the defaults and click **Commit change**. -14. This will create a **draft** pull request with the fix for the vulnerability. In a real world example, assuming your build and tests pass, you would move the PR out of a draft state, having someone on your team review it, and then merge the change. +11. [] It will take a little time (30-60s) to generate a suggestion. Wait for it to finish. +12. [] If you're happy with the suggestion, click the **Commit to a new branch** button. +13. [] Accept the defaults and click **Commit change**. +14. [] This will create a **draft** pull request with the fix for the vulnerability. In a real world example, assuming your build and tests pass, you would move the PR out of a draft state, having someone on your team review it, and then merge the change. - The nice thing with code scanning alerts (just like Dependabot alerts) is that once you merge the code and is scanned again that resolves an alert, the alert will be automatically closed. This is because the alert is no longer present in the code.
@@ -141,23 +141,23 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-2-4.png)
-15. We will merge this in change in. But first, we have to wait for the CodeQL workflow to finish running to ensure we aren't introducing any *new* vulnerabilities into the codebase. The workflow run will take 2-5 minutes. -16. Once the workflow finishes, click **Ready for review**. This moves the pull request out of the draft state. -17. Afterwards, click **Merge pull request** and then **Confirm merge**. +15. [] We will merge this in change in. But first, we have to wait for the CodeQL workflow to finish running to ensure we aren't introducing any *new* vulnerabilities into the codebase. The workflow run will take 2-5 minutes. +16. [] Once the workflow finishes, click **Ready for review**. This moves the pull request out of the draft state. +17. [] Afterwards, click **Merge pull request** and then **Confirm merge**. - 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! It will take a few minutes for the code scanning to run and close the alert. -18. Now that our new code has been merged, let's go watch the workflow scan run. Click on the **Actions** tab at the top of the page. -19. Select **CodeQL** on the left side of the page. This shows you all the default runs for the CodeQL workflow. You should see a workflow running right now for our push to main -20. Click the running workflow to see the details of the run. You can review the logs to see what CodeQL is doing behind the scenes here if you want! -21. Once the workflow completes successfully, return to the **Security** tab and check back on the list of code scanning alerts. You should see one (1) **Closed** alert listed - yay! 🎉 +18. [] Now that our new code has been merged, let's go watch the workflow scan run. Click on the **Actions** tab at the top of the page. +19. [] Select **CodeQL** on the left side of the page. This shows you all the default runs for the CodeQL workflow. You should see a workflow running right now for our push to main +20. [] Click the running workflow to see the details of the run. You can review the logs to see what CodeQL is doing behind the scenes here if you want! +21. [] Once the workflow completes successfully, return to the **Security** tab and check back on the list of code scanning alerts. You should see one (1) **Closed** alert listed - yay! 🎉 > [!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** --> **Default** option. This will show all of the default secret scanning alerts. -2. You should see a number of alerts. For example, there should be a **GitHub Personal Access token alert**. Click it. +1. [] Under the **Security** tab in the repo, click on the **Secret scanning** --> **Default** option. This will show all of the default secret scanning alerts. +2. [] You should see a number of alerts. For example, there should be a **GitHub Personal Access token alert**. Click it. - This page shows where in the code the secret was discovered (if there were multiple locations, it would list them all). - 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. @@ -167,30 +167,29 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-3-1.png) -3. 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). (clicking may not be there, since we enabled automatic visibility checked it may have been checked already, or it may even say the secret has been Publicly leaked). -4. Go back to list of secret scanning alerts. Click on the **Google API key** alert. -5. Click on **Verify secret** again. This time, it should say **secret inactive** (or **Publicly leaked inactive secret**). This is a good candidate to **Close as** --> **Revoked** (click the **Close as** button in the upper right to do so). Do this. +3. [] 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). (clicking may not be there, since we enabled automatic visibility checked it may have been checked already, or it may even say the secret has been Publicly leaked). +4. [] Go back to list of secret scanning alerts. Click on the **Google API key** alert. +5. [] Click on **Verify secret** again. This time, it should say **secret inactive** (or **Publicly leaked inactive secret**). This is a good candidate to **Close as** --> **Revoked** (click the **Close as** button in the upper right to do so). Do this. - 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 re-writing 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. -6. Navigate back to the **Default** secret alerts list. -7. We can click **1 Closed** to see the alert we just closed. +6. [] Navigate back to the **Default** secret alerts list. +7. [] We can click **1 Closed** to see the alert we just closed.
![image](images/lab-2-3-2.png)
-8. Click on the **Generic** 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. -9. Let's click into one of the **Password** alerts. +8. [] Click on the **Generic** 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. +9. [] Let's click into one of the **Password** alerts.
![image](images/lab-2-3-3.png)
-10. Just like high confidence secret scanning 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. +10. [] Just like high confidence secret scanning 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. -➡️ Head to the next [lab](lab3.md). diff --git a/_labs/lab3.md b/_labs/lab3.md index 51dd6e5..37b9973 100644 --- a/_labs/lab3.md +++ b/_labs/lab3.md @@ -4,11 +4,11 @@ With Code Scanning enabled, we want to block vulnerable code from entering the c ## Exercise 1: Introduce a code scanning security vulnerability -1. Navigate to the **routes/login.ts** file in your repository (make sure the **Code** tab is selected). -2. Click the Pencil icon on the top right of the file view to edit the file. -3. Find lines 36-46 and delete them +1. [] Navigate to the **routes/login.ts** file in your repository (make sure the **Code** tab is selected). +2. [] Click the Pencil icon on the top right of the file view to edit the file. +3. [] Find lines 36-46 and delete them -```diff +```diff-nopaste - models.sequelize.query( - 'SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL', - { @@ -22,30 +22,30 @@ With Code Scanning enabled, we want to block vulnerable code from entering the c - ) ``` -4. At line 36, add the following code: +4. [] At line 36, add the following code: ```javascript models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: UserModel, plain: true }) ``` -5. Let's push our new branch with the vulnerability up to GitHub. -6. Click the green **Commit Changes** button on the top right of the file view. -7. Keep the commit message the same, but feel free to add a description. -8. Select the **Create a new branch for this commit and start a pull request** radio button. -9. Keep the branch name at the default, which should be your GitHub handle followed by **-patch-1**. -10. Click the **Propose changes** button. -11. Click the **Create pull request** button at the bottom of the text field in the next view. -12. The page will redirect to the pull request that was just created. Do not merge the pull request yet, as we want to see the code scanning results first. -13. After the pull request is created, the code scanning job will have been initiated. You can see the status of the job in the pull request checks. It will take a few minutes to run. +5. [] Let's push our new branch with the vulnerability up to GitHub. +6. [] Click the green **Commit Changes** button on the top right of the file view. +7. [] Keep the commit message the same, but feel free to add a description. +8. [] Select the **Create a new branch for this commit and start a pull request** radio button. +9. [] Keep the branch name at the default, which should be your GitHub handle followed by **-patch-1**. +10. [] Click the **Propose changes** button. +11. [] Click the **Create pull request** button at the bottom of the text field in the next view. +12. [] The page will redirect to the pull request that was just created. Do not merge the pull request yet, as we want to see the code scanning results first. +13. [] After the pull request is created, the code scanning job will have been initiated. You can see the status of the job in the pull request checks. It will take a few minutes to run.
![image](images/lab-3-1-3.png)
-10. CodeQL should find the vulnerability, so the check will fail. Also, we should see Copilot create us an autofix on the PR as a code suggestion change that we can review (and commit) -11. It might take Copilot a few moments to create the autofix. -12. Review the autofix - we can prevent a vulnerability from entering the repository now with a click of a button! 🎉 ⚠️⚠️ **But don't commit the suggestion yet.** ⚠️⚠️ +10. [] CodeQL should find the vulnerability, so the check will fail. Also, we should see Copilot create us an autofix on the PR as a code suggestion change that we can review (and commit) +11. [] It might take Copilot a few moments to create the autofix. +12. [] Review the autofix - we can prevent a vulnerability from entering the repository now with a click of a button! 🎉 ⚠️⚠️ **But don't commit the suggestion yet.** ⚠️⚠️
@@ -59,41 +59,41 @@ Without a ruleset (GitHub's new version of branch protections), even though Code > [!NOTE] > We want to wait for the PR check to finish entirely (with a pass or fail) before creating the ruleset! -1. Let's go into the **Settings** tab of the repository (we will be adding a branch ruleset). -2. On the left hand list of options, click on **Rules --> Rulesets**. +1. [] Let's go into the **Settings** tab of the repository (we will be adding a branch ruleset). +2. [] On the left hand list of options, click on **Rules --> Rulesets**.
![image](images/lab-3-2-1.png)
-3. Click on **New ruleset ▾ --> New branch ruleset** -4. Create the ruleset: - 1. Give the ruleset a **name** (any name is fine) - 2. Change the **enforcement status** to **Active**. - 3. Under **target branches**, click **Add target** and select **Include default branch**. - 4. Scroll down and check the **Require code scanning results** box - 5. The CodeQL tool should already be there - there's nothing to change -5. Scroll down and click the **Create** button. +3. [] Click on **New ruleset ▾ --> New branch ruleset** +4. [] Create the ruleset: + 1. [] Give the ruleset a **name** (any name is fine) + 2. [] Change the **enforcement status** to **Active**. + 3. [] Under **target branches**, click **Add target** and select **Include default branch**. + 4. [] Scroll down and check the **Require code scanning results** box + 5. [] The CodeQL tool should already be there - there's nothing to change +5. [] Scroll down and click the **Create** button.
![image](images/lab-3-2-2.png)
-7. With the ruleset created, both the JavaScript scan has to finish and no vulnerabilities found with CodeQL in order to merge the code. -8. Navigate back to our open PR. The **Merge pull request** button should now be grayed out (there also a big red icon and the text **Merging is blocked** with the list of blocking reasons underneath), preventing us from merging vulnerable code. +7. [] With the ruleset created, both the JavaScript scan has to finish and no vulnerabilities found with CodeQL in order to merge the code. +8. [] Navigate back to our open PR. The **Merge pull request** button should now be grayed out (there also a big red icon and the text **Merging is blocked** with the list of blocking reasons underneath), preventing us from merging vulnerable code.
![image](images/lab-3-2-3.png)
-9. Review the **Copilot Autofix suggestion**. -10. Click on the **commit suggestion** button and **commit changes**. -11. After another CodeQL scan, the PR should pass and the **Merge pull request** button should be enabled, allowing you to merge the change without the vulnerability. +9. [] Review the **Copilot Autofix suggestion**. +10. [] Click on the **commit suggestion** button and **commit changes**. +11. [] After another CodeQL scan, the PR should pass and the **Merge pull request** button should be enabled, allowing you to merge the change without the vulnerability. - ➡️ For the purposes of this lab, you don't have to actually merge the PR, so **you don't have to wait fo the CodeQL scan to finish before moving on**. -12. Celebrate 🎉! We just prevented a security vulnerability from entering our codebase! +12. [] Celebrate 🎉! We just prevented a security vulnerability from entering our codebase! ## Summary @@ -101,4 +101,3 @@ Excellent! In this lab we saw how GitHub code scanning can find bugs in the pul In the next lab, we are going to learn about Dependency Review, and how it can help us stop bad dependencies from making it to the default branch. -➡️ Head to the next [lab](lab4.md). diff --git a/_labs/lab4.md b/_labs/lab4.md index 9075b58..fbd06c5 100644 --- a/_labs/lab4.md +++ b/_labs/lab4.md @@ -6,34 +6,34 @@ With Dependency Review enabled and configured, we want to block vulnerable packa First, let's add the dependency review action workflow. -1. In the repository, click on the **Actions** tab. -2. Click on the **New workflow** button in the upper left. -3. Search for "**dependency**" and click enter on your keyboard. -4. Under the **Dependency Review** workflow, click **Configure**. +1. [] In the repository, click on the **Actions** tab. +2. [] Click on the **New workflow** button in the upper left. +3. [] Search for "**dependency**" and click enter on your keyboard. +4. [] Under the **Dependency Review** workflow, click **Configure**.
![image](images/lab-4-1-1.png)
-5. Review the action **actions/dependency-review-action** and its inputs after **with:**. The options are going to be commented out so default values will be used. For example this action can also block specific open source license types or you can configure the severity of the vulnerabilities to be flagged. -6. In the upper right, click on **Commit changes...** -7. Since we have a ruleset, we have to create a branch and merge this to main via pull request. Create a branch and commit (**Propose changes**) the changes. +5. [] Review the action **actions/dependency-review-action** and its inputs after **with:**. The options are going to be commented out so default values will be used. For example this action can also block specific open source license types or you can configure the severity of the vulnerabilities to be flagged. +6. [] In the upper right, click on **Commit changes...** +7. [] Since we have a ruleset, we have to create a branch and merge this to main via pull request. Create a branch and commit (**Propose changes**) the changes.
![image](images/lab-4-1-2.png)
-8. On the next screen, If you have a Copilot license use the Copilot icon in the formatting bar to generate a pull request description. +8. [] On the next screen, If you have a Copilot license use the Copilot icon in the formatting bar to generate a pull request description.
![image](images/lab-4-1-3.png)
-9. Click **Create pull request**. -10. Wait for the code scanning job to finish. It will take a few minutes to run. +9. [] Click **Create pull request**. +10. [] Wait for the code scanning job to finish. It will take a few minutes to run. - You will notice that the Dependency Review workflow ran against this PR and didn't report any issues.
@@ -41,30 +41,30 @@ First, let's add the dependency review action workflow. ![image](images/lab-4-1-4.png)
-11. Merge the PR once the code scanning completes. -12. Navigate to **Settings** of the repo. -13. Navigate to **Rules --> Rulesets**. -14. Click on the name of the ruleset you created in **lab 3** to modify it. -15. Enable the check box for **Require status checks to pass** (scroll down or use search) -16. Click on **Add checks**. -17. Search for `dependency-review` and add it (it should show up under **suggestions**). +11. [] Merge the PR once the code scanning completes. +12. [] Navigate to **Settings** of the repo. +13. [] Navigate to **Rules --> Rulesets**. +14. [] Click on the name of the ruleset you created in **lab 3** to modify it. +15. [] Enable the check box for **Require status checks to pass** (scroll down or use search) +16. [] Click on **Add checks**. +17. [] Search for `dependency-review` and add it (it should show up under **suggestions**).
![image](images/lab-4-1-5.png)
-18. Save the changes to the ruleset. +18. [] Save the changes to the ruleset. ## Exercise 2: Introduce a dependency vulnerability Now, let's attempt to add a vulnerable dependency to the codebase and test out the dependency review feature. -1. Navigate back to the **Code** tab in the repo. -2. Click the **package.json** file in the root of the repository to open it. -3. Click the **pencil** ✏️ icon at the top right of the file to go into edit mode. -4. Go to the end of line 181 and hit Enter to create a blank line for line 182. -5. Add the following code to line 182, making sure to include the comma at the end of the line: +1. [] Navigate back to the **Code** tab in the repo. +2. [] Click the **package.json** file in the root of the repository to open it. +3. [] Click the **pencil** ✏️ icon at the top right of the file to go into edit mode. +4. [] Go to the end of line 181 and hit Enter to create a blank line for line 182. +5. [] Add the following code to line 182, making sure to include the comma at the end of the line: ``` "tar": "2.2.2", @@ -75,19 +75,19 @@ Now, let's attempt to add a vulnerable dependency to the codebase and test out t ![image](images/lab-4-2-1.png)
-6. Click the **Commit changes** button. -7. Change the branch name to **lab4/dependency-vulnerability** and click **Propose changes** to start a pull request. -8. Use the **Copilot** button in the formatting bar to generate a PR summary for you. -9. Click the **Create pull request** button. -10. Wait for the dependency review job to finish. -11. It should make a comment to the pull request with a note that it found a vulnerable package dependency. In fact, adding this one package would introduce 3 new vulnerabilities to our codebase. +6. [] Click the **Commit changes** button. +7. [] Change the branch name to **lab4/dependency-vulnerability** and click **Propose changes** to start a pull request. +8. [] Use the **Copilot** button in the formatting bar to generate a PR summary for you. +9. [] Click the **Create pull request** button. +10. [] Wait for the dependency review job to finish. +11. [] It should make a comment to the pull request with a note that it found a vulnerable package dependency. In fact, adding this one package would introduce 3 new vulnerabilities to our codebase.
![image](images/lab-4-2-2.png)
-12. Also, the status check will be marked as failed, preventing the pull request from being merged since we have made dependency review a required check. +12. [] Also, the status check will be marked as failed, preventing the pull request from being merged since we have made dependency review a required check. ## Summary @@ -95,4 +95,3 @@ Celebrate 🎉! We just prevented a security vulnerability from entering our cod In the next lab, we are going to go hands-on with secret protection, and see how we can use push protection to stop secrets from being pushed to GitHub. -➡️ Head to the next [lab](lab4.md). diff --git a/_labs/lab5.md b/_labs/lab5.md index 3dc1e3e..20b5159 100644 --- a/_labs/lab5.md +++ b/_labs/lab5.md @@ -4,27 +4,27 @@ Let's use Secret Scanning with push protections to prevent secrets from entering ## Exercise 1: Attempt to commit a secret -1. Let's try to commit a secret to the repository to test out the secret scanning push protection feature. -2. But first, we need a secret to commit! The easiest is to generate a GitHub personal access token (with limited scopes) and attempt to commit it. -3. In a new browser tab, navigate to github.com and click on your **user profile picture** in the upper right and click on **Settings**. -4. In the lower left of the list of options, click on **Developer settings**. -5. Click on **Personal Access Tokens** to expand and click on **Fine-Grained Tokens**. -6. Generate a **new token**. -7. Don't give the token any permissions - just give it a **name** and scroll down to the bottom and **Generate token**. -8. **Copy** the value of the token to the clipboard. +1. [] Let's try to commit a secret to the repository to test out the secret scanning push protection feature. +2. [] But first, we need a secret to commit! The easiest is to generate a GitHub personal access token (with limited scopes) and attempt to commit it. +3. [] In a new browser tab, navigate to github.com and click on your **user profile picture** in the upper right and click on **Settings**. +4. [] In the lower left of the list of options, click on **Developer settings**. +5. [] Click on **Personal Access Tokens** to expand and click on **Fine-Grained Tokens**. +6. [] Generate a **new token**. +7. [] Don't give the token any permissions - just give it a **name** and scroll down to the bottom and **Generate token**. +8. [] **Copy** the value of the token to the clipboard. - Note: If you leave this page, you will not be able to copy the token again. If you lose the token from the clipboard, either regenerate the token or create a new one. -9. Now, let's attempt to commit the token to the repository. -10. Any file would work, but for example, we can open up the `routes/login.ts` file we edited earlier. -11. As an example, on line 18 you can add `const secret = "";`, replacing **** with the token you just generated - it should start with **github_pat_**. -12. Commit the file and then push the file to the repo. -13. Push protection should detect the GitHub personal access token and block the push - great! +9. [] Now, let's attempt to commit the token to the repository. +10. [] Any file would work, but for example, we can open up the `routes/login.ts` file we edited earlier. +11. [] As an example, on line 18 you can add `const secret = "";`, replacing **** with the token you just generated - it should start with **github_pat_**. +12. [] Commit the file and then push the file to the repo. +13. [] Push protection should detect the GitHub personal access token and block the push - great!
In the UI:
![image](images/lab-5-1-1.png)

-14. Depending on how the settings are configured, we could bypass the push protection and push the secret to the repository. But, we don't want to do that! 🙅‍♂️ Repository admins and organization owners would receive an email notification if we did. +14. [] Depending on how the settings are configured, we could bypass the push protection and push the secret to the repository. But, we don't want to do that! 🙅‍♂️ Repository admins and organization owners would receive an email notification if we did. ## Summary @@ -32,4 +32,3 @@ Celebrate 🎉! We just prevented a secret from entering our codebase! And there you have it. You should now have a good grasp on what GitHub Advanced Security is, how it works, and how to implement it. So get out there and keep your company secured! -➡️ Head to the next [lab](lab5.md). diff --git a/_labs/lab6.md b/_labs/lab6.md index a67f5e7..5456f13 100644 --- a/_labs/lab6.md +++ b/_labs/lab6.md @@ -6,8 +6,6 @@ This lab covers parts of the following exam domains: - Domain 6: Describe GitHub Advanced Security best practices -> [!NOTE] This lab is only available if you are using an organization as the owner of the repository. - ## Exercise 1: Navigating to Security Overview The Security Overview can be used by anyone inside of an organization; it shows repositories that **you** have access to. If you are an org owner or a security manager, you would see all alerts. If you are a regular org member, you would only see alerts for repositories by default that you have write access to. @@ -15,10 +13,10 @@ The Security Overview can be used by anyone inside of an organization; it shows > [!NOTE] > Security alerts for a repository are visible to people with write, maintain, or admin access to the repository and, when the repository is owned by an organization, organization owners. You can give additional teams and people access to the alerts. -1. Navigate to the organization you created the repository for the lab. You can do so by **clicking on the org name** in the repository breadcrumbs in the upper left hand corner. +1. [] Navigate to the organization you created the repository for the lab. You can do so by **clicking on the org name** in the repository breadcrumbs in the upper left hand corner. - You can also navigate to your orgs by clicking on your profile picture and "**Your organizations**" -2. Click on the **Security** tab. -3. Review (and click on!) the different views on the left-hand side: +2. [] Click on the **Security** tab. +3. [] Review (and click on!) the different views on the left-hand side: - **Overview**: visualize trends in Detection, Remediation, and Prevention of security alerts ([docs](https://docs.github.com/en/enterprise-cloud@latest/code-security/security-overview/viewing-security-insights#about-security-insights)) - **Risk**: explore the risk from security alerts of all types or focus on a single alert type and identify your risk from specific vulnerable dependencies, code weaknesses, or leaked secrets ([docs](https://docs.github.com/en/enterprise-cloud@latest/code-security/security-overview/assessing-code-security-risk)) - **Coverage**: assess the adoption of code security features across repositories in the organization ([docs](https://docs.github.com/en/enterprise-cloud@latest/code-security/security-overview/assessing-adoption-code-security)) @@ -29,16 +27,17 @@ The Security Overview can be used by anyone inside of an organization; it shows > [!TIP] > You can export a CSV of nearly from most of these views using the **Export CSV** button in the upper right. -4. Under the **Overview** view, navigate the sub-views, specifically **Detection** and **Remediation**. +4. [] Under the **Overview** view, navigate the sub-views, specifically **Detection** and **Remediation**. - Note the trends - this is useful information to evaluate the security posture of your organization. Are we getting better over time? - Being secure requires "constant vigilance" -5. Navigate to the **Risk** view. -6. On the right-hand side, click the **Teams ▾** button/dropdown. -7. Click on the **all users** team - this team is only added to a different sample repo, so note how the total alerts changes. +5. [] Navigate to the **Risk** view. +6. [] On the right-hand side, click the **Teams ▾** button/dropdown. +7. [] Click on the **all users** team - this team is only added to a different sample repo, so note how the total alerts changes. - This can be really useful for a manager, architect, or developer to see which repositories assigned to the teams have security features enabled and how many alerts they are generating. -8. At the bottom of the options on the left, you will see **Security Campaigns**. +8. [] At the bottom of the options on the left, you will see **Security Campaigns**. - Security campaigns are a new feature designed to help administrators and security managers create targeted campaigns and track remediation progress effectively. -9. ⚠️ Please don't create a new security campaign as to not introduce noise to your fellow attendees ⚠️ +9. [] ⚠️ Please don't create a new security campaign as to not introduce noise to your fellow attendees ⚠️, but click on the existing campaign here (**SQL injection (CWE-89)**) to check it out! + - How are we doing on our goal? > [!TIP] If your If your company is using GitHub Enterprise or GitHub Teams plan and is not yet using GitHub Secrets Protection, you can run a [secret risk assessement](https://docs.github.com/en/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment) at no cost to understand exposure to data leaks and to get an overview of your organization's secret leak footprint. @@ -50,5 +49,3 @@ If you want to learn more about the security overview or about what a particular Congrats, you have finished all of the main labs! 🎉 If you have time or are up for a challenge, try out the extra credit labs! -➡️ If you want, you can now head to the first [extra credit lab](lab7-ec.md). - diff --git a/_labs/lab7-ec.md b/_labs/lab7-ec.md index 7a8b5cb..527d3ed 100644 --- a/_labs/lab7-ec.md +++ b/_labs/lab7-ec.md @@ -26,4 +26,3 @@ Your goal is to have a CodeQL workflow committed that successfully scans your co In this lab, you have learned how to set up and configure advanced code scanning. There is no definitive answer as to whether the default or advanced setup is better. The default setup is ideal for quickly configuring CodeQL on repositories without requiring code changes or PR approvals. However, the advanced setup offers more customization and flexibility. -➡️ Head to the next [extra credit lab](lab8-ec.md). diff --git a/_labs/lab8-ec.md b/_labs/lab8-ec.md index e8ff218..af92f49 100644 --- a/_labs/lab8-ec.md +++ b/_labs/lab8-ec.md @@ -20,4 +20,3 @@ Create a pattern, run a dry-run, and hopefully you find the pattern! If so, save In this lab, you should have identified the credit card number that was accidentally committed. Custom secret scanning patterns offer an excellent way to implement additional scanning patterns that are crucial for your organization! -➡️ Head back to the [labs](README.md) page. From 711f32b9ea3c48d875d3331a2acac111eb6ea384 Mon Sep 17 00:00:00 2001 From: Tiago Pascoal Date: Mon, 28 Apr 2025 08:21:54 +0100 Subject: [PATCH 2/5] Fix Entra credentials --- _labs/lab1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_labs/lab1.md b/_labs/lab1.md index ff706a5..620083d 100644 --- a/_labs/lab1.md +++ b/_labs/lab1.md @@ -19,8 +19,8 @@ In this exercise, you will create a repository with code from which you can work 1. [] Navigate to +++https://github.com/enterprises/skillable-events/sso+++ 2. [] Click on the green **Continue** button when the **Single sign-on to Skillable Events** page appears -3. [] Enter the your username +++@lab.VirtualMachine(Win11-Pro-Base-VM).Username+++ -4. [] Enter your password +++@lab.VirtualMachine(Win11-Pro-Base-VM).Password+++ +3. [] Enter the your username +++@lab.CloudPortalCredential(User1).Username+++ +4. [] Enter your password +++@lab.CloudPortalCredential(User1).Password+++ 5. [] Navigate to +++https://github.com/github-samples/securing-your-code+++ in your browser. 6. [] Click the green **Use this template** button in the upper right corner of the page. 7. [] Create a new repository in our organization by choosing **Microsoft-Build-2025** in the owner dropdown. From 20cd7b4446ae183b80af4a2841607af6f769385a Mon Sep 17 00:00:00 2001 From: Tiago Pascoal Date: Tue, 29 Apr 2025 18:26:25 +0100 Subject: [PATCH 3/5] Update labs. Make items more readable, remove some things that don't make sense in target environment and a few fixes (numbering,typos) --- _labs/lab1.md | 9 +++++---- _labs/lab2.md | 12 ++++++------ _labs/lab3.md | 14 +++++++------- _labs/lab4.md | 8 ++++---- _labs/lab5.md | 8 +++++--- _labs/lab6.md | 12 ++++++------ 6 files changed, 33 insertions(+), 30 deletions(-) diff --git a/_labs/lab1.md b/_labs/lab1.md index 620083d..7608de5 100644 --- a/_labs/lab1.md +++ b/_labs/lab1.md @@ -39,7 +39,7 @@ Although Dependabot isn't part of the GitHub Advanced Security product suite, it Dependabot and Dependency Graph should already be turned on for your repository. If not, follow the steps below. 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 **Advanced Security** section. +2. [] Click on the **Code Security** section. 3. [] Ensure the Dependency Graph is enabled (scroll down to **Code Security** group). This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependency Graph** setting. To enable Dependabot, we first have to enable the Dependency Graph. This allows Dependabot to ingest your package manifest files. 4. [] Ensure the Dependabot alerts are enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependabot alerts** setting. This feature will create alerts for vulnerable dependencies found in your repository. 5. [] Click the **Enable** button next to the **Dependabot security updates** setting. @@ -55,9 +55,10 @@ Once you are done turning on Dependabot features, the next thing we will need to ### Exercise 2: Enable Code Security -1. [] Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Advanced Security** settings page. -2. [] Ensure **Code Security** is enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable **Code Security**. -3. [] Underneath the **Code Security | Tools** heading, click the **Set up** button in the **CodeQL analysis** row. +1. [] Scroll down to the **GitHub Advanced Security** section and make sure it's enabled. If there is a black **Enable** button, click it to enable the **GitHub Advanced Security** setting. +2. [] Click on the **Enabled GitHub Advanced Security for this repository** on the confirmation **Enable GitHub Advanced Security for this repository?** dialog window. +3. [] Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Code Security** settings page. +4. [] Underneath the **Code Security | Tools** heading, click the **Set up** button in the **CodeQL analysis** row. > [!NOTE] > If you do not see the **Code scanning** heading on the **Code security** page after enabling **Code Security** - you have likely not created your repo in the proper Organization. Go back to the beginning of this lab and ensure you choose **Microsoft-Build-2025** value from the dropdown as the new repository **Owner** when you choose **Use this template**. diff --git a/_labs/lab2.md b/_labs/lab2.md index dbd3077..9d5d18c 100644 --- a/_labs/lab2.md +++ b/_labs/lab2.md @@ -9,7 +9,7 @@ Now that we have all of the security feature enabled, let's review the security
- ![alt text](image.png) + ![security alerts](images/lab-2-1-1.png)
3. [] You should see a number of Dependabot alerts with various severities. Click on one of the alerts to see more information about it. @@ -19,7 +19,7 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-1-2.png) -4. [] When reviewing a Dependabot alert, you can see the following information (see if you can locate this information in the alert you opened): +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 @@ -71,7 +71,7 @@ Now that we have all of the security feature enabled, let's review the security -15. [] Auto-triage your alerts allows you control over how Dependabot opens pull requests, ignores false positives and snoozes alerts. Navigate to the **Settings** tab (the icon of the gear) in the repo and then **Advanced Security** left sidecar, scroll to **Dependabot**, then find **Dependabot rules** underneath **Dependabot alerts**. +15. [] Auto-triage your alerts allows you control over how Dependabot opens pull requests, ignores false positives and snoozes alerts. Navigate to the **Settings** tab (the icon of the gear) in the repo and then **Code Security** left sidecar, scroll to **Dependabot**, then find **Dependabot rules** underneath **Dependabot alerts**. 16. [] Add a rule to snooze any alerts that do not have a fix available. Choose the "gear" icon and select the **New rule** button. Name the rule `Snooze when no patch available`, add a target metadata for all npm packages: `ecosystem:npm` and ensure the **Dismiss Alerts - Until patch is available** is selected. Next, select **Create rule**. @@ -141,7 +141,7 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-2-4.png) -15. [] We will merge this in change in. But first, we have to wait for the CodeQL workflow to finish running to ensure we aren't introducing any *new* vulnerabilities into the codebase. The workflow run will take 2-5 minutes. +15. [] We will merge this in change in. But first, we have to wait for the CodeQL workflow to finish running to ensure we aren't introducing any *new* vulnerabilities into the codebase. The workflow run will take 2-5 minutes (watch the running workflow in the Checks section to check when it's completed (circle changes from yellow to green and says "All Checks have passed")). 16. [] Once the workflow finishes, click **Ready for review**. This moves the pull request out of the draft state. 17. [] Afterwards, click **Merge pull request** and then **Confirm merge**. - After merging the code into the default branch, a code scan will run and once it finishes, the alert will be closed. @@ -169,7 +169,7 @@ Now that we have all of the security feature enabled, let's review the security 3. [] 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). (clicking may not be there, since we enabled automatic visibility checked it may have been checked already, or it may even say the secret has been Publicly leaked). 4. [] Go back to list of secret scanning alerts. Click on the **Google API key** alert. -5. [] Click on **Verify secret** again. This time, it should say **secret inactive** (or **Publicly leaked inactive secret**). This is a good candidate to **Close as** --> **Revoked** (click the **Close as** button in the upper right to do so). Do this. +5. [] Click on **Verify secret** again. This time, it should say **secret inactive** (or **Publicly leaked inactive secret**). This is a good candidate to **Close as** --> **Revoked** (click the **Close as** button in the upper right to do so), select **Revoked** and click on **Close Alert**. - 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 re-writing 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. 6. [] Navigate back to the **Default** secret alerts list. 7. [] We can click **1 Closed** to see the alert we just closed. @@ -180,7 +180,7 @@ Now that we have all of the security feature enabled, let's review the security 8. [] Click on the **Generic** 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. -9. [] Let's click into one of the **Password** alerts. +9. [] Let's click into one of the found **Generic** alerts.
diff --git a/_labs/lab3.md b/_labs/lab3.md index 37b9973..78bb74b 100644 --- a/_labs/lab3.md +++ b/_labs/lab3.md @@ -43,9 +43,9 @@ models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ' ![image](images/lab-3-1-3.png)
-10. [] CodeQL should find the vulnerability, so the check will fail. Also, we should see Copilot create us an autofix on the PR as a code suggestion change that we can review (and commit) -11. [] It might take Copilot a few moments to create the autofix. -12. [] Review the autofix - we can prevent a vulnerability from entering the repository now with a click of a button! 🎉 ⚠️⚠️ **But don't commit the suggestion yet.** ⚠️⚠️ +14. [] CodeQL should find the vulnerability, so the check will fail. Also, we should see Copilot create us an autofix on the PR as a code suggestion change that we can review (and commit) +15. [] It might take Copilot a few moments to create the autofix. +16. [] Review the autofix - we can prevent a vulnerability from entering the repository now with a click of a button! 🎉 ⚠️⚠️ **But don't commit the suggestion yet.** ⚠️⚠️
@@ -73,7 +73,7 @@ Without a ruleset (GitHub's new version of branch protections), even though Code 2. [] Change the **enforcement status** to **Active**. 3. [] Under **target branches**, click **Add target** and select **Include default branch**. 4. [] Scroll down and check the **Require code scanning results** box - 5. [] The CodeQL tool should already be there - there's nothing to change + 5. [] The CodeQL tool should already be there - there's nothing to change (you can change the security alerts and alerts. But please don't). 5. [] Scroll down and click the **Create** button.
@@ -81,8 +81,8 @@ Without a ruleset (GitHub's new version of branch protections), even though Code ![image](images/lab-3-2-2.png)
-7. [] With the ruleset created, both the JavaScript scan has to finish and no vulnerabilities found with CodeQL in order to merge the code. -8. [] Navigate back to our open PR. The **Merge pull request** button should now be grayed out (there also a big red icon and the text **Merging is blocked** with the list of blocking reasons underneath), preventing us from merging vulnerable code. +6. [] With the ruleset created, both the JavaScript scan has to finish and no vulnerabilities found with CodeQL in order to merge the code. +7. [] Navigate back to our open PR. The **Merge pull request** button should now be grayed out (there also a big red icon and the text **Merging is blocked** with the list of blocking reasons underneath), preventing us from merging vulnerable code.
@@ -92,7 +92,7 @@ Without a ruleset (GitHub's new version of branch protections), even though Code 9. [] Review the **Copilot Autofix suggestion**. 10. [] Click on the **commit suggestion** button and **commit changes**. 11. [] After another CodeQL scan, the PR should pass and the **Merge pull request** button should be enabled, allowing you to merge the change without the vulnerability. - - ➡️ For the purposes of this lab, you don't have to actually merge the PR, so **you don't have to wait fo the CodeQL scan to finish before moving on**. + - ➡️ For the purposes of this lab, you don't have to actually merge the PR, so **you don't have to wait for the CodeQL scan to finish before moving on**. 12. [] Celebrate 🎉! We just prevented a security vulnerability from entering our codebase! ## Summary diff --git a/_labs/lab4.md b/_labs/lab4.md index fbd06c5..45fa08f 100644 --- a/_labs/lab4.md +++ b/_labs/lab4.md @@ -16,7 +16,7 @@ First, let's add the dependency review action workflow. ![image](images/lab-4-1-1.png)
-5. [] Review the action **actions/dependency-review-action** and its inputs after **with:**. The options are going to be commented out so default values will be used. For example this action can also block specific open source license types or you can configure the severity of the vulnerabilities to be flagged. +5. [] Review the action **actions/dependency-review-action** and its inputs after **with:...**. The options are going to be commented out so default values will be used. For example this action can also block specific open source license types or you can configure the severity of the vulnerabilities to be flagged. 6. [] In the upper right, click on **Commit changes...** 7. [] Since we have a ruleset, we have to create a branch and merge this to main via pull request. Create a branch and commit (**Propose changes**) the changes. @@ -25,7 +25,7 @@ First, let's add the dependency review action workflow. ![image](images/lab-4-1-2.png)
-8. [] On the next screen, If you have a Copilot license use the Copilot icon in the formatting bar to generate a pull request description. +8. [] On the next screen, enter an optional pull request description (and feel free to change the title).
@@ -77,7 +77,7 @@ Now, let's attempt to add a vulnerable dependency to the codebase and test out t 6. [] Click the **Commit changes** button. 7. [] Change the branch name to **lab4/dependency-vulnerability** and click **Propose changes** to start a pull request. -8. [] Use the **Copilot** button in the formatting bar to generate a PR summary for you. +8. [] Enter an optional pull request description (and feel free to change the title). 9. [] Click the **Create pull request** button. 10. [] Wait for the dependency review job to finish. 11. [] It should make a comment to the pull request with a note that it found a vulnerable package dependency. In fact, adding this one package would introduce 3 new vulnerabilities to our codebase. @@ -87,7 +87,7 @@ Now, let's attempt to add a vulnerable dependency to the codebase and test out t ![image](images/lab-4-2-2.png)
-12. [] Also, the status check will be marked as failed, preventing the pull request from being merged since we have made dependency review a required check. +12. [] Also, the **required** status check will be marked as failed, preventing the pull request from being merged since we have made dependency review a required check. ## Summary diff --git a/_labs/lab5.md b/_labs/lab5.md index 20b5159..c8e0855 100644 --- a/_labs/lab5.md +++ b/_labs/lab5.md @@ -13,18 +13,20 @@ Let's use Secret Scanning with push protections to prevent secrets from entering 7. [] Don't give the token any permissions - just give it a **name** and scroll down to the bottom and **Generate token**. 8. [] **Copy** the value of the token to the clipboard. - Note: If you leave this page, you will not be able to copy the token again. If you lose the token from the clipboard, either regenerate the token or create a new one. -9. [] Now, let's attempt to commit the token to the repository. +9. Now, let's attempt to commit the token to the repository. 10. [] Any file would work, but for example, we can open up the `routes/login.ts` file we edited earlier. 11. [] As an example, on line 18 you can add `const secret = "";`, replacing **** with the token you just generated - it should start with **github_pat_**. -12. [] Commit the file and then push the file to the repo. +12. [] Commit the file and then push the file to the repo, by clicking on the **Commit changes** button and then **Propose Changes**. + 13. [] Push protection should detect the GitHub personal access token and block the push - great! +14. [] Click on **Cancel** since GitHub Secret Protection did it's job and prevented us from pushing the secret to the repository.
In the UI:
![image](images/lab-5-1-1.png)

-14. [] Depending on how the settings are configured, we could bypass the push protection and push the secret to the repository. But, we don't want to do that! 🙅‍♂️ Repository admins and organization owners would receive an email notification if we did. +15. [] Depending on how the settings are configured, we could bypass the push protection and push the secret to the repository. But, we don't want to do that! 🙅‍♂️ Repository admins and organization owners would receive an email notification if we did. ## Summary diff --git a/_labs/lab6.md b/_labs/lab6.md index 5456f13..c0389f4 100644 --- a/_labs/lab6.md +++ b/_labs/lab6.md @@ -13,7 +13,7 @@ The Security Overview can be used by anyone inside of an organization; it shows > [!NOTE] > Security alerts for a repository are visible to people with write, maintain, or admin access to the repository and, when the repository is owned by an organization, organization owners. You can give additional teams and people access to the alerts. -1. [] Navigate to the organization you created the repository for the lab. You can do so by **clicking on the org name** in the repository breadcrumbs in the upper left hand corner. +1. [] Navigate to the **Microsoft-Build-2025** organization. You can do so by clicking on the **Microsoft-Build-2025** in the repository breadcrumbs in the upper left hand corner. - You can also navigate to your orgs by clicking on your profile picture and "**Your organizations**" 2. [] Click on the **Security** tab. 3. [] Review (and click on!) the different views on the left-hand side: @@ -32,14 +32,14 @@ The Security Overview can be used by anyone inside of an organization; it shows - Being secure requires "constant vigilance" 5. [] Navigate to the **Risk** view. 6. [] On the right-hand side, click the **Teams ▾** button/dropdown. -7. [] Click on the **all users** team - this team is only added to a different sample repo, so note how the total alerts changes. - - This can be really useful for a manager, architect, or developer to see which repositories assigned to the teams have security features enabled and how many alerts they are generating. -8. [] At the bottom of the options on the left, you will see **Security Campaigns**. +7. [] Click on the **members** team - this is going to be empty since the team has no repositories, so note how the total alerts changes. + - This can be really useful for a manager, architect, or developer to see which repositories assigned to the teams have security features enabled and how many alerts they are generating. In our case it's not useful at all. +8. [] At the bottom of the options on the left, you will see **Campaigns**. - Security campaigns are a new feature designed to help administrators and security managers create targeted campaigns and track remediation progress effectively. -9. [] ⚠️ Please don't create a new security campaign as to not introduce noise to your fellow attendees ⚠️, but click on the existing campaign here (**SQL injection (CWE-89)**) to check it out! +9. [] Click on the existing campaign here (**SQL injection (CWE-89)**) to check it out! - How are we doing on our goal? -> [!TIP] If your If your company is using GitHub Enterprise or GitHub Teams plan and is not yet using GitHub Secrets Protection, you can run a [secret risk assessement](https://docs.github.com/en/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment) at no cost to understand exposure to data leaks and to get an overview of your organization's secret leak footprint. +> [!TIP] If your If your company is using GitHub Enterprise or GitHub Teams plan and is not yet using GitHub Secrets Protection, you can run a [secret risk assessment](https://docs.github.com/en/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment) at no cost to understand exposure to data leaks and to get an overview of your organization's secret leak footprint. ## Summary From c47b01fadb49b40eb1ea9954283a299f9bc58570 Mon Sep 17 00:00:00 2001 From: Tiago Pascoal Date: Wed, 7 May 2025 18:59:08 +0100 Subject: [PATCH 4/5] Small content fixes --- _labs/lab1.md | 16 ++++++++-------- _labs/lab2.md | 4 ++-- _labs/lab7-ec.md | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/_labs/lab1.md b/_labs/lab1.md index 7608de5..f58c522 100644 --- a/_labs/lab1.md +++ b/_labs/lab1.md @@ -24,7 +24,7 @@ In this exercise, you will create a repository with code from which you can work 5. [] Navigate to +++https://github.com/github-samples/securing-your-code+++ in your browser. 6. [] Click the green **Use this template** button in the upper right corner of the page. 7. [] Create a new repository in our organization by choosing **Microsoft-Build-2025** in the owner dropdown. -8. [] Give the repository a unique name **lab303-**. Click the green link below for inspiration on a unique repo name 😉. +8. [] Give the repository a unique name +++lab301-@lab.LabInstance.ID+++. 9. [] Make sure you switch it to visibility **Private** so your work does not conflict with other attendees! Now click **Create repository**. 10. [] The page will refresh after a few seconds where you can now see the code we will be working with. @@ -39,8 +39,8 @@ Although Dependabot isn't part of the GitHub Advanced Security product suite, it Dependabot and Dependency Graph should already be turned on for your repository. If not, follow the steps below. 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** section. -3. [] Ensure the Dependency Graph is enabled (scroll down to **Code Security** group). This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependency Graph** setting. To enable Dependabot, we first have to enable the Dependency Graph. This allows Dependabot to ingest your package manifest files. +2. [] Click on the **Advanced Security** section. +3. [] Ensure the Dependency Graph is enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependency Graph** setting. To enable Dependabot, we first have to enable the Dependency Graph. This allows Dependabot to ingest your package manifest files. 4. [] Ensure the Dependabot alerts are enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable the **Dependabot alerts** setting. This feature will create alerts for vulnerable dependencies found in your repository. 5. [] Click the **Enable** button next to the **Dependabot security updates** setting. - This will automatically create pull requests to update your vulnerable dependencies (if there is a non-vulnerable version to upgrade to). @@ -56,12 +56,12 @@ Once you are done turning on Dependabot features, the next thing we will need to ### Exercise 2: Enable Code Security 1. [] Scroll down to the **GitHub Advanced Security** section and make sure it's enabled. If there is a black **Enable** button, click it to enable the **GitHub Advanced Security** setting. -2. [] Click on the **Enabled GitHub Advanced Security for this repository** on the confirmation **Enable GitHub Advanced Security for this repository?** dialog window. -3. [] Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Code Security** settings page. -4. [] Underneath the **Code Security | Tools** heading, click the **Set up** button in the **CodeQL analysis** row. +2. [] Click on the **Enable GitHub Advanced Security for this repository** on the confirmation **Enable GitHub Advanced Security for this repository?** dialog window. +3. [] Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Advanced Security** settings page. +4. [] Underneath the **Code Scanning | Tools** heading, click the **Set up** button in the **CodeQL analysis** row. > [!NOTE] -> If you do not see the **Code scanning** heading on the **Code security** page after enabling **Code Security** - you have likely not created your repo in the proper Organization. Go back to the beginning of this lab and ensure you choose **Microsoft-Build-2025** value from the dropdown as the new repository **Owner** when you choose **Use this template**. +> If you do not see the **Code scanning** heading on the **Code Scanning** page after enabling **Code Security** - you have likely not created your repo in the proper Organization. Go back to the beginning of this lab and ensure you choose **Microsoft-Build-2025** value from the dropdown as the new repository **Owner** when you choose **Use this template**. 4. There are two options: **Default** and **Advanced**. Select the **Default** option and review the settings. - For this lab, we will use the **Default** setup, which creates a managed Actions workflow (i.e. you will not see a codeql.yaml file committed to the repo). The Advanced option can be used to manage your code scanning workflow as a GitHub Actions workflow YAML file committed to the repo. The **Default** option is a great option to get started quickly to enable code scanning in a repository without needing to commit any additional code. @@ -96,7 +96,7 @@ Once you are done turning on Dependabot features, the next thing we will need to 1. [] Ensure that Secret Protection is enabled. This will be indicated by a red **Disable** button. If there is a black **Enable** button, click it to enable **Secret Scanning**. 2. [] 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 Azure, 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. 3. [] Click the **Enable** button next to the **Non-provider patterns** setting. This scans for patterns that do not correspond to partners but still have a common syntax, such as a MySQL or MongoDB connection string. -4. [] Check the box to **Scan for generic passwords**. This feature uses AI to find secrets/passwords that may be in your code that do not correspond to a known provider pattern. +4. [] Click the **Enable** button next to the **Scan for generic passwords**. This feature uses AI to find secrets/passwords that may be in your code that do not correspond to a known provider pattern. 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**. - By default, as to not interrupt developers' workflows, 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). diff --git a/_labs/lab2.md b/_labs/lab2.md index 9d5d18c..6bacfeb 100644 --- a/_labs/lab2.md +++ b/_labs/lab2.md @@ -19,7 +19,7 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-1-2.png) -4. When reviewing a Dependabot alert, you can see the following information (see if you can locate this information in the alert you opened): +4. [] Click on an alert. 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 @@ -71,7 +71,7 @@ Now that we have all of the security feature enabled, let's review the security -15. [] Auto-triage your alerts allows you control over how Dependabot opens pull requests, ignores false positives and snoozes alerts. Navigate to the **Settings** tab (the icon of the gear) in the repo and then **Code Security** left sidecar, scroll to **Dependabot**, then find **Dependabot rules** underneath **Dependabot alerts**. +15. [] Auto-triage your alerts allows you control over how Dependabot opens pull requests, ignores false positives and snoozes alerts. Navigate to the **Settings** tab (the icon of the gear) in the repo and then **Advanced Security** left sidecar, scroll to **Dependabot**, then find **Dependabot rules** underneath **Dependabot alerts**. 16. [] Add a rule to snooze any alerts that do not have a fix available. Choose the "gear" icon and select the **New rule** button. Name the rule `Snooze when no patch available`, add a target metadata for all npm packages: `ecosystem:npm` and ensure the **Dismiss Alerts - Until patch is available** is selected. Next, select **Create rule**. diff --git a/_labs/lab7-ec.md b/_labs/lab7-ec.md index 527d3ed..9d1a190 100644 --- a/_labs/lab7-ec.md +++ b/_labs/lab7-ec.md @@ -18,7 +18,7 @@ Why might you want to use the advanced setup? Here are some reasons: ### Assignment -Your assignment here is to switch to the **[advanced setup](https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning)**. You can start under the **Settings** --> **Code Security** page. +Your assignment here is to switch to the **[advanced setup](https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning)**. You can start under the **Settings** --> **Advanced Security** page. Your goal is to have a CodeQL workflow committed that successfully scans your code. Pay attention to some of the configuration options for the CodeQL scanning action. Refer to the [documentation](https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning) for more details. From 1392ff48e09cccca877939a5e99eec129350a099 Mon Sep 17 00:00:00 2001 From: Tiago Pascoal Date: Mon, 12 May 2025 19:00:34 +0100 Subject: [PATCH 5/5] Fix typo in lab2.md regarding CodeQL workflow instructions --- _labs/lab2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_labs/lab2.md b/_labs/lab2.md index 6bacfeb..b63bd6a 100644 --- a/_labs/lab2.md +++ b/_labs/lab2.md @@ -141,7 +141,7 @@ Now that we have all of the security feature enabled, let's review the security ![image](images/lab-2-2-4.png) -15. [] We will merge this in change in. But first, we have to wait for the CodeQL workflow to finish running to ensure we aren't introducing any *new* vulnerabilities into the codebase. The workflow run will take 2-5 minutes (watch the running workflow in the Checks section to check when it's completed (circle changes from yellow to green and says "All Checks have passed")). +15. [] We will merge this change. But first, we have to wait for the CodeQL workflow to finish running to ensure we aren't introducing any *new* vulnerabilities into the codebase. The workflow run will take 2-5 minutes (watch the running workflow in the Checks section to check when it's completed (circle changes from yellow to green and says "All Checks have passed")). 16. [] Once the workflow finishes, click **Ready for review**. This moves the pull request out of the draft state. 17. [] Afterwards, click **Merge pull request** and then **Confirm merge**. - After merging the code into the default branch, a code scan will run and once it finishes, the alert will be closed.