From 5a2976e11607444d0c272e6de32cbe80df38ab1d Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Fri, 12 Apr 2024 12:19:25 -0400 Subject: [PATCH 1/9] add knowledge base article --- _kbarticlespages/repository-best-practices.md | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 _kbarticlespages/repository-best-practices.md diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md new file mode 100644 index 000000000..ac9627232 --- /dev/null +++ b/_kbarticlespages/repository-best-practices.md @@ -0,0 +1,67 @@ +--- +layout: post +title: "GitHub Repository Best Practices" +date: April 16, 2024 +excerpt: Pages guide for mainitning GitHub hosted repositories +--- + +Adhering to a set of best practices when it comes to managing GitHub repositories can greatly ease the maintenance burden and drastically improve the developer experience for websites hosted on cloud.gov Pages. It must be stated that this document should serve as a constructive conversation piece for agencies and not as an audit mechanism. Although by utilizing certain code scanning tools agencies may find it easier to identify and cover certain security controls within their respective Customer Responsibility Matrix (CRM). Here is a useful guide for you to get started with implementing some best practices regarding user permissions and security for your GitHub hosted repositories. + +## **Public vs Private repositories** + +A repository does *not need* to be public in order for Pages to be able to build the website, both public and private repositories are acceptable. When it comes to Pages there are certainly some unique considerations for each. + + #### **Public** + +##### **Pros** + - Easy for Pages engineers to access the codebase and provide support/debug + - Transparency/High visibility + - Able to utilize CodeQL free of charge + - Seamless OpenSSF Allstar integration + - Collaboration with outside contributors + - Compliance with open source and transparency initiatives per agency/ program + +##### **Cons** + - Any sensitive information inadvertently hardcoded is immediately visible + +#### **Private** + +##### **Pros** + - Restrict access to authorized collaborators and contributors (for any support issues a Pages engineer will request to be added as a collaborator to the repository if necessary) + - Risk mitigation + - Test/Make changes to a website without exposing commits to the public + - Safeguard against any potential leaks of sensitive information + +##### **Cons** + - Not able to utilize CodeQL for free + - Potentially out of compliance with any agency/program transparency initiative + +## **User Permissions** + +It is important to designate admin/owner access of the repository to an individual(s) who is either the persistent site owner or a federal employee with the “manager” role within the Pages organization. It is strongly recommended to not grant admin/owner privileges of the repository to any contractors or other temporary employees. This is such due to certain instances where actions will need to be taken by either Pages engineers or customers where it will be necessary to have an active user with admin access to a website's repository. Additionally when adding contributors/collaborators to a private repository it should mirror the member count that your organization has within Pages. Please note that removing an organization member from an organization within Pages will **not** automatically remove them from the repository within GitHub. They will still retain whatever read/write access they have in GitHub until explicitly removed. + + +## **Security** + +### Dependabot + +Dependabot is a useful and highly configurable automated dependency management tool which assists developers with keeping third-party dependencies up-to-date with their latest version. It can be extremely beneficial to smaller agencies whose developer teams are limited or in some cases a single developer by reducing maintenance overhead. It scans the repository for outdated dependencies and generates pull requests against whatever branch it is enabled on to update them. Check out our [knowledge base article on Dependabot](https://cloud.gov/pages/knowledge-base/dependabot-with-pages/#configuring-dependabot) to view how to enable and configure it for your repository. + +### Branch Protection + +[Branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) is a security feature within GitHub that limits users with write and push access the ability to push directly to any branch where branch protections are enabled. This includes but is not limited to requiring a pull request to merge code, setting the number of pull request reviews required, requiring status checks, dismissing approvals and other configuration options. With good branch protection settings you can protect your repository from an attack by a malicious actor with the stolen credentials from a single maintainer of that repository. + + +#### *Advanced Feature Settings for GitHub Repository Security* + +### OpenSSF Allstar + +[Allstar](https://github.com/ossf/allstar?tab=readme-ov-file#disabling-unwanted-issues-1) is an open source security tool which monitors organizations and repositories within GitHub for adherence to security best practices and improves the security posture for those organizations. It achieves this by continuously scanning repositories for any breach of enabled [security policies](https://github.com/ossf/allstar?tab=readme-ov-file#policies) and then raising an alert for any security remediation findings. An alert can be a GitHub issue or another type of configured action and in some instances it can automatically resolve the issue on the admin/owners behalf. + +### CodeQL + +[CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning), a GitHub open source security application, is a code analysis tool that automatically finds security vulnerabilities and other software bugs in codebases. Although primarily used for security analysis it can also be used for general code quality analysis as well. It is important to again note that CodeQL is only free to use on public repositories and GitHub Advanced Security must be purchased/enabled in order to utilize the tool on private repositories. + +### Signed Commits + +In conjunction with good user permissions practices and as an added layer of security you can ensure that only commits by members of your Pages organization are made to the repository by having them signed and then verified by GitHub. This increases the authenticity and integrity of your repositories' commit history, especially for those repositories which are public facing. There are various methods when it comes to implementing [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) so be sure to review them in full detail. \ No newline at end of file From d11186a29a6fd44ff02568abeb99fa143d0c86ab Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Fri, 12 Apr 2024 14:01:24 -0400 Subject: [PATCH 2/9] fix date --- _kbarticlespages/repository-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index ac9627232..55b0ca8f6 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -1,7 +1,7 @@ --- layout: post title: "GitHub Repository Best Practices" -date: April 16, 2024 +date: April 12, 2024 excerpt: Pages guide for mainitning GitHub hosted repositories --- From 34a543fe4c8e8827e68de0d45ec889d1f3408020 Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Fri, 12 Apr 2024 15:56:37 -0400 Subject: [PATCH 3/9] copy/edit --- _kbarticlespages/repository-best-practices.md | 26 ++++++++++--------- 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index 55b0ca8f6..993f513be 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -2,16 +2,17 @@ layout: post title: "GitHub Repository Best Practices" date: April 12, 2024 -excerpt: Pages guide for mainitning GitHub hosted repositories +excerpt: Pages guide for maintaining GitHub hosted repositories --- -Adhering to a set of best practices when it comes to managing GitHub repositories can greatly ease the maintenance burden and drastically improve the developer experience for websites hosted on cloud.gov Pages. It must be stated that this document should serve as a constructive conversation piece for agencies and not as an audit mechanism. Although by utilizing certain code scanning tools agencies may find it easier to identify and cover certain security controls within their respective Customer Responsibility Matrix (CRM). Here is a useful guide for you to get started with implementing some best practices regarding user permissions and security for your GitHub hosted repositories. +Adhering to a set of best practices when it comes to managing GitHub repositories can greatly ease the maintenance burden and drastically improve the developer experience for websites hosted on cloud.gov Pages. This document should serve as a constructive conversation piece for agencies and not as an audit mechanism. But by utilizing certain code scanning tools, agencies may find it easier to identify and cover certain security controls within their respective Customer Responsibility Matrix (CRM). Here is a useful guide for you to get started with implementing some best practices regarding user permissions and security for your GitHub hosted repositories. ## **Public vs Private repositories** -A repository does *not need* to be public in order for Pages to be able to build the website, both public and private repositories are acceptable. When it comes to Pages there are certainly some unique considerations for each. +A repository does *not need* to be public in order for Pages to be able to build the website; both public and private repositories are acceptable. When it comes to Pages there are certainly some unique considerations for each. + +#### **Public** - #### **Public** ##### **Pros** - Easy for Pages engineers to access the codebase and provide support/debug @@ -19,13 +20,14 @@ A repository does *not need* to be public in order for Pages to be able to build - Able to utilize CodeQL free of charge - Seamless OpenSSF Allstar integration - Collaboration with outside contributors - - Compliance with open source and transparency initiatives per agency/ program + - Compliance with open source and transparency initiatives per agency/program ##### **Cons** - Any sensitive information inadvertently hardcoded is immediately visible #### **Private** + ##### **Pros** - Restrict access to authorized collaborators and contributors (for any support issues a Pages engineer will request to be added as a collaborator to the repository if necessary) - Risk mitigation @@ -34,29 +36,29 @@ A repository does *not need* to be public in order for Pages to be able to build ##### **Cons** - Not able to utilize CodeQL for free - - Potentially out of compliance with any agency/program transparency initiative + - Potentially out of compliance with agency/program transparency initiatives -## **User Permissions** +## **Repository User Permissions** -It is important to designate admin/owner access of the repository to an individual(s) who is either the persistent site owner or a federal employee with the “manager” role within the Pages organization. It is strongly recommended to not grant admin/owner privileges of the repository to any contractors or other temporary employees. This is such due to certain instances where actions will need to be taken by either Pages engineers or customers where it will be necessary to have an active user with admin access to a website's repository. Additionally when adding contributors/collaborators to a private repository it should mirror the member count that your organization has within Pages. Please note that removing an organization member from an organization within Pages will **not** automatically remove them from the repository within GitHub. They will still retain whatever read/write access they have in GitHub until explicitly removed. +It is important to designate admin/owner access of the repository to one or more individuals who are either the persistent site owners or else federal employees with the “manager” role within the Pages organization. It is strongly recommended to not grant admin/owner privileges of the repository to any contractors or other temporary employees. This is because in certain instances where actions will need to be taken by either Pages engineers or by customers that require an active user with admin access to a website's repository. Additionally, when adding contributors or collaborators to a private repository it should mirror the member count that your organization has within Pages. Please note that removing an organization member from an organization within Pages will **not** automatically remove them from the repository within GitHub. They will still retain whatever read/write access they have in GitHub until explicitly removed. -## **Security** +## **GitHub Repository Security** ### Dependabot -Dependabot is a useful and highly configurable automated dependency management tool which assists developers with keeping third-party dependencies up-to-date with their latest version. It can be extremely beneficial to smaller agencies whose developer teams are limited or in some cases a single developer by reducing maintenance overhead. It scans the repository for outdated dependencies and generates pull requests against whatever branch it is enabled on to update them. Check out our [knowledge base article on Dependabot](https://cloud.gov/pages/knowledge-base/dependabot-with-pages/#configuring-dependabot) to view how to enable and configure it for your repository. +Dependabot is a useful and highly configurable automated dependency management tool which assists developers with keeping third-party dependencies up-to-date with their latest version. This can benefit smaller developer teams by reducing maintenance overhead. Dependabot scans the repository for outdated dependencies and generates pull requests against whatever branch it is enabled on to update them. Check out our [knowledge base article on Dependabot](https://cloud.gov/pages/knowledge-base/dependabot-with-pages/#configuring-dependabot) to learn how to enable and configure it for your repository. ### Branch Protection [Branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) is a security feature within GitHub that limits users with write and push access the ability to push directly to any branch where branch protections are enabled. This includes but is not limited to requiring a pull request to merge code, setting the number of pull request reviews required, requiring status checks, dismissing approvals and other configuration options. With good branch protection settings you can protect your repository from an attack by a malicious actor with the stolen credentials from a single maintainer of that repository. -#### *Advanced Feature Settings for GitHub Repository Security* +#### *Additional Advanced Feature Settings for GitHub Repository Security* ### OpenSSF Allstar -[Allstar](https://github.com/ossf/allstar?tab=readme-ov-file#disabling-unwanted-issues-1) is an open source security tool which monitors organizations and repositories within GitHub for adherence to security best practices and improves the security posture for those organizations. It achieves this by continuously scanning repositories for any breach of enabled [security policies](https://github.com/ossf/allstar?tab=readme-ov-file#policies) and then raising an alert for any security remediation findings. An alert can be a GitHub issue or another type of configured action and in some instances it can automatically resolve the issue on the admin/owners behalf. +[Allstar](https://github.com/ossf/allstar?tab=readme-ov-file#disabling-unwanted-issues-1) is an open source security tool which monitors organizations and repositories within GitHub for adherence to security best practices and improves the security posture for those organizations. It achieves this by continuously scanning repositories for any breach of enabled [security policies](https://github.com/ossf/allstar?tab=readme-ov-file#policies) and then raising an alert for any security remediation findings. This alert can be in the form of a GitHub issue or another type of configured action. In some instances Allstar can automatically resolve the issue on the admin/owner's behalf. ### CodeQL From 8d5982c3c811766cdcdbd923f48c30d20347e4b0 Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Fri, 12 Apr 2024 16:02:29 -0400 Subject: [PATCH 4/9] formatting --- _kbarticlespages/repository-best-practices.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index 993f513be..396e33864 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -11,10 +11,10 @@ Adhering to a set of best practices when it comes to managing GitHub repositorie A repository does *not need* to be public in order for Pages to be able to build the website; both public and private repositories are acceptable. When it comes to Pages there are certainly some unique considerations for each. -#### **Public** +### **Public** -##### **Pros** +#### **Pros** - Easy for Pages engineers to access the codebase and provide support/debug - Transparency/High visibility - Able to utilize CodeQL free of charge @@ -22,19 +22,19 @@ A repository does *not need* to be public in order for Pages to be able to build - Collaboration with outside contributors - Compliance with open source and transparency initiatives per agency/program -##### **Cons** +#### **Cons** - Any sensitive information inadvertently hardcoded is immediately visible -#### **Private** +### **Private** -##### **Pros** +#### **Pros** - Restrict access to authorized collaborators and contributors (for any support issues a Pages engineer will request to be added as a collaborator to the repository if necessary) - Risk mitigation - Test/Make changes to a website without exposing commits to the public - Safeguard against any potential leaks of sensitive information -##### **Cons** +#### **Cons** - Not able to utilize CodeQL for free - Potentially out of compliance with agency/program transparency initiatives From 4d4fb6ceb4283d7058de5397b7904786b2b4fba0 Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Tue, 23 Apr 2024 10:54:45 -0400 Subject: [PATCH 5/9] formatting --- _kbarticlespages/repository-best-practices.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index 396e33864..8dfbc97e6 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -53,13 +53,12 @@ Dependabot is a useful and highly configurable automated dependency management t [Branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) is a security feature within GitHub that limits users with write and push access the ability to push directly to any branch where branch protections are enabled. This includes but is not limited to requiring a pull request to merge code, setting the number of pull request reviews required, requiring status checks, dismissing approvals and other configuration options. With good branch protection settings you can protect your repository from an attack by a malicious actor with the stolen credentials from a single maintainer of that repository. - -#### *Additional Advanced Feature Settings for GitHub Repository Security* - ### OpenSSF Allstar [Allstar](https://github.com/ossf/allstar?tab=readme-ov-file#disabling-unwanted-issues-1) is an open source security tool which monitors organizations and repositories within GitHub for adherence to security best practices and improves the security posture for those organizations. It achieves this by continuously scanning repositories for any breach of enabled [security policies](https://github.com/ossf/allstar?tab=readme-ov-file#policies) and then raising an alert for any security remediation findings. This alert can be in the form of a GitHub issue or another type of configured action. In some instances Allstar can automatically resolve the issue on the admin/owner's behalf. +## *Additional Advanced Feature Settings for GitHub Repository Security* + ### CodeQL [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning), a GitHub open source security application, is a code analysis tool that automatically finds security vulnerabilities and other software bugs in codebases. Although primarily used for security analysis it can also be used for general code quality analysis as well. It is important to again note that CodeQL is only free to use on public repositories and GitHub Advanced Security must be purchased/enabled in order to utilize the tool on private repositories. From d92f9dadaebd85cac3671e74c870666ab836f7c0 Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Tue, 23 Apr 2024 11:47:34 -0400 Subject: [PATCH 6/9] update language --- _kbarticlespages/repository-best-practices.md | 22 +++++++++---------- 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index 8dfbc97e6..d10a1d560 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -1,20 +1,20 @@ --- layout: post title: "GitHub Repository Best Practices" -date: April 12, 2024 +date: April 23, 2024 excerpt: Pages guide for maintaining GitHub hosted repositories --- Adhering to a set of best practices when it comes to managing GitHub repositories can greatly ease the maintenance burden and drastically improve the developer experience for websites hosted on cloud.gov Pages. This document should serve as a constructive conversation piece for agencies and not as an audit mechanism. But by utilizing certain code scanning tools, agencies may find it easier to identify and cover certain security controls within their respective Customer Responsibility Matrix (CRM). Here is a useful guide for you to get started with implementing some best practices regarding user permissions and security for your GitHub hosted repositories. -## **Public vs Private repositories** +## Public vs Private repositories -A repository does *not need* to be public in order for Pages to be able to build the website; both public and private repositories are acceptable. When it comes to Pages there are certainly some unique considerations for each. +A repository does *not need* to be public in order for Pages to be able to build the website and there are no added website security benefits for private repositories; both public and private repositories are acceptable on Pages due to all branches, both public and private, being published publicly when built. When it comes to deciding whether to make your GitHub repository public or private you may consider the following items. -### **Public** +### Public -#### **Pros** +#### Pros - Easy for Pages engineers to access the codebase and provide support/debug - Transparency/High visibility - Able to utilize CodeQL free of charge @@ -22,17 +22,15 @@ A repository does *not need* to be public in order for Pages to be able to build - Collaboration with outside contributors - Compliance with open source and transparency initiatives per agency/program -#### **Cons** - - Any sensitive information inadvertently hardcoded is immediately visible +#### Cons + - Sensitive information inadvertently hardcoded in an website configuration file is visible -### **Private** +### Private -#### **Pros** - - Restrict access to authorized collaborators and contributors (for any support issues a Pages engineer will request to be added as a collaborator to the repository if necessary) - - Risk mitigation +#### Pros - Test/Make changes to a website without exposing commits to the public - - Safeguard against any potential leaks of sensitive information + - Safeguard sensitive data such as API keys, access tokens or other credentials in any configuration files #### **Cons** - Not able to utilize CodeQL for free From 796ad18f7348f17283285682ecbc588976e55de2 Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Tue, 23 Apr 2024 12:09:07 -0400 Subject: [PATCH 7/9] more formatting --- _kbarticlespages/repository-best-practices.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index d10a1d560..4665cf746 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -32,35 +32,35 @@ A repository does *not need* to be public in order for Pages to be able to build - Test/Make changes to a website without exposing commits to the public - Safeguard sensitive data such as API keys, access tokens or other credentials in any configuration files -#### **Cons** +#### Cons - Not able to utilize CodeQL for free - Potentially out of compliance with agency/program transparency initiatives -## **Repository User Permissions** +### Repository User Permissions It is important to designate admin/owner access of the repository to one or more individuals who are either the persistent site owners or else federal employees with the “manager” role within the Pages organization. It is strongly recommended to not grant admin/owner privileges of the repository to any contractors or other temporary employees. This is because in certain instances where actions will need to be taken by either Pages engineers or by customers that require an active user with admin access to a website's repository. Additionally, when adding contributors or collaborators to a private repository it should mirror the member count that your organization has within Pages. Please note that removing an organization member from an organization within Pages will **not** automatically remove them from the repository within GitHub. They will still retain whatever read/write access they have in GitHub until explicitly removed. -## **GitHub Repository Security** +### GitHub Repository Security -### Dependabot +#### Dependabot Dependabot is a useful and highly configurable automated dependency management tool which assists developers with keeping third-party dependencies up-to-date with their latest version. This can benefit smaller developer teams by reducing maintenance overhead. Dependabot scans the repository for outdated dependencies and generates pull requests against whatever branch it is enabled on to update them. Check out our [knowledge base article on Dependabot](https://cloud.gov/pages/knowledge-base/dependabot-with-pages/#configuring-dependabot) to learn how to enable and configure it for your repository. -### Branch Protection +#### Branch Protection [Branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) is a security feature within GitHub that limits users with write and push access the ability to push directly to any branch where branch protections are enabled. This includes but is not limited to requiring a pull request to merge code, setting the number of pull request reviews required, requiring status checks, dismissing approvals and other configuration options. With good branch protection settings you can protect your repository from an attack by a malicious actor with the stolen credentials from a single maintainer of that repository. -### OpenSSF Allstar +#### OpenSSF Allstar [Allstar](https://github.com/ossf/allstar?tab=readme-ov-file#disabling-unwanted-issues-1) is an open source security tool which monitors organizations and repositories within GitHub for adherence to security best practices and improves the security posture for those organizations. It achieves this by continuously scanning repositories for any breach of enabled [security policies](https://github.com/ossf/allstar?tab=readme-ov-file#policies) and then raising an alert for any security remediation findings. This alert can be in the form of a GitHub issue or another type of configured action. In some instances Allstar can automatically resolve the issue on the admin/owner's behalf. -## *Additional Advanced Feature Settings for GitHub Repository Security* +### Additional Advanced Feature Settings for GitHub Repository Security -### CodeQL +#### CodeQL [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning), a GitHub open source security application, is a code analysis tool that automatically finds security vulnerabilities and other software bugs in codebases. Although primarily used for security analysis it can also be used for general code quality analysis as well. It is important to again note that CodeQL is only free to use on public repositories and GitHub Advanced Security must be purchased/enabled in order to utilize the tool on private repositories. -### Signed Commits +#### Signed Commits In conjunction with good user permissions practices and as an added layer of security you can ensure that only commits by members of your Pages organization are made to the repository by having them signed and then verified by GitHub. This increases the authenticity and integrity of your repositories' commit history, especially for those repositories which are public facing. There are various methods when it comes to implementing [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) so be sure to review them in full detail. \ No newline at end of file From 8f872a856a88a19ce5659851c9974bda55a3e64b Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Mon, 29 Apr 2024 15:49:46 -0400 Subject: [PATCH 8/9] add clarifying language --- _kbarticlespages/repository-best-practices.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index 4665cf746..451017624 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -23,14 +23,15 @@ A repository does *not need* to be public in order for Pages to be able to build - Compliance with open source and transparency initiatives per agency/program #### Cons - - Sensitive information inadvertently hardcoded in an website configuration file is visible + - Sensitive information inadvertently hardcoded is immediately visible ### Private #### Pros - Test/Make changes to a website without exposing commits to the public - - Safeguard sensitive data such as API keys, access tokens or other credentials in any configuration files + - Safeguard sensitive data such as API keys, access tokens or other credentials in any configuration files by storing them as environment variables in `config.yml` for Jekyll sites or using `dotenv` to load values from a separate `.env` file for 11ty, Gatsby and Node.js websites as an additional layer of privacy. + *Websites on Pages are all published publicly, user's configuration settings and static site build engine factor into what is included in the site build output.* #### Cons - Not able to utilize CodeQL for free From 7903a407d0de185cf06e1de3cfe16782664a9198 Mon Sep 17 00:00:00 2001 From: Ephraim-G Date: Mon, 29 Apr 2024 16:27:50 -0400 Subject: [PATCH 9/9] link to pages env var doc --- _kbarticlespages/repository-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_kbarticlespages/repository-best-practices.md b/_kbarticlespages/repository-best-practices.md index 451017624..5edb63768 100644 --- a/_kbarticlespages/repository-best-practices.md +++ b/_kbarticlespages/repository-best-practices.md @@ -30,7 +30,7 @@ A repository does *not need* to be public in order for Pages to be able to build #### Pros - Test/Make changes to a website without exposing commits to the public - - Safeguard sensitive data such as API keys, access tokens or other credentials in any configuration files by storing them as environment variables in `config.yml` for Jekyll sites or using `dotenv` to load values from a separate `.env` file for 11ty, Gatsby and Node.js websites as an additional layer of privacy. + - Safeguard sensitive data such as API keys, access tokens or other credentials by [using environment variables](https://cloud.gov/pages/documentation/env-vars-on-pages-builds/) in the build runtime. *Websites on Pages are all published publicly, user's configuration settings and static site build engine factor into what is included in the site build output.* #### Cons