You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/github/maintain-secure-repository-github/4-knowledge-check.yml
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ title: Module assessment
4
4
metadata:
5
5
title: Module assessment
6
6
description: Check what you've learned.
7
-
ms.date: 04/22/2024
7
+
ms.date: 04/09/2025
8
8
author: a-a-ron
9
9
ms.author: aastewar
10
10
ms.topic: unit
@@ -18,7 +18,7 @@ quiz:
18
18
choices:
19
19
- content: "Configure your package files to always use the latest versions of dependencies."
20
20
isCorrect: false
21
-
explanation: "This practice is generally a bad idea because it can introduce breaking changes or unexpected behavior in your software."
21
+
explanation: "This practice is generally a bad idea, because it can introduce breaking changes or unexpected behavior in your software."
22
22
- content: "Check each project's security details closely before adding it to your dependencies by confirming its version status across multiple advisory sites."
23
23
isCorrect: false
24
24
explanation: "Even if this practice helps you start off with a secure version of a given dependency, it won't ensure that you're safe from future vulnerabilities. You would need to constantly monitor every package to ensure compliance, which might be infeasible."
Copy file name to clipboardExpand all lines: learn-pr/github/maintain-secure-repository-github/includes/2-how-to-maintain-secure-repository.md
+9-12Lines changed: 9 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,11 +25,11 @@ There are many aspects to building and deploying secure applications. Here are t
25
25
26
26
Security isn't something you can just add later to an application or a system. Secure development must be part of every stage of the software-development life cycle. This concept is even more important for critical applications and those applications that process sensitive or highly confidential information.
27
27
28
-
In practice, to hold teams accountable for what they develop, processes need to **shift left**, or be completed earlier, in the development lifecycle. By moving steps from a final gate at deployment time to an earlier step, fewer mistakes are made, and developers can move more quickly.
28
+
In practice, to hold teams accountable for what they develop, processes need to **shift left**, or be completed earlier in the development lifecycle. By moving steps from a final gate at deployment time to an earlier step, fewer mistakes are made, and developers can move more quickly.
29
29
30
30
Application-security concepts weren't a focus for developers in the past. Apart from the education and training issues, it's because their organizations emphasized fast development of features.
31
31
32
-
With the introduction of DevOps practices however, security testing is easier to integrate into the pipeline. Rather than being a task performed by security specialists, security testing should just be part of the day-to-day delivery processes.
32
+
However, with the introduction of DevOps practices, security testing is easier to integrate into the pipeline. Rather than being a task performed by security specialists, security testing should just be part of the day-to-day delivery processes.
33
33
34
34
Overall, when the time for rework is taken into account, adding security to your DevOps practices earlier in the development lifecycle allows development teams to catch issues earlier. Catching issues earlier can actually reduce the overall time it takes to develop quality software.
35
35
@@ -54,9 +54,6 @@ From the Security tab, you can add features to your GitHub workflow to help avoi
54
54
55
55
For more information, see [GitHub security features](https://docs.github.com/code-security/getting-started/github-security-features).
56
56
57
-
> [!NOTE]
58
-
> Dependabot alert advisories for malware are currently in beta and subject to change. Only advisories that have been reviewed by GitHub will trigger Dependabot alerts.
59
-
60
57
Next, we explore some of these features and learn ways to distribute security and operational responsibilities across all phases of the software-development lifecycle.
61
58
62
59
## Communicate a security policy with SECURITY.md
@@ -99,11 +96,11 @@ x86/
99
96
100
97
Your repository might include multiple `.gitignore` files. Settings are inherited from parent directories, with overriding fields in new `.gitignore` files taking precedence over parent settings for their folders and subfolders. It's significant effort to maintain the root `.gitignore` file, although adding a `.gitignore` file into a project directory can be helpful when that project has specific requirements that are easier to maintain separately from the parent, such as files that should *not* be ignored.
101
98
102
-
To learn more about `.gitignore`, see [Ignoring files](https://docs.github.com/get-started/getting-started-with-git/ignoring-files). Also check out the collection of starter `.gitignore` files offered for various platforms in the [gitignore repository](https://github.com/github/gitignore).
99
+
To learn more about `.gitignore`, see [Ignoring files](https://docs.github.com/get-started/git-basics/ignoring-files). Also check out the collection of starter `.gitignore` files offered for various platforms in the [gitignore repository](https://github.com/github/gitignore).
103
100
104
101
## Remove sensitive data from a repository
105
102
106
-
While `.gitignore` files can be useful in helping contributors avoid committing sensitive data, it's just a strong suggestion. Developers can still work around it to add files if they're motivated enough, and sometimes files might slip through because they don't meet the `.gitignore` file configuration. Project participants should always be on the lookout for commits that contain data that shouldn't be included in the repository or its history.
103
+
While `.gitignore` files can be useful in helping contributors avoid committing sensitive data, they're just a strong suggestion. Developers can still work around a `.gitignore` file to add files if they're motivated enough, and sometimes files might slip through because they don't meet the `.gitignore` file configuration. Project participants should always be on the lookout for commits that contain data that shouldn't be included in the repository or its history.
107
104
108
105
> [!IMPORTANT]
109
106
> You should assume that any data committed to GitHub at any point has been compromised. Simply overwriting a commit isn't enough to ensure the data won't be accessible in the future. For the complete guide to removing sensitive data from GitHub, see [Removing sensitive data from a repository](https://docs.github.com/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository).
@@ -114,14 +111,14 @@ You can create a [branch protection rule](https://docs.github.com/repositories/c
114
111
115
112
You can use the workflows that protect the branch to:
116
113
117
-
- Run a build to verify the code changes can be built
118
-
- Run a linter to check for typos and conformation to the internal coding conventions
119
-
- Run automated tests to check for any behavior changes of the code
120
-
- And so on
114
+
- Run a build to verify the code changes can be built;
115
+
- Run a linter to check for typos and conformation to the internal coding conventions;
116
+
- Run automated tests to check for any behavior changes of the code;
117
+
- And so on.
121
118
122
119
## Add a CODEOWNERS file
123
120
124
-
By adding a [CODEOWNERS](https://docs.github.com/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-code-owners#codeowners-syntax) file to your repository, you can assign individual team members or entire teams as code owners to paths in your repository. These code owners are then required for pull-request reviews on any changes to files in a path for which they're configured.
121
+
By adding a [CODEOWNERS](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax) file to your repository, you can assign individual team members or entire teams as code owners to paths in your repository. These code owners are then required for pull-request reviews on any changes to files in a path for which they're configured.
125
122
126
123
```
127
124
# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
Copy file name to clipboardExpand all lines: learn-pr/github/maintain-secure-repository-github/includes/3-security-automation.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ For the list of supported dependency manifests, see [About the dependency graph]
14
14
15
15
### Dependabot alerts
16
16
17
-
Even with a visual dependency graph, it can still be overwhelming to stay on top of the latest security considerations for every dependency a project has. To reduce this overhead, GitHub provides [Dependabot alerts](https://docs.github.com/code-security/dependabot/dependabot-alerts/about-dependabot-alerts#dependabot-alerts-for-vulnerable-dependencies) that watch your dependency graphs for you. It then cross-references target versions with versions on known vulnerability lists. When a risk is discovered, the project is alerted. Input for the analysis comes from [GitHub Security Advisories](https://docs.github.com/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories#dependabot-alerts-for-published-security-advisories).
17
+
Even with a visual dependency graph, it can still be overwhelming to stay on top of the latest security considerations for every dependency a project has. To reduce this overhead, GitHub provides [Dependabot alerts](https://docs.github.com/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) that watch your dependency graphs for you. It then cross-references target versions with versions on known vulnerability lists. When a risk is discovered, the project is alerted. Input for the analysis comes from [GitHub Security Advisories](https://docs.github.com/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories#dependabot-alerts-for-published-security-advisories).
18
18
19
19
20
20
@@ -34,12 +34,12 @@ You can enable code-scanning alerts and workflows in the security tab of a GitHu
34
34
35
35
:::image type="content" source="../media/security-overview.png" alt-text="Screenshot of a list of policies, advisories, and alerts with links to more information.":::
36
36
37
-
Learn more about [Code scanning and CodeQL](https://docs.github.com/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning#about-code-scanning).
37
+
Learn more about [Code scanning and CodeQL](https://docs.github.com/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning).
38
38
39
39
### Secret scanning
40
40
41
41
Another automated scanning feature within a GitHub repository is secret scanning. Similar to the previous security scanning features, secret scanning looks for known secrets or credentials committed within the repository. This scanning is done to prevent the use of fraudulent behavior and to secure the integrity of any sensitive data. By default, secret scanning occurs on public repositories and you can enable secret scanning on private repositories by repository administrators or organization owners.
42
42
43
43
When secret scanning detects a set of credentials, GitHub notifies the service provider who issued the secret. The service provider validates the credential. Then, it decides whether they should revoke the secret, issue a new secret, or reach out to you directly. The action depends on the associated risks to you or the service provider.
44
44
45
-
Learn more about [Secret scanning for public and private repositories](https://docs.github.com/code-security/secret-scanning/about-secret-scanning).
45
+
Learn more about [Secret scanning for public and private repositories](https://docs.github.com/code-security/secret-scanning/introduction/about-secret-scanning).
Copy file name to clipboardExpand all lines: learn-pr/github/maintain-secure-repository-github/includes/3-security-strategy-essentials.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ Here are some helpful tips before you begin the exercise:
10
10
- Stuck on what to do? Revisit the content in the last unit or check out the README file in the exercise's repository.
11
11
12
12
> [!NOTE]
13
-
> A grading script exists under `.github/workflows/grading.yml`. You don't need to modify this workflow to complete this exercise. **Altering the contents in this workflow can break the exercise's ability to validate your actions, provide feedback, or grade the results.**
13
+
> There's a grading script under `.github/workflows/grading.yml`. You don't need to modify this workflow to complete this exercise. **Altering the contents in this workflow can break the exercise's ability to validate your actions, provide feedback, or grade the results.**
14
14
15
15
This exercise is a challenge based on content covered in this module, and there could be more than one way to successfully complete the exercise. If you get stuck, revisit previous content in this module or navigate to some of the other resources provided.
-[Removing sensitive data from a repository](https://docs.github.com/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)
0 commit comments