Merge pull request #3 from ghuwsec1953/mickeygousset/dryrun1

Mickeygousset/dryrun1

Author: Admin-01 SecW01

_labs/images/lab-1-3-1.png

@@ -12,12 +12,12 @@ This lab covers parts of the following exam domains:
 
 We need to provision our working copy of the repository in order to begin the labs!
 
-1. Navigate to URL: [https://github.com/joshjohanning-org/juice-shop-ghas-workshop](https://github.com/joshjohanning-org/juice-shop-ghas-workshop) TODO: update URL with universe repo
-2. Click on the **Use this template ▾** button.
-3. Make sure you have the **githubuniverseworkshops** organization selected.
+1. Navigate to URL: [https://github.com/ghuwsec1953/juice-shop-ghas-workshop](https://github.com/ghuwsec1953/juice-shop-ghas-workshop) 
+2. Click on the **Use this template ▾** button and select **Create a new repository**.
+3. Make sure you have the **ghuwsec1953** organization selected as the **Owner**.
 4. Name the repository **YOUR_USERNAME-juice-shop-ghas-workshop**.
-5. ❗️❗️ Make sure to check the box to **Include all branches**. The other branches are required in order to complete the workshop. ❗️❗️
-6. Click the green **Create repository** button to create the repository
+5. Set the repository visibility to **Internal**.
+6. Click the green **Create repository** button to create the repository.
 
 Once the repository is created, you will be automatically redirected to it.  Continue on to Exercise 2.
 
@@ -40,9 +40,10 @@ In this exercise, you will be guided through the process of enabling the remaini
 ### Exercise 2.2: Enable Code Scanning
 
 1. Next, let's enable **Code Scanning with CodeQL**. These settings are also under the **Code security** settings page.
-2. Underneath the GitHub Advanced Security | Code Scanning heading, click the **Set up** button in the **CodeQL analysis** row.
-3. There are two options: **Default** and **Advanced**. For this lab, we will use the **Default** setup which creates a workflow behind the scenes (i.e. you will not see it committed to the repo). You can use the Advanced option to manage your code scanning workflow as a GitHub Actions workflow YAML file committed to the repo.
-4. Select the **Default** option, review the settings. By default, we will scan the JavaScript code, use the default CodeQL queries (for highest precision), and scan the default branch on push, pull request, and on a weekly schedule.
+2. Click the **Enable** button next to GitHub Advanced Security if it is not enabled. If prompted, then click the **Enable GitHub Advanced Security for this repository** button.
+3. Underneath the GitHub Advanced Security | Code Scanning heading, click the **Set up** button in the **CodeQL analysis** row.
+4. There are two options: **Default** and **Advanced**. For this lab, we will use the **Default** setup which creates a workflow behind the scenes (i.e. you will not see it committed to the repo). You can use the Advanced option to manage your code scanning workflow as a GitHub Actions workflow YAML file committed to the repo.
+5. Select the **Default** option and review the settings. By default, we will scan the JavaScript code (it may suggest Python as well), use the default CodeQL queries (for highest precision), and scan the default branch on push, pull request, and on a weekly schedule.
 
 <details>
   <img src="images/lab-1-2-1.png"/>
@@ -68,7 +69,7 @@ In this exercise, you will be guided through the process of enabling the remaini
 ### Exercise 2.3: Enable Secret Scanning
 
 1. If it's not already enabled, click on the **Enable** button to enable Secret Scanning.
-2. Check the box to **Use AI detection to find additional secrets (beta)**. This feature uses AI to find secrets/passwords that may be in your code that don't correspond to a known provider pattern.
+2. Check the box to **Scan for generic secrets**. This feature uses AI to find secrets/passwords that may be in your code that don't correspond to a known provider pattern.
 3. Click the **Enable** button next to the **Validity checks** setting. This feature checks if the secret is still valid for [specific partners](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/introduction/supported-secret-scanning-patterns#high-confidence-patterns), such as AWS and, of course, GitHub. As an example, you can use this feature to check if a GitHub personal access token found in the repo is still valid and needs to be revoked.
 4. Click the **Enable** button next to the **Non-provider patterns** setting. This scans for patterns that don't correspond to partners but still have a common syntax, such as a MySQL or MongoDB connection string.
 5. Click the **Enable** button next to the "Push protection" setting. This feature will block pushes that contain high-precision secrets. You can use this [chart](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/introduction/supported-secret-scanning-patterns#supported-secrets) to determine which types of secrets would be blocked with secret scanning push protection enabled.

_labs/images/lab-2-2-4.png

@@ -4,9 +4,9 @@ Now that we have all of the security feature enabled, let's review the security
 
 This lab covers parts of the following exam domains:
 
-Domain 2: Configure and use secret scanning
-Domain 3: Configure and use dependency management
-Domain 4: Configure and use code scanning
+- Domain 2: Configure and use secret scanning
+- Domain 3: Configure and use dependency management
+- Domain 4: Configure and use code scanning
 
 ## Exercise 1: Reviewing Dependabot alerts
 
@@ -42,9 +42,8 @@ Domain 4: Configure and use code scanning
 5. You can manually close an alert by clicking on the **Dismiss alert** button in the upper right hand corner. It's not recommended to close alerts manually, but there may be times where this is helpful (for example, the code that contains the alert is not used).
     - If you resolve an alert by upgrading to a non-vulnerable version, Dependabot will automatically close the alert!
 6. If there is a non-vulnerable package version to update to, you will see a **Create Dependabot security update** button to queue Dependabot to attempt to create a pull request automatically to upgrade the vulnerable dependency. With this feature, assuming your build and tests pass, you can merge the pull request to close the alert.
-    - TODO: Do we want to have them actually do this? or do you think showing/telling them about it is good. enough. Right now I think showing/telling is good enough. We can always add steps to have them do it if we need to lengthen the labs
 7. Go **back** to the prior page and let's take a look at the list of Dependabot alerts again.
-8. We can filter by **Package**, **Ecosystem**, **Manifest**, and **Severity**. For example, sometimes upgrading just one package can resolve multiple security alerts, so this can be a great way to prioritize fixes.
+8. We can filter by **Package**, **Ecosystem**, **Manifest**, and **Severity**. For example, sometimes upgrading just one package can resolve multiple security alerts, so this can be a great way to prioritize fixes. You can see this, if you enabled Dependabot security updates, by the fact that multiple Dependabot alerts are tied to the same PR.
 
 <details>
   <img src="images/lab-2-1-4.png"/>
@@ -93,15 +92,21 @@ Domain 4: Configure and use code scanning
 9. Oftentimes, there will be a lot of information to help understand the vulnerability and how to fix it. There should be a **Show more** expandable section that will show more information about the type of vulnerability you're working with.
 10. In the upper right-hand corner, there is a **Generate fix** button to use Copilot to generate a fix for the vulnerability. Click it! This is a great way to learn how to fix the vulnerability and to see how to fix it in the context of your code.
 11. It will take a little time to generate a suggestion. Wait for it to finish.
-12. If you're happy with the suggestion, click the **Create PR with fix** button. 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 merge the PR.
+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 and merge it.
 
 <details>
   <img src="images/lab-2-2-4.png"/>
 </details>
 
-13. The nice thing with code scanning alerts (just like Dependabot alerts) is that once you merge the code that resolves an alert, the alert will be automatically closed. This is because the alert is no longer present in the code. After merging the code into the default branch, a code scan will run and once it finishes, the alert will be closed. You can test this by merging the pull request we just created! It will take a few minutes for the code scanning to run and close the alert
-14. If you did merge the pull request, check back on the list of code scanning alerts under the **Security** tab in the repo. Once the code scan finishes running, you should see one (1) **Closed** alert listed.
-    - #TODO: May have to flesh this out more (see comment: https://github.com/joshjohanning-org/universe2024-ghas-workshop/pull/1/files#r1760207693)
+13. The nice thing with code scanning alerts (just like Dependabot alerts) is that once you merge the code that resolves an alert, the alert will be automatically closed. This is because the alert is no longer present in the code. After merging the code into the default branch, a code scan will run and once it finishes, the alert will be closed. You can test this by merging the pull request we just created! It will take a few minutes for the code scanning to run and close the alert.
+14. Click the **Ready for review** button on the pull request. This moves the pull request out of the draft state
+15. Click the **Merge pull request button**, followed by the **Confirm merge** button.
+16. Let's go watch the workflow run. Select the **Actions** tab at the top of the page.
+17. 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.
+18. Click the running workflow to see the details of the run.
+19. 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.
 
 > [!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.

_labs/lab1.md

@@ -17,20 +17,49 @@ Domain 6: Describe GitHub Advanced Security best practices
 </details>
 
 2. Give it a few moments to load the repository. Codespaces allows you full access to a cloud compute environment to develop and debug your code. It's a great way to get started with a project quickly and to contribute to open source projects.
-3. Switch to the `lab3/code-scanning-vulnerability` branch. This branch has a commit with an intentional security vulnerability in it. To switch branches, you can:
-    - In the lower left of the Codespace, click on `main` and pick the branch.
-    - Otherwise, in a terminal (CTRL/CMD + `` ` `` ) and enter: `git checkout lab3/code-scanning-vulnerability`
-4. Open the `routes/login.ts` file. This file has a security vulnerability in it.
-5. Highlight line 36. Let's ask Copilot Chat to explain this line of code. With line 36 highlighted, **right click --> Copilot --> Explain**.
+3. Now Josh has given you a new piece of code to add to the **routes/login.ts** file.
+4. We need to create a new branch. Click **main** in the taskbar at the bottom of VSCode.
+5. Select **Create new branch**, enter **lab3/code-scanning-vulnerability**, and hit Enter. The branch will be created and VSCode will switch to the branch.
+6. Open the **routes/login.ts** file.
+7. Find lines 36-46 and delete them
+
+```
+models.sequelize.query(
+      'SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL',
+      {
+        replacements: {
+          email: req.body.email || '',
+          password: security.hash(req.body.password || '')
+        },
+        model: UserModel,
+        plain: true
+      }
+    )
+```
+
+8. At line 36, add the following code:
+
+```
+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 })
+```
+
+9. You know what? Maybe we should double-check this code from Josh. Highlight line 36. Let's ask Copilot Chat to explain this line of code. With line 36 highlighted, **right click** on the line and select **Copilot --> Explain**.
 
 <details>
   <img src="images/lab-3-1-2.png"/>
 </details>
 
-6. Copilot chat should open up and explain what this line is doing. And oh no, read it thoroughly - it tells us we have a vulnerability! 😱
-7. We can ask Copilot chat how we could fix it. Better yet, do this: right click on line 36 and select **Copilot --> Fix**. ❗️❗️ We don't want to save anything though, so just review the fix for now. ❗️❗️
-8. Let's create a pull request for this branch to attempt to merge it into main.
+10. Copilot chat should open up and explain what this line is doing. And oh no, read it thoroughly - it tells us we have a vulnerability! 😱
+11. We can ask Copilot chat how we could fix it. Better yet, do this: right click on line 36 and select **Copilot --> Fix**. ❗️❗️ We don't want to save anything though, so just review the fix for now. Don't accept this change, discard it.❗️❗️
+12. Let's push our new branch and changes up to GitHub. Select the **Source Control** extension on the left side of Visual Studio Code
+13. Click the **+** button next to **login.ts** to stage the changes
+14. Add a commit message and click **Commit**.
+15. Click **Publish Branch** to push your new branch with the code changes to GitHub.
+16. Let's create a pull request for this branch to attempt to merge it into main.
     - In another browser tab, navigate back to the repository --> **Pull requests** tab --> **New pull request** button --> select the `lab3/code-scanning-vulnerability` to merge into `main`.
+    - Click **Create pull request**
+    - In the pull request description, click the Copilot icon on the bar and have Copilot generate a pull request summary for you.
+    - Click **Create pull request**
 9. 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.
 
 <details>
@@ -39,15 +68,15 @@ Domain 6: Describe GitHub Advanced Security best practices
 
 10. CodeQL should find the vulnerability, so the check will fail. Also, we should see Copilot create us an autofix on the PR that we can review.
 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.
+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.**
 
 <details>
   <img src="images/lab-3-1-4.png"/>
 </details>
 
 ## Exercise 2: Creating a code scanning ruleset
 
-Without a ruleset (GitHub's newer version of branch protections), even though CodeQL found the vulnerability, a developer could still merge the code mistakenly, or merge the code before the CodeQL checks finish. Let's prevent this!
+Without a ruleset (GitHub's new version of branch protections), even though CodeQL found the vulnerability, a developer could still merge the code mistakenly, or merge the code before the CodeQL checks finish. Let's prevent this!
 
 > [!NOTE]  
 > We have to wait for the PR check to finish entirely (with a pass or fail) in order to create the ruleset properly!

_labs/lab2.md

@@ -4,8 +4,8 @@ With Dependency Review enabled and configured, we want to block vulnerable packa
 
 This lab covers parts of the following exam domains:
 
-Domain 3: Configure and use dependency management
-Domain 6: Describe GitHub Advanced Security best practices
+- Domain 3: Configure and use dependency management
+- Domain 6: Describe GitHub Advanced Security best practices
 
 ## Exercise 1: Add the Dependency Review Action
 
@@ -22,7 +22,7 @@ First, let's add the dependency review action workflow.
 
 5. Review the action and its defaults on line 32-39. This action can also block specific open source license types.
 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**) the 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.
 
 <details>
   <img src="images/lab-4-1-2.png"/>
@@ -54,7 +54,7 @@ First, let's add the dependency review action workflow.
   <img src="images/lab-4-1-5.png"/>
 </details>
 
-17. Save the ruleset.
+17. Save the changes to the ruleset.
 
 ## Exercise 2: Introduce a dependency vulnerability
 
@@ -68,21 +68,31 @@ Now, let's attempt to add a vulnerable dependency to the codebase and test out t
 </details>
 
 3. Navigate back to the **Code** tab in the repo.
-4. Switch to the `lab4/dependency-vulnerability` branch.
+4. Click the **package.json** file to open it
+5. Click the pencil icon at the top right of the file to go into edit mode
+6. Go to the end of line 181 and hit Enter to create a blank line for line 182
+7. Add the following code to line 182:
+
+```
+"tar": "2.2.2",
+```
+
+8. Click the **Commit changes** button.
+9. Change the branch name to **lab4/dependency-vulnerability** and click **Propose changes** to start a pull request
+10. Switch to the `lab4/dependency-vulnerability` branch.
     - You can change to this branch by selecting the **main** dropdown below the repository name when under the **Code** tab.
-5. Open up the `package.json` file in the repository root.
-6. Navigate to line 182 and review this line - this branch has a change to introduce the `"tar": "2.2.2"` package to the codebase - a package with a known vulnerability.
+11. Open up the `package.json` file in the repository root.
+12. Navigate to line 182 and review this line - this branch has a change to introduce the `"tar": "2.2.2"` package to the codebase - a package with a known vulnerability.
 
 <details>
   <img src="images/lab-4-2-2.png"/>
 </details>
 
 7. Create a pull request by navigating the the **Pull requests** tab and clicking on the **New pull request** button.
-8. Make sure to select the `lab4/dependency-vulnerability` branch to merge into the `main` branch. Also make sure to use Copilot to generate a PR summary for you
-   If you scroll down to the status check section of the PR, you should see a note: "This branch is out-of-date with the base branch".
-10. Click on the **Update branch** button; this adds in the dependency review workflow you committed in the prior exercise. TODO: verify this works correctly
-11. Wait for the dependency review job to finish.
-12. It should make a comment to the pull request with a note that it found a vulnerable package dependency. In fact, adding this one vulnerable package would introduce 3 new vulnerabilities to our codebase.
+8. Use Copilot 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 vulnerable package would introduce 3 new vulnerabilities to our codebase.
 
 <details>
   <img src="images/lab-4-2-3.png"/>