Skip to content

Commit 20a08d6

Browse files
committed
Updating content for MSFT Ignite.
1 parent 99df5e5 commit 20a08d6

File tree

10 files changed

+65
-172
lines changed

10 files changed

+65
-172
lines changed

_labs/README.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,5 @@
55
3. [Lab 3 - Hands-on with Code Scanning (blocking vulnerable code from entering codebase and Copilot Autofix)](./lab3.md)
66
4. [Lab 4 - Hands-on with Dependency Review (blocking vulnerable dependencies from entering codebase)](./lab4.md)
77
5. [Lab 5 - Hands-on with Secret Scanning (secret scanning with push protections)](./lab5.md)
8-
6. [Lab 6 - Hands-on with Security Overview](./lab6.md)
9-
7. [Extra credit: Advanced CodeQL Setup](./lab7-ec.md)
10-
8. [Extra credit: Custom Patterns for Secret Scanning](./lab8-ec.md)
8+
6. [Extra credit: Advanced CodeQL Setup](./lab6-ec.md)
9+
7. [Extra credit: Custom Patterns for Secret Scanning](./lab7-ec.md)

_labs/lab1.md

Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -2,15 +2,18 @@
22

33
Welcome! In this lab, you will be introduced to GitHub Advanced Security (GHAS) and its features. You will use the Juice Shop sample repository to enable the GHAS features, manage alerts, and learn how GitHub Advanced Security can keep vulnerabilities out of your code in the first place.
44

5-
This lab covers parts of the following exam domains:
6-
7-
- Domain 2: Configure and use secret scanning
8-
- Domain 3: Configure and use dependency management
9-
- Domain 4: Configure and use code scanning
10-
115
> [!TIP]
126
> We recommend opening up two browser windows, one with the lab and one with the working copy of your repo!
137
8+
## Forking the repository
9+
10+
In this excerise, you will fork a repository with code from which you can work to test our the GHAS capabilities.
11+
12+
1. Navigate to [https://github.com/Ignite-GHAS-Workshop/ghas-workshop-repo](https://github.com/Ignite-GHAS-Workshop/ghas-workshop-repo) in your browser.
13+
2. Click the **Fork** button in the upper right corner of the page.
14+
3. Fork the repository to your personal account.
15+
4. Refresh the page a few seconds after you fork the repository to see the new repository in your account.
16+
1417
## Enabling the security settings
1518

1619
In the following exercises, you will be guided through the process of enabling the remaining GHAS features. Then you will be shown how to use the features to secure your code.
@@ -70,7 +73,7 @@ Although Dependabot isn't part of the GitHub Advanced Security product suite, it
7073
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 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.
7174
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.
7275
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.
73-
6. Optionally, configure **Who can bypass push protection for secret scanning**.
76+
6. Optionally, configure **Who can bypass push protection for secret scanning**.
7477
- 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).
7578
- You can change this to only allow select users/teams (or no one) to bypass secret scanning push protection.
7679
7. Note that you can define your own **Custom patterns** from this page to scan for secrets that don't correspond to a known provider pattern.

_labs/lab2.md

Lines changed: 1 addition & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -2,12 +2,6 @@
22

33
Now that we have all of the security feature enabled, let's review the security alerts that have been created and how to manage them.
44

5-
This lab covers parts of the following exam domains:
6-
7-
- Domain 2: Configure and use secret scanning
8-
- Domain 3: Configure and use dependency management
9-
- Domain 4: Configure and use code scanning
10-
115
## Exercise 1: Reviewing Dependabot alerts
126

137
1. Click the **Security** tab in the repo. This is where you can see and manage all of the security alerts for the repo.
@@ -114,6 +108,7 @@ This lab covers parts of the following exam domains:
114108
13. Accept the defaults and click **Commit change**.
115109
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.
116110
- 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.
111+
117112
<details>
118113
<img src="images/lab-2-2-4.png"/>
119114
</details>

_labs/lab3.md

Lines changed: 15 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -1,27 +1,12 @@
11
# Lab 3 - Hands-on with Code Scanning
22

3-
With Code Scanning enabled, we want to block vulnerable code from entering the codebase. We can define a repository ruleset to enforce this. Also, let's see how Copilot Autofix can help fix security vulnerabilities for us.
4-
5-
This lab covers parts of the following exam domains:
6-
7-
- Domain 4: Configure and use code scanning
8-
- Domain 5: Use code scanning with CodeQL
9-
- Domain 6: Describe GitHub Advanced Security best practices
3+
With Code Scanning enabled, we want to block vulnerable code from entering the codebase. We can define a repository ruleset to enforce this.
104

115
## Exercise 1: Introduce a code scanning security vulnerability
126

13-
1. Let's open up the repository in Codespaces! Navigate to the **Code** tab in the repo and click on the green **Code ▾** button. Then, click on **Codespaces** tab and **Create codespace on main**.
14-
15-
<details>
16-
<img src="images/lab-3-1-1.png"/>
17-
</details>
18-
19-
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.
20-
3. Now, Josh has given you a new piece of code to add to the `routes/login.ts` file.
21-
4. Before making the code change, let's create a new branch. Click **main** in the taskbar at the bottom of VSCode (the **main** that appears just to the right of your Codespaces name).
22-
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.
23-
6. Open the **routes/login.ts** file.
24-
7. Find lines 36-46 and delete them
7+
1. Navigate to the **routes/login.ts** file in your repository.
8+
2. Click the Pencil icon on the top right of the file view to edit the file.
9+
3. Find lines 36-46 and delete them
2510

2611
```diff
2712
- models.sequelize.query(
@@ -37,32 +22,21 @@ This lab covers parts of the following exam domains:
3722
- )
3823
```
3924

40-
8. At line 36, add the following code:
25+
4. At line 36, add the following code:
4126

4227
```javascript
4328
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 })
4429
```
4530

46-
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**.
47-
48-
<details>
49-
<img src="images/lab-3-1-2.png"/>
50-
</details>
51-
52-
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! 😱
53-
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, click on the **Discard** button.❗️❗️
54-
12. Let's push our new branch with the vulnerability up to GitHub. Select the **Source Control** extension on the left side of Visual Studio Code
55-
13. Click the **+** button next to **login.ts** to stage the changes
56-
14. Add a commit message and click **Commit**.
57-
15. Click **Publish Branch** to push your new branch with the code changes to GitHub.
58-
16. Let's create a pull request for this branch to attempt to merge it into main.
59-
- In another browser tab, navigate back to the repository.
60-
- Alternatively navigate back to the [workshop organization](https://github.com/ghuwsec1953) and find your repo.
61-
- Click the **Pull requests** tab --> **New pull request** button --> select the `lab3/code-scanning-vulnerability` to merge into `main`.
62-
- Click **Create pull request**
63-
- In the pull request description, click the Copilot icon on the formatting bar and have Copilot generate a pull request **summary** for you.
64-
- Click **Create pull request**
65-
17. 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.
31+
5. Let's push our new branch with the vulnerability up to GitHub.
32+
6. Click the green **Commit Changes** button on the top right of the file view.
33+
7. Keep the commit message the same, but feel free to add a description.
34+
8. Select the **Create a new branch for this commit and start a pull request** radio button.
35+
9. Keep the branch name at the default, which should be your GitHub handle followed by `-patch-1`.
36+
10. Click the **Propose changes** button.
37+
11. Click the **Create pull request** button at the bottom of the text field in the next view.
38+
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.
39+
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.
6640

6741
<details>
6842
<img src="images/lab-3-1-3.png"/>
@@ -110,7 +84,7 @@ Without a ruleset (GitHub's new version of branch protections), even though Code
11084
<img src="images/lab-3-2-3.png"/>
11185
</details>
11286

113-
9. Review the **Copilot Autofix suggestion** - it offers a similar suggestion to what Copilot in our IDE did!
87+
9. Review the **Copilot Autofix suggestion**.
11488
10. Click on the **commit suggestion** button and **commit changes**.
11589
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.
11690
- ➡️ 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**.

_labs/lab4.md

Lines changed: 0 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -2,11 +2,6 @@
22

33
With Dependency Review enabled and configured, we want to block vulnerable packages from entering the codebase. We can define a repository ruleset to enforce this as well!
44

5-
This lab covers parts of the following exam domains:
6-
7-
- Domain 3: Configure and use dependency management
8-
- Domain 6: Describe GitHub Advanced Security best practices
9-
105
## Exercise 1: Add the Dependency Review Action
116

127
First, let's add the dependency review action workflow.

_labs/lab5.md

Lines changed: 3 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -2,11 +2,6 @@
22

33
Let's use Secret Scanning with push protections to prevent secrets from entering the codebase!
44

5-
This lab covers parts of the following exam domains:
6-
7-
- Domain 2: Configure and use secret scanning
8-
- Domain 6: Describe GitHub Advanced Security best practices
9-
105
## Exercise 1: Attempt to commit a secret
116

127
1. Let's try to commit a secret to the repository to test out the secret scanning push protection feature.
@@ -18,24 +13,17 @@ This lab covers parts of the following exam domains:
1813
7. We don't need to give the token any scopes here - just give it a **name** and scroll down to the bottom and **Generate**.
1914
8. **Copy** the value of the token to the clipboard.
2015
- 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.
21-
9. Now, let's attempt to commit the token to the repository. You can do this in Codespaces or in the web browser.
16+
9. Now, let's attempt to commit the token to the repository.
2217
10. Any file would work, but for example, we can open up the `routes/login.ts` file we edited earlier.
2318
11. As an example, on line 18 you can add `const secret = "<YOUR TOKEN>";`, replacing `<YOUR TOKEN>` with the token you just generated - it should start with `ghp_`.
24-
12. Save and commit the file.
25-
- If making the changes in the UI, the push will happen as you commit.
26-
- If making the change in Codespaces, you will have to push separately to a non-main branch.
19+
12. Commit the file and then push the file to the repo.
2720
13. Push protection should detect the GitHub personal access token and block the push - great!
28-
1. If using the browser, you will see a message with a red banner that the push was blocked.
29-
2. If using Codespaces review the git output in the terminal. It should provide information on why the push was blocked (because of the secret scanning push protection).
30-
3. As a GitHub organization owner, you can add in a link that appears in the terminal output that links to a GitHub wiki, readme, etc. that explains to the developer on how to resolve the issue. For example, you can instruct the developer to run a `git reset HEAD~1`, where `1` is the number of commits they need to rewind in order to remove the commit with the secret.
21+
3122
<details>
3223
In the UI:</br><img src="images/lab-5-1-1.png"/></br></br>
33-
In an IDE/Codespaces:</br><img src="images/lab-5-1-2.png"/>
3424
</details>
3525

3626
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.
37-
15. BONUS: If you used the browser to commit a secret, switch to Codespaces and try to commit and push the secret. If you used Codespaces, try using the browser to commit and push the secret. See how the experience differs, but the end result is still the same: no secrets committed to the repository!
38-
16. BONUS BONUS: Ok, go ahead and push the secret anyway and see what happens. Did you get a secret scanning alert? If so, does the alert say the secret is valid?
3927

4028
## Summary
4129

_labs/lab6-ec.md

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
# Extra Credit - Lab 6 - Advanced CodeQL Setup
2+
3+
We set up Code Scanning with CodeQL using the default method. Now, let's try using 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)**!
4+
5+
## Exercise
6+
7+
Why might you want to use the advanced setup? Here are some reasons:
8+
9+
- More control over triggers and schedule
10+
- When pulling in packages from a private feed, you may have to provide instructions on authorizing to the NuGet, NPM, Maven, etc. feed.
11+
- For compiled languages, providing more instructions on how to build the code
12+
- Ability to customize the CodeQL configuration (such as query suites used)
13+
- Manage code scanning settings "as code"
14+
- Utilize 3rd party code scanning tooling
15+
16+
### Assignment
17+
18+
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 and Analysis** page.
19+
20+
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.
21+
22+
## Summary
23+
24+
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.
25+
26+
➡️ Head back to the [labs](README.md) page.

0 commit comments

Comments
 (0)