diff --git a/prowler/CHANGELOG.md b/prowler/CHANGELOG.md index 05c06d8d58..07b3e96f53 100644 --- a/prowler/CHANGELOG.md +++ b/prowler/CHANGELOG.md @@ -18,6 +18,7 @@ All notable changes to the **Prowler SDK** are documented in this file. - CIS Amazon Web Services Foundations Benchmark v7.0.0 compliance framework for the AWS provider, adding the new Organizations section (2.1.1-2.1.6), resource policy (2.21), web front-end access logging (4.10), and VPC Endpoints (6.8) recommendations [(#11707)](https://github.com/prowler-cloud/prowler/pull/11707) - CIS Microsoft Azure Foundations Benchmark v6.0.0 compliance framework for the Azure provider [(#11708)](https://github.com/prowler-cloud/prowler/pull/11708) - CIS Google Cloud Platform Foundation Benchmark v5.0.0 compliance framework for the GCP provider [(#11714)](https://github.com/prowler-cloud/prowler/pull/11714) +- CIS GitHub Benchmark v1.2.0 compliance framework for the GitHub provider [(#11719)](https://github.com/prowler-cloud/prowler/pull/11719) ### 🐞 Fixed diff --git a/prowler/compliance/github/cis_1.2.0_github.json b/prowler/compliance/github/cis_1.2.0_github.json new file mode 100644 index 0000000000..840b5aa3d8 --- /dev/null +++ b/prowler/compliance/github/cis_1.2.0_github.json @@ -0,0 +1,2574 @@ +{ + "Framework": "CIS", + "Name": "CIS GitHub Benchmark v1.2.0", + "Version": "1.2.0", + "Provider": "GitHub", + "Description": "This document provides prescriptive guidance for establishing a secure configuration posture for securing GitHub.", + "Requirements": [ + { + "Id": "1.1.1", + "Description": "Manage all code projects in a version control platform.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Manage all code projects in a version control platform.", + "RationaleStatement": "Version control platforms keep track of every modification to code. They represent the cornerstone of code security, as well as allowing for better code collaboration within engineering teams. With granular access management, change tracking, and key signing of code edits, version control platforms are the first step in securing the software supply chain.", + "ImpactStatement": "", + "RemediationProcedure": "Upload existing code projects to a dedicated Github organization and repositories and create an identity for each active team member who might contribute or need access to it.", + "AuditProcedure": "Ensure that all code activity is managed through Github repository for every micro-service or application developed by an organization.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.2", + "Description": "Use a task management system to trace any code back to its associated task.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Use a task management system to trace any code back to its associated task.", + "RationaleStatement": "The ability to trace each piece of code back to its associated task simplifies the Agile and DevOps process by enabling transparency of any code changes. This allows faster remediation of bugs and security issues, while also making it harder to push unauthorized code changes to sensitive projects. Additionally, using a task management system simplifies achieving compliance, as it is easier to track each regulation.", + "ImpactStatement": "", + "RemediationProcedure": "Use a task management system to manage tasks as the starting point for each code change. Whether it is a new feature, bug fix, or security fix - all should originate from a dedicated task (ticket) in your organization's task management system. These tasks should also be linked to the code changes themselves in a way that is easy to follow: from code to task, and from task back to code.", + "AuditProcedure": "Ensure every code change can be traced back to its origin task in a task management system.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.3", + "Description": "Ensure that every code change is reviewed and approved by two authorized contributors who are both strongly authenticated - using Multi-Factor Authentication (MFA), from the team relevant to the code change.", + "Checks": [ + "repository_default_branch_requires_multiple_approvals" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Automated", + "Description": "Ensure that every code change is reviewed and approved by two authorized contributors who are both strongly authenticated - using Multi-Factor Authentication (MFA), from the team relevant to the code change.", + "RationaleStatement": "To prevent malicious or unauthorized code changes, the first layer of protection is the process of code review. This process involves engineer teammates reviewing each other's code for errors, optimizations, and general knowledge-sharing. With proper peer reviews in place, an organization can detect unwanted code changes very early in the process of release. In order to help facilitate code review, companies should employ automation to verify that every code change has been reviewed and approved by at least two team members before it is pushed into the code base. These team members should be from the team that is related to the code change, so it will be a meaningful review.", + "ImpactStatement": "To enforce a code review requirement, verification for a minimum of two reviewers must be put into place. This will ensure new code will not be able to be pushed to the code base before it has received two independent approvals.", + "RemediationProcedure": "For every code repository in use, perform the next steps to require two approvals from the specific code repository team in order to push new code to the code base:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you added the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Check **Require a pull request before merging** and **Require approvals**, and set **Required number of approvals before merging** to 2.\n5. Click **Create** or **Save changes**.", + "AuditProcedure": "For every code repository in use, perform the next steps to verify that two approvals from the specific code repository team are required to push new code to the code base:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Require a pull request before merging** and **Require approvals** are checked, and verify that **Required number of approvals before merging** is set to 2.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "0" + } + ] + }, + { + "Id": "1.1.4", + "Description": "Ensure that when a proposed code change is updated, previous approvals are declined, and new approvals are required.", + "Checks": [ + "repository_default_branch_dismisses_stale_reviews" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure that when a proposed code change is updated, previous approvals are declined, and new approvals are required.", + "RationaleStatement": "An approval process is necessary when code changes are suggested. Through this approval process, however, changes can still be made to the original proposal even after some approvals have already been given. This means malicious code can find its way into the code base even if the organization has enforced a review policy. To ensure this is not possible, outdated approvals must be declined when changes to the suggestion are introduced.", + "ImpactStatement": "If new code changes are pushed to a specific proposal, all previously accepted code change proposals must be declined.", + "RemediationProcedure": "For each code repository in use, perform the next steps to enforce dismissal of given approvals to code change suggestions if those suggestions were updated:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you added the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Require pull request reviews before merging** and then **Dismiss stale pull request approvals when new commits are pushed**.\n5. Click **Create** or **Save changes**.", + "AuditProcedure": "For each code repository in use, perform the next steps to verify that each updated code suggestion declines the previously received approvals:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Require a pull request before merging** is checked, and verify that **Dismiss stale pull request approvals when new commits are pushed** is checked.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.5", + "Description": "Only trusted users should be allowed to dismiss code change reviews.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Only trusted users should be allowed to dismiss code change reviews.", + "RationaleStatement": "Dismissing a code change review permits users to merge new suggested code changes without going through the standard process of approvals. Controlling who can perform this action will prevent malicious actors from simply dismissing the required reviews to code changes and merging malicious or dysfunctional code into the code base.", + "ImpactStatement": "In cases where a code change proposal has been updated since it was last reviewed and the person who reviewed it isn't available for approval, a general collaborator would not be able to merge their code changes until a user with \"dismiss review\" abilities could dismiss the open review.\n\nUsers who are not allowed to dismiss code change reviews will not be permitted to do so, and thus are unable to waive the standard flow of approvals.", + "RemediationProcedure": "For each code repository in use, perform the next steps to restrict dismissal of code changes reviews unless it is necessary:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you added the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n4. Select **Require pull request reviews before merging** and **Restrict who can dismiss pull request reviews**.\n5. Do not add any user or team unless it is obligatory. If it is obligatory, carefully select the users or teams whom you trust with the ability to dismiss code change reviews.\n6. Click **Create** or **Save changes**.", + "AuditProcedure": "For each code repository in use, perform the next steps to verify that only trusted users are allowed to dismiss code change reviews: \n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n4. Verify that **Require a pull request before merging** and **Restrict who can dismiss pull request reviews** is checked.\n5. Verify that no users and teams are specified except for organization and repository admins. If it is obligatory, verify that the users or teams specified were carefully selected to be trusted with the ability to dismiss code change reviews.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "By default, all users who have write access to the code repository are able to dismiss code change reviews." + } + ] + }, + { + "Id": "1.1.6", + "Description": "Code owners are trusted users that are responsible for reviewing and managing an important piece of code or configuration. An organization is advised to set code owners for every extremely sensitive code or configuration.", + "Checks": [ + "repository_has_codeowners_file" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Code owners are trusted users that are responsible for reviewing and managing an important piece of code or configuration. An organization is advised to set code owners for every extremely sensitive code or configuration.", + "RationaleStatement": "Configuring code owners protects data by verifying that trusted users will notice and review every edit, thus preventing unwanted or malicious changes from potentially compromising sensitive code or configurations.", + "ImpactStatement": "Code owner users will receive notifications for every change that occurs to the code and subsequently added as reviewers of pull requests automatically.", + "RemediationProcedure": "In every code repository create a CODEOWNERS file in the root, docs/, or .github/ directory of the repository.\nIn the file, specify codeowners for the .github/workflows/ directory atleast. Specify organization members you trust. For example:\n```\n.github/workflows/ @user1 @user2\n```", + "AuditProcedure": "In every code repository, verify that a file named CODEOWNERS exists in the root, docs/, or .github/ directory of the repository.\nIn the CODEOWNERS file, verify that the users specified are users you trust.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners", + "DefaultValue": "None" + } + ] + }, + { + "Id": "1.1.7", + "Description": "Ensure trusted code owners are required to review and approve any code change proposal made to their respective owned areas in the code base.", + "Checks": [ + "repository_default_branch_requires_codeowners_review" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure trusted code owners are required to review and approve any code change proposal made to their respective owned areas in the code base.", + "RationaleStatement": "Configuring code owners ensures that no code, especially code which could prove malicious, will slip into the source code or configuration files of a repository. This allows an organization to mark areas in the code base that are especially sensitive or more prone to an attack. It can also enforce review by specific individuals who are designated as owners to those areas so that they may filter out unauthorized or unwanted changes beforehand.", + "ImpactStatement": "If an organization enforces code owner-based reviews, some code change proposals would not be able to be merged to the codebase before specific, trusted individuals approve them.", + "RemediationProcedure": "For every code repository in use, perform the following steps to require code owners' approvals for each change proposal related to code they own:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Require pull request reviews before merging** and **Require review from Code Owners**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For every code repository in use, perform the following steps to verify that code owners are required to review all code change proposals relevant to areas they own before code merge:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n4. Ensure that **Require a pull request before merging** and **Require review from Code Owners** are checked.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "Code owners are not required to review changes by default." + } + ] + }, + { + "Id": "1.1.8", + "Description": "Keep track of code branches that are inactive for a lengthy period of time and periodically remove them.", + "Checks": [ + "repository_inactive_not_archived", + "repository_branch_delete_on_merge_enabled" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Keep track of code branches that are inactive for a lengthy period of time and periodically remove them.", + "RationaleStatement": "Git branches that have been inactive (i.e., no new changes introduced) for a long period of time are enlarging the surface of attack for malicious code injection, sensitive data leaks, and CI pipeline exploitation. They potentially contain outdated dependencies which may leave them highly vulnerable. They are more likely to be improperly managed, and could possibly be accessed by a large number of members of the organization.", + "ImpactStatement": "Removing inactive Git branches means that any code changes they contain would be removed along with them, thus work done in the past might not be accessible after auditing for inactivity.", + "RemediationProcedure": "For each code repository in use, review existing Git branches and remove those which have not been active for a period of time by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Above the list of files, click **Branches**.\n3. Use the navigation at the top of the page to view the Stale branches. The Stale view shows all branches that no one has committed to in the last three months, ordered by the branches with the oldest commits first.\n4. For each branch listed, either delete it by clicking the trash bin icon, or find the valid reason it still exists.\n\nYou can perform the next steps to prevent pull request branches from becoming stale branches:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click Settings.\n3. Under \"Pull Requests\", select **Automatically delete head branches**.", + "AuditProcedure": "For each code repository in use, verify that all existing Git branches are active or have yet to be checked for inactivity by performing the next steps:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Above the list of files, click **Branches**.\n3. Use the navigation at the top of the page to view the Stale branches. The Stale view shows all branches that no one has committed to in the last three months, ordered by the branches with the oldest commits first.\n4. If the list is empty, you are compliant. If the list is not empty, but there is a valid reason the branches listed are not deleted, you are compliant.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "By default, newly opened Git branches would never be removed, regardless of activity or inactivity." + } + ] + }, + { + "Id": "1.1.9", + "Description": "Before a code change request can be merged to the code base, all predefined checks must successfully pass.", + "Checks": [ + "repository_default_branch_status_checks_required" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Before a code change request can be merged to the code base, all predefined checks must successfully pass.", + "RationaleStatement": "On top of manual reviews of code changes, a code protect should contain a set of prescriptive checks which validate each change. Organizations should enforce those status checks so that changes can only be introduced if all checks have successfully passed. This set of checks should serve as the absolute quality, stability, and security conditions which must be met in order to merge new code to a project.", + "ImpactStatement": "Code changes in which all checks do not pass successfully would not be able to be pushed into the code base of the specific code repository.", + "RemediationProcedure": "For each code repository in use, require all status checks to pass before permitting a merge of new code by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", check if there is a rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Require status checks to pass before merging**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For each code repository in use, verify that status checks are required to pass before allowing any code change proposal merge by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Require status checks to pass before merging** is checked.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "By default, no checks are defined per project, and thus no enforcement of checks is made." + } + ] + }, + { + "Id": "1.1.10", + "Description": "Organizations should make sure each suggested code change is in full sync with the existing state of its origin code repository before allowing merging.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Organizations should make sure each suggested code change is in full sync with the existing state of its origin code repository before allowing merging.", + "RationaleStatement": "Git branches can easily become outdated since the origin code repository is constantly being edited. This means engineers working on separate code branches can accidentally include outdated code with potential security issues which might have already been fixed, overriding the potential solutions for those security issues when merging their own changes.", + "ImpactStatement": "If enforced, outdated branches would not be able to be merged into their origin repository without first being updated to contain any recent changes.", + "RemediationProcedure": "For each code repository in use, enforce a policy to only allow merging open branches if they are current with the latest change from their original repository by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Require status checks to pass before merging** and **Require branches to be up to date before merging**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For each code repository in use, verify that open branches must be updated before merging is permitted by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Require status checks to pass before merging** and **Require branches to be up to date before merging** are checked.", + "AdditionalInformation": "", + "References": "https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/", + "DefaultValue": "By default, there is no requirement to update a branch before merging it." + } + ] + }, + { + "Id": "1.1.11", + "Description": "Organizations should enforce a \"no open comments\" policy before allowing code change merging.", + "Checks": [ + "repository_default_branch_requires_conversation_resolution" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Organizations should enforce a \"no open comments\" policy before allowing code change merging.", + "RationaleStatement": "In an open code change proposal, reviewers can leave comments containing their questions and suggestions. These comments can also include potential bugs and security issues. Requiring all comments on a code change proposal to be resolved before it can be merged ensures that every concern is properly addressed or acknowledged before the new code changes are introduced to the code base.", + "ImpactStatement": "Code change proposals containing open comments would not be able to be merged into the code base.", + "RemediationProcedure": "For each code repository in use, require open comments to be resolved before the relevant code change can be merged by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Require conversation resolution before merging**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For every code repository in use, verify that each merged code change does not contain open, unattended comments by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Require conversation resolution before merging** is checked.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "By default, code changes with open comments on them are able to be merged into the code \nbase." + } + ] + }, + { + "Id": "1.1.12", + "Description": "Ensure every commit in a pull request is signed and verified before merging.", + "Checks": [ + "repository_default_branch_requires_signed_commits" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Ensure every commit in a pull request is signed and verified before merging.", + "RationaleStatement": "Signing commits, or requiring to sign commits, gives other users confidence about the origin of a specific code change. It ensures that the author of the change is not hidden and is verified by the version control system, thus the change comes from a trusted source.", + "ImpactStatement": "Pull requests with unsigned commits cannot be merged.", + "RemediationProcedure": "For each repository in use, enforce the branch protection rule of requiring signed commits, and make sure only signed commits are capable of merging by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Require signed commits**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "Ensure only signed commits can be merged for every branch, especially the main branch, via branch protection rules by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Require signed commits** is checked.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.13", + "Description": "Linear history is the name for Git history where all commits are listed in chronological order, one after another. Such history exists if a pull request is merged either by rebase merge (re-order the commits history) or squash merge (squashes all commits to one). Ensure that linear history is required by requiring the use of rebase or squash merge when merging a pull request.", + "Checks": [ + "repository_default_branch_requires_linear_history" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Linear history is the name for Git history where all commits are listed in chronological order, one after another. Such history exists if a pull request is merged either by rebase merge (re-order the commits history) or squash merge (squashes all commits to one). Ensure that linear history is required by requiring the use of rebase or squash merge when merging a pull request.", + "RationaleStatement": "Enforcing linear history produces a clear record of activity, and as such it offers specific advantages: it is easier to follow, easier to revert a change, and bugs can be found more easily.", + "ImpactStatement": "Pull request cannot be merged except squash or rebase merge.", + "RemediationProcedure": "For every code repository in use, perform the following steps to require linear history and/or allow only rebase merge and squash merge:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Require linear history**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For every code repository in use, perform the following steps to verify that linear history is required and/or that only squash merge and rebase merge are allowed:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Require linear history** is checked.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.14", + "Description": "Ensure administrators are subject to branch protection rules.", + "Checks": [ + "repository_default_branch_protection_applies_to_admins" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure administrators are subject to branch protection rules.", + "RationaleStatement": "Administrators by default are excluded from any branch protection rules. This means these privileged users (both on the repository and organization levels) are not subject to protections meant to prevent untrusted code insertion, including malicious code. This is extremely important since administrator accounts are often targeted for account hijacking due to their privileged role.", + "ImpactStatement": "Administrator users won't be able to push code directly to the protected branch without being compliant with listed branch protection rules.", + "RemediationProcedure": "For every code repository in use, enforce branch protection rules on administrators as well, by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Do not allow bypassing the above settings**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For every code repository in use, validate branch protection rules also apply to administrator accounts by performing the next steps:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Do not allow bypassing the above settings** is checked.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule", + "DefaultValue": "Administrator accounts are not subject to branch protection rules by default." + } + ] + }, + { + "Id": "1.1.15", + "Description": "Ensure that only trusted users can push or merge new code to protected branches.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Ensure that only trusted users can push or merge new code to protected branches.", + "RationaleStatement": "Requiring that only trusted users may push or merge new changes reduces the risk of unverified code, especially malicious code, to a protected branch by reducing the number of trusted users who are capable of doing such.", + "ImpactStatement": "Only administrators and trusted users can push or merge to the protected branch.", + "RemediationProcedure": "For every code repository in use, allow only trusted and responsible users to push or merge new code by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4.Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Select **Restrict who can push to matching branches** and choose trusted and responsible users and teams who will have the permission to do so. \n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For every code repository in use, ensure only trusted and responsible users can push or merge new code by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Restrict who can push to matching branches** is checked and that only trusted and responsible users and teams are selected.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.16", + "Description": "The \"Force Push\" option allows users with \"Push\" permissions to force their changes directly to the branch without a pull request, and thus should be disabled.", + "Checks": [ + "repository_default_branch_disallows_force_push" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "The \"Force Push\" option allows users with \"Push\" permissions to force their changes directly to the branch without a pull request, and thus should be disabled.", + "RationaleStatement": "The \"Force Push\" option allows users to override the existing code with their own code. This can lead to both intentional and unintentional data loss, as well as data infection with malicious code. Disabling the \"Force Push\" option prohibits users from forcing their changes to the master branch, which ultimately prevents malicious code from entering source code.", + "ImpactStatement": "Users cannot force push to protected branches.", + "RemediationProcedure": "For each repository in use, block the option to \"Force Push\" code by performing the following:\n\nEnsure that Trunk / Long-standing branches are protected by Policies and submitted to PR while applying the 4-eyes approach.\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Uncheck **Allow force pushes**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For every code repository in use, validate that no one can force push code by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Allow force pushes** is not checked.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.17", + "Description": "Ensure that users with only push access are incapable of deleting a protected branch.", + "Checks": [ + "repository_default_branch_deletion_disabled" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure that users with only push access are incapable of deleting a protected branch.", + "RationaleStatement": "When enabling deletion of a protected branch, any user with at least push access to the repository can delete a branch. This can be potentially dangerous, as a simple human mistake or a hacked account can lead to data loss if a branch is deleted. It is therefore crucial to prevent such incidents by denying protected branch deletion.", + "ImpactStatement": "Protected branches cannot be deleted.", + "RemediationProcedure": "For each repository that is being used, block the option to delete protected branches by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, click **Add rule**.\n5. If you add the rule, under \"Branch name pattern\", type the branch name or pattern you want to protect.\n6. Uncheck **Allow deletions**.\n7. Click **Create** or **Save changes**.", + "AuditProcedure": "For each repository that is being used, verify that protected branches cannot be deleted by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", verify that there is at least one rule for your main branch. If there is, click **Edit** to its right. If there isn't, you are not compliant.\n5. Ensure that **Allow deletions** is not checked.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.18", + "Description": "Ensure that every pull request is required to be scanned for risks.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure that every pull request is required to be scanned for risks.", + "RationaleStatement": "Scanning pull requests to detect risks allows for early detection of vulnerable code and/or dependencies and helps mitigate potentially malicious code.", + "ImpactStatement": "", + "RemediationProcedure": "For every repository in use, enforce risk scanning on every pull request by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Actions**.\n3. If the repository already has at least one workflow set up and running, click **New workflow** and go to step 5. If there are currently no workflows configured for the repository, go to the next step.\n4. Scroll down to the \"Security\" category and click **Configure** under the workflow you want to configure or click **View all** to see all available security workflows.\n5. On the right pane of the workflow page, click **Documentation** and follow the on-screen instructions to tailor the workflow to your needs.", + "AuditProcedure": "For each repository in use, ensure that every pull request must be scanned for risks by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Actions**.\n3. Ensure that at least one workflow is configured to run like that: \n```\non:\n push:\n branches: [ \"main\" ]\n pull_request:\n branches: [ \"main\" ]\n```\nand that it has a step that runs code scanning on the code.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.19", + "Description": "Ensure that changes in the branch protection rules are audited.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure that changes in the branch protection rules are audited.", + "RationaleStatement": "Branch protection rules should be configured on every repository. The only users who may change such rules are administrators. In a case of an attack on an administrator account or of human error on the part of an administrator, protection rules could be disabled, and thus decrease source code confidentiality as a result. It is important to track and audit such changes to prevent potential incidents as soon as possible.", + "ImpactStatement": "", + "RemediationProcedure": "Use the audit log to audit changes in branch protection rules by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Archives\" section of the sidebar, click **Logs**, then click **Audit log**.\n4. Use the action qualifier in your query and look for **protected_branch** category. Ensure every action is reasonable and secure and investigate if not.", + "AuditProcedure": "Ensure changes in branch protection rules are audited by performing the following regularly:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Archives\" section of the sidebar, click **Logs**, then click **Audit log**.\n4. Use the action qualifier in your query and look for **protected_branch** category. Ensure every action is reasonable and secure and is investigated if not.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.1.20", + "Description": "Enforce branch protection on the default and main branch.", + "Checks": [ + "repository_default_branch_protection_enabled" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.1 Code Changes", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Enforce branch protection on the default and main branch.", + "RationaleStatement": "The default or main branch of repositories is considered very important, as it is eventually gets deployed to the production. Therefore it needs protection. By enforcing branch protection rules on this branch, it is secured from unwanted or unauthorized changes. It can also be protected from untested and unreviewed changes and more.", + "ImpactStatement": "", + "RemediationProcedure": "Perform the following to enforce branch protection on the main branch:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Next to \"Branch protection rules\", click **Add rule**.\n5. Under \"Branch name pattern\", type the branch name or pattern you want to protect. Ensure it applies to the main branch name.\n6. Configure policies you want.\n7. Click Create.", + "AuditProcedure": "Perform the following to ensure branch protection is enforced on the main branch:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Code and automation\" section of the sidebar, click **Branches**.\n4. Under **Branch protection rules**, verify that there is a rule applied to the \"main\" or default branch.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.2.1", + "Description": "A SECURITY.md file is a security policy file that offers instruction on reporting security vulnerabilities in a project. When someone creates an issue within a specific project, a link to the SECURITY.md file will subsequently be shown.", + "Checks": [ + "repository_public_has_securitymd_file" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.2 Repository Management", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "A SECURITY.md file is a security policy file that offers instruction on reporting security vulnerabilities in a project. When someone creates an issue within a specific project, a link to the SECURITY.md file will subsequently be shown.", + "RationaleStatement": "A SECURITY.md file provides users with crucial security information. It can also serve an important role in project maintenance, encouraging users to think ahead about how to properly handle potential security issues, updates, and general security practices.", + "ImpactStatement": "", + "RemediationProcedure": "Enforce that each public repository has a SECURITY.md file by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under the repository name, click **Security**.\n3. In the left sidebar, click **Security policy**.\n4. Click **Start setup**.\n5. In the new SECURITY.md file, add information about supported versions of your project and how to report a vulnerability.\n6. At the bottom of the page, type a commit message.\n7. Below the commit message fields, choose to create a new branch for your commit and then create a pull request.\n8. Click **Propose file change**.", + "AuditProcedure": "Verify that each public repository has a SECURITY.md file by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under the repository name, click **Security**.\n3. Verify that **Security policy** is enabled.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.2.2", + "Description": "Limit the ability to create repositories to trusted users and teams.", + "Checks": [ + "organization_repository_creation_limited" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.2 Repository Management", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Limit the ability to create repositories to trusted users and teams.", + "RationaleStatement": "Restricting repository creation to trusted users and teams is recommended in order to keep the organization properly structured, track fewer items, prevent impersonation, and to not overload the version-control system. It will allow administrators easier source code tracking and management capabilities, as they will have fewer repositories to track. The process of detecting potential attacks also becomes far more straightforward, as well, since the easier it is to track the source code, the easier it is to detect malicious acts within it. Additionally, the possibility of a member creating a public repository and sharing the organization's data externally is significantly decreased.", + "ImpactStatement": "Specific users will not be permitted to create repositories.", + "RemediationProcedure": "Restrict repository creation to trusted users and teams only by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Member privileges**.\n4. Under \"Repository creation\", unselect both options - **Public** and **Private**.\n5. Click **Save**.", + "AuditProcedure": "Verify that only trusted users and teams can create repositories by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Member privileges**.\n4. Under \"Repository creation\", ensure that **Public** and **Private** are not checked. This means only owners are able to create repositories.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.2.3", + "Description": "Ensure only a limited number of trusted users can delete repositories.", + "Checks": [ + "organization_repository_deletion_limited" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.2 Repository Management", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure only a limited number of trusted users can delete repositories.", + "RationaleStatement": "Restricting the ability to delete repositories protects the organization from intentional and unintentional data loss. This ensures that users cannot delete repositories or cause other potential damage — whether by accident or due to their account being hacked — unless they have the correct privileges.", + "ImpactStatement": "Certain users will not be permitted to delete repositories.", + "RemediationProcedure": "Enforce repository deletion by a few trusted and responsible users only by performing either of the following steps:\n\nIf Your organizations > Settings > Access > Member privileges > Allow members to delete or transfer repositories for this organization is selected, allow only trusted members to have admin privileges:\n1. In every repository, on GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings** and then in the \"Access\" section of the sidebar, click **Collaborators & teams**.\n3. Under \"Manage access\" use the dropdown **Role** menu to filter and search for admin members. Change their role by clicking the **Role** dropdown next to the username until there are only two trusted and qualified users with admin privileges. \n\nIf it is not selected, allow only trusted users to become an organization owner:\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Click the name of your organization and under your organization name, click **People**.\n3. You will see a list of the people in your organization. Click Role and select Owners. Check every member you want to change permissions to. Above the list of members, use the drop-down menu and click Change role and choose Member > change role. Do that until there are only a few trusted and qualified users with organization owner privileges. \n\nIn any case, only members with administrator or organization owner privileges can delete repositories, regardless of your setting.", + "AuditProcedure": "Verify that only a limited number of trusted users can delete repositories by performing either of the following steps:\n\nIf Your organizations > Settings > Access > Member privileges > Allow members to delete or transfer repositories for this organization is selected, verify that every admin member is trusted by you:\n1. In every repository, on GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings** and then in the \"Access\" section of the sidebar, click **Collaborators & teams**.\n3. Under \"Manage access\" use the dropdown **Role** menu to filter and search for admin members. Verify that there are only two of them and that they are trusted and qualified. \n\nIf it is not selected, verify that every organization owner is trusted by you:\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Click the name of your organization and under your organization name, click **People**.\n3. You will see a list of the people in your organization. Click Role and select Owners. Verify that there are only a few of them and that they are trusted and qualified. \n\nIn any case, only members with administrator or organization owner privileges can delete repositories, regardless of your setting.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "Only organization owners or members with admin privileges can delete repositories." + } + ] + }, + { + "Id": "1.2.4", + "Description": "Ensure only trusted and responsible users can delete issues.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.2 Repository Management", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure only trusted and responsible users can delete issues.", + "RationaleStatement": "Issues are a way to keep track of things happening in repositories, such as setting new milestones or requesting urgent fixes. Deleting an issue is not a benign activity, as it might harm the development workflow or attempt to hide malicious behavior. Because of this, it should be restricted and allowed only by trusted and responsible users.", + "ImpactStatement": "Certain users will not be permitted to delete issues.", + "RemediationProcedure": "Restrict issue deletion to a few trusted and responsible users only by performing either of the following steps:\n\nIf Your organizations > Settings > Access > Member privileges > Allow members to delete issues for this organization is selected, allow only trusted members to have admin privileges:\n1. In every repository, on GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings** and then in the \"Access\" section of the sidebar, click **Collaborators & teams**.\n3. Under \"Manage access\" use the dropdown **Role** menu to filter and search for admin members. Change their role by clicking the **Role** dropdown next to the username until there are only two trusted and qualified users with admin privileges.\n\nIf it is not selected, allow only trusted users to become an organization owner:\n1. In the top right corner of GitHub.com, click your profile photo, then click Your organizations.\n2. Click the name of your organization and under your organization name, click **People**.\n3. You will see a list of the people in your organization. Click **Role** and select **Owners**. Check every member you want to change permissions to. Above the list of members, use the drop-down menu and click **Change role** and choose Member > change role. Do that until there are only a few trusted and qualified users with organization owner privileges.\n\nIn any case, only members with administrator or organization owner privileges can delete issues, regardless of your setting.", + "AuditProcedure": "Verify that only a limited number of trusted users can delete issues by performing either of the following steps:\n\nIf Your organizations > Settings > Access > Member privileges > Allow members to delete issues for this organization is selected, verify that every admin member is trusted by you:\n1. In every repository, on GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings** and then in the \"Access\" section of the sidebar, click **Collaborators & teams**.\n3. Under \"Manage access\" use the dropdown **Role** menu to filter and search for admin members. Verify that there are only two of them and that they are trusted and qualified.\n\nIf it is not selected, verify that every organization owner is trusted by you:\n1. In the top right corner of GitHub.com, click your profile photo, then click Your organizations.\n2. Click the name of your organization and under your organization name, click **People**.\n3. You will see a list of the people in your organization. Click **Role** and select **Owners**. Verify that there are only a few of them and that they are trusted and qualified.\n\nIn any case, only members with administrator or organization owner privileges can delete issues, regardless of your setting.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "Only organization owners or members with admin privileges can delete issues." + } + ] + }, + { + "Id": "1.2.5", + "Description": "Track every fork of code and ensure it is accounted for.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.2 Repository Management", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Track every fork of code and ensure it is accounted for.", + "RationaleStatement": "A fork is a copy of a repository. On top of being a plain copy, any updates to the original repository itself can be pulled and reflected by the fork under certain conditions. A large number of repository copies (forks) become difficult to manage and properly secure. New and sensitive changes can often be pushed into a critical repository without developer knowledge of an updated copy of the very same repository. If there is no limit on doing this, then it is recommended to track and delete copies of organization repositories as needed.", + "ImpactStatement": "Disabling forks completely may slow down the development process as more actions will be necessary to take in order to fork a repository.", + "RemediationProcedure": "Track forks and examine them by performing the following on a regular basis:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Insights**.\n3. In the left sidebar, click **Forks**.\n4. Examine the forks listed there.", + "AuditProcedure": "Verify that the following steps are done regularly to track and examine forks:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Insights**.\n3. In the left sidebar, click **Forks**.\n4. Examine the forks listed there.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.2.6", + "Description": "Ensure every change in visibility of projects is tracked.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.2 Repository Management", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure every change in visibility of projects is tracked.", + "RationaleStatement": "Visibility of projects determines who can access a project and/or fork it: anyone, designated users, or only members of the organization. If a private project becomes public, this may point to a potential attack, which can ultimately lead to data loss, the leaking of sensitive information, and finally to a supply chain attack. It is crucial to track these changes in order to prevent such incidents.", + "ImpactStatement": "", + "RemediationProcedure": "Track every change in project visibility and investigate if suspicious behavior occurs, by performing the following regularly:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Archives\" section of the sidebar, click **Logs**, then click **Audit log**.\n4. Use the **repo** qualifier in your query and look for **access** category. Ensure every change is reasonable and secure and investigate if it is not.", + "AuditProcedure": "Ensure that every change in project visibility is tracked and investigated, by performing the following regularly:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Archives\" section of the sidebar, click **Logs**, then click **Audit log**.\n4. Use the **repo** qualifier in your query and look for **access** category. Ensure every change is reasonable and secure and is investigated if it is not.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.2.7", + "Description": "Track inactive repositories and remove them periodically.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.2 Repository Management", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Track inactive repositories and remove them periodically.", + "RationaleStatement": "Inactive repositories (i.e., no new changes introduced for a long period of time) can enlarge the surface of a potential attack or data leak. These repositories are more likely to be improperly managed, and thus could possibly be accessed by a large number of users in an organization.", + "ImpactStatement": "Bug fixes and deployment of necessary changes could prove complicated for archived repositories.", + "RemediationProcedure": "Perform the following to review all inactive repositories and archive them periodically:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Click on your organization name and then on **repositories**.\n3. Ensure every repository listed has been active in the last 3 to 6 months. Every repository that isn't active you should either review or archive by performing the next steps:\n 1. On GitHub.com, navigate to the main page of the repository.\n 2. Under your repository name, click **Settings**.\n 3. Under \"Danger Zone\", click **Archive this repository**.\n 4. Read the warnings.\n 5. Type the name of the repository you want to archive.\n 6. Click **I understand the consequences, archive this repository**.", + "AuditProcedure": "Perform the following to ensure that all the repositories in the organization are active, and those that are not reviewed or archived:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Click on your organization name and then on **repositories**.\n3. Ensure every repository listed has been active in the last 3 to 6 months. If it's not, then ensure it is archived or reviewed regularly.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.1", + "Description": "Track inactive user accounts and periodically remove them.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Track inactive user accounts and periodically remove them.", + "RationaleStatement": "User accounts that have been inactive for a long period of time are enlarging the surface of attack. Inactive users with high-level privileges are of particular concern, as these accounts are more likely to be targets for attackers. This could potentially allow access to large portions of an organization should such an attack prove successful. It is recommended to remove them as soon as possible in order to prevent this.", + "ImpactStatement": "", + "RemediationProcedure": "If you have GitHub Enterprise Cloud, perform the following:\n\n1. In the top-right corner of GitHub.com, click your profile photo, then click **Your enterprises**.\n2. In the list of enterprises, click the enterprise you want to view.\n3. In the enterprise account sidebar, click **Compliance**.\n4. To download your Dormant Users (beta) report as a CSV file, under \"Other\", click **Download**.\n5. Find the users listed in the file under **Your organizations** > your organization > **People** and select them.\n6. Click **Remove from organization** and **Remove members**.", + "AuditProcedure": "If you have GitHub Enterprise Cloud, perform the following:\n\n1. In the top-right corner of GitHub.com, click your profile photo, then click **Your enterprises**.\n2. In the list of enterprises, click the enterprise you want to view.\n3. In the enterprise account sidebar, click **Compliance**.\n4. To download your Dormant Users (beta) report as a CSV file, under \"Other\", click **Download**.\n5. Verify that there are no users listed.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.2", + "Description": "Limit ability to create teams to trusted and specific users.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Limit ability to create teams to trusted and specific users.", + "RationaleStatement": "The ability to create new teams should be restricted to specific members in order to keep the organization orderly and ensure users have access to only the lowest privilege level necessary. Teams typically inherit permissions from their parent team, thus if base permissions are less restricted and any user has the ability to create a team, a permission leverage could occur in which certain data is made available to users who should not have access to it. Such a situation could potentially lead to the creation of shadow teams by an attacker. Restricting team creation will also reduce additional clutter in the organizational structure, and as a result will make it easier to track changes and anomalies.", + "ImpactStatement": "Only specific users will be able to create new teams.", + "RemediationProcedure": "For every organization, limit team creation to specific, trusted users by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Member privileges**.\n4. Under \"Team creation rules\", deselect **Allow members to create teams**.\n5. Click **Save**.", + "AuditProcedure": "For every organization, ensure that team creation is limited to specific, trusted users by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Member privileges**.\n4. Under \"Team creation rules\", verify that **Allow members to create teams** is not selected.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.3", + "Description": "Ensure the organization has a minimum number of administrators.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure the organization has a minimum number of administrators.", + "RationaleStatement": "Organization administrators have the highest level of permissions, including the ability to add/remove collaborators, create or delete repositories, change branch protection policy, and convert to a publicly-accessible repository. Due to the permissive access granted to an organization administrator, it is highly recommended to keep the number of administrator accounts as minimal as possible.", + "ImpactStatement": "", + "RemediationProcedure": "Set the minimum number of administrators in your organization by performing the following:\n\n1. In the top right corner of GitHub, click your profile photo, then click **Your profile**.\n2. On the left side of your profile page, under \"Organizations\", click the icon for your organization.\n3. Under your organization name, click **People**. \n4. In the Role drop-down, choose **Owners**.\n5. Select the person or people you'd like to remove from owner role.\n6. Above the list of members, use the drop-down menu and click Change role.\n7. Select **Member**, then click **Change role**.", + "AuditProcedure": "Verify the minimum number of administrators in your organization by performing the following:\n\n1. In the top right corner of GitHub, click your profile photo, then click **Your profile**.\n2. On the left side of your profile page, under \"Organizations\", click the icon for your organization.\n3. Under your organization name, click **People**. \n4. In the Role drop-down, choose **Owners**.\n5. If there are minimum number of members in the list, you are compliant.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.4", + "Description": "Require collaborators from outside the organization to use Multi-Factor Authentication (MFA) in addition to a standard user name and password when authenticating to the source code management platform.", + "Checks": [ + "organization_members_mfa_required" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Require collaborators from outside the organization to use Multi-Factor Authentication (MFA) in addition to a standard user name and password when authenticating to the source code management platform.", + "RationaleStatement": "By default every user authenticates within the system by password only. If the password of a user is compromised, however, the user account and every repository to which they have access are in danger of data loss, malicious code commits, and data theft. It is therefore recommended that each user has Multi-Factor Authentication enabled. This adds an additional layer of protection to ensure the account remains secure even if the user's password is compromised.", + "ImpactStatement": "A member without enabled Multi-Factor Authentication cannot contribute to the project. They must enable Multi-Factor Authentication a before they can contribute any code.", + "RemediationProcedure": "For each repository in use, enforce Multi-Factor Authentication is the only way to authenticate for contributors, by doing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. Under \"Authentication\", select **Require two-factor authentication for everyone in your organization**, then click **Save**.", + "AuditProcedure": "For each repository in use, verify that Multi-Factor Authentication is enforced for contributors and is the only way to authenticate, by doing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. Under \"Authentication\", check if **Require two-factor authentication for everyone in your organization** is checked. If so, you are compliant.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.5", + "Description": "Require members of the organization to use Multi-Factor Authentication (MFA) in addition to a standard user name and password when authenticating to the source code management platform.", + "Checks": [ + "organization_members_mfa_required" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Require members of the organization to use Multi-Factor Authentication (MFA) in addition to a standard user name and password when authenticating to the source code management platform.", + "RationaleStatement": "By default every user authenticates within the system by password only. If the password of a user is compromised, however, the user account and every repository to which they have access are in danger of data loss, malicious code commits, and data theft. It is therefore recommended that each user has Multi-Factor Authentication enabled. This adds an additional layer of protection to ensure the account remains secure even if the user's password is compromised.", + "ImpactStatement": "Members will be removed from the organization if they don't have Multi-Factor Authentication already enabled. If this is the case, it is recommended that an invitation be sent to reinstate the user's access and former privileges. They must enable Multi-Factor Authentication to accept the invitation.", + "RemediationProcedure": "For every organization that exists in your GitHub platform, enforce Multi-Factor Authentication and define it as the only way to authenticate, by doing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. Under \"Authentication\", select **Require two-factor authentication for everyone in your organization**, then click **Save**.\n5. If prompted, read the information about members and outside collaborators who will be removed from the organization. Type your organization's name to confirm the change, then click **Remove members & require two-factor authentication**.", + "AuditProcedure": "For every organization that exists in your GitHub platform, verify that Multi-Factor Authentication is enforced and is the only way to authenticate, by doing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. Under \"Authentication\", check if **Require two-factor authentication for everyone in your organization** is checked. If so, you are compliant.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.6", + "Description": "Existing members of an organization can invite new members to join, however new members must only be invited with their company-approved email.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Existing members of an organization can invite new members to join, however new members must only be invited with their company-approved email.", + "RationaleStatement": "Ensuring new members of an organization have company-approved email prevents existing members of the organization from inviting arbitrary new users to join. Without this verification, they can invite anyone who is using the organization's version control system or has an active email account, thus allowing outside users (and potential threat actors) to easily gain access to company private code and resources. This practice will subsequently reduce the chance of human error or typos when inviting a new member.", + "ImpactStatement": "Existing members would not be able to invite new users who do not have a company-approved email address.", + "RemediationProcedure": "For each organization, allow only users with company-approved email to be invited. If a user was invited without company-approved email, perform the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Click the name of your organization and under your organization name, click **People**.\n3. On the People tab, click **Invitations**. Next to the username or email address of the person whose invitation you'd like to cancel, click **Edit invitation**.\n4. To cancel the user's invitation to join your organization, click **Cancel invitation**.", + "AuditProcedure": "For each organization in use, verify for every invitation that the invited email address is company-approved by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Click the name of your organization and under your organization name, click **People**.\n3. On the People tab, click **Invitations**. Verify that each invitation email is company approved by your company.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.7", + "Description": "Ensure every repository has two users with administrative permissions.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Ensure every repository has two users with administrative permissions.", + "RationaleStatement": "Repository administrators have the highest permissions to said repository. These include the ability to add/remove collaborators, change branch protection policy, and convert to a publicly-accessible repository. Due to the liberal access granted to a repository administrator, it is highly recommended that only two contributors occupy this role.", + "ImpactStatement": "Removing administrative users from a repository would result in them losing high-level access to that repository.", + "RemediationProcedure": "For every repository in use, set two administrators by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Collaborators & teams**.\n4. Under **Manage access**, find the team or person whose you'd like to revoke admin permissions, then select the Role drop-down and click a new role.", + "AuditProcedure": "For every repository in use, verify there are two administrators by performing the following:\n\n1. On GitHub, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Collaborators & teams**.\n4. Under **Manage access**, verify that there are only 2 members with Admin permission.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.8", + "Description": "Base permissions define the permission level automatically granted to all organization members. Define strict base access permissions for all of the repositories in the organization, including new ones.", + "Checks": [ + "organization_default_repository_permission_strict" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Base permissions define the permission level automatically granted to all organization members. Define strict base access permissions for all of the repositories in the organization, including new ones.", + "RationaleStatement": "Defining strict base permissions is the best practice in every role-based access control (RBAC) system. If the base permission is high — for example, \"write\" permission — every member of the organization will have \"write\" permission to every repository in the organization. This will apply regardless of the specific permissions a user might need, which generally differ between organization repositories. The higher the permission, the higher the risk for incidents such as bad code commit or data breach. It is therefore recommended to set the base permissions to the strictest level possible.", + "ImpactStatement": "Users might not be able to access organization repositories or perform some acts as commits. These specific permissions should be granted individually for each user or team, as needed.", + "RemediationProcedure": "Set strict base permissions for the organization repositories with the next steps:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Member privileges**.\n4. Under \"Base permissions\", use the drop-down to select new base permissions - \"Read\" or \"None\".\n5. Review the changes. To confirm, click **Change default permission to PERMISSION**.", + "AuditProcedure": "Verify that strict base permissions are set for the organization repositories by doing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Access\" section of the sidebar, click **Member privileges**.\n4. Under \"Base permissions\", verify that it is set to \"Read\" or \"None\". If it does, you are compliant.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "Read permission" + } + ] + }, + { + "Id": "1.3.9", + "Description": "Confirm the domains an organization owns with a \"Verified\" badge.", + "Checks": [ + "organization_verified_badge" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Confirm the domains an organization owns with a \"Verified\" badge.", + "RationaleStatement": "Verifying the organization's domain gives developers assurance that a given domain is truly the official home for a public organization. Attackers can pretend to be an organization and steal information via a faked/spoof domain, therefore the use of a \"Verified\" badge instills more confidence and trust between developers and the open-source community.", + "ImpactStatement": "", + "RemediationProcedure": "Only if you have an enterprise account, verify the organization's domains and secure a \"Verified\" badge next to its name by performing the following:\n\n1. In the top-right corner of GitHub.com, click your profile photo, then click **Your enterprises**.\n2. In the list of enterprises, click the enterprise you want to view. Then in the enterprise account sidebar, click **Settings**.\n3. Under \"Settings\", click **Verified & approved domains**.\n4. Click **Add a domain**.\n5. In the domain field, type the domain you'd like to verify, then click **Add domain**.\n6. Follow the instructions under **Add a DNS TXT record** to create a DNS TXT record with your domain hosting service. Wait for your DNS configuration to change, which may take up to 72 hours. You can confirm your DNS configuration has changed by running the `dig` command on the command line, replacing ENTERPRISE-ACCOUNT with the name of your enterprise account, and example.com with the domain you'd like to verify. You should see your new TXT record listed in the command output.\n```\ndig _github-challenge-ENTERPRISE-ACCOUNT.DOMAIN-NAME +nostats +nocomments +nocmd TXT\n```\n7. After confirming your TXT record is added to your DNS, follow steps one through three above to navigate to your enterprise account's approved and verified domains.\n8. To the right of the domain that's pending verification, click the 3-dots, then click **Continue verifying**. Click **Verify**.\n9. Optionally, after the \"Verified\" badge is visible on your organizations' profiles, delete the TXT entry from the DNS record at your domain hosting service.", + "AuditProcedure": "Only if you have an enterprise account, view the enterprise organization profile page and ensure it has a \"Verified\" badge in it.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.10", + "Description": "Restrict the Source Code Management (SCM) organization's email notifications to approved domains only.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Restrict the Source Code Management (SCM) organization's email notifications to approved domains only.", + "RationaleStatement": "Restricting Source Code Management email notifications to verified domains only prevents data leaks, as personal emails and custom domains are more prone to account takeover via DNS hijacking or password breach.", + "ImpactStatement": "Only members with approved email would be able to receive Source Code Management notifications.", + "RemediationProcedure": "Only if you have an enterprise account, restrict Source Code Management email notifications to approved domains only by performing the following:\n\n1. In the top-right corner of GitHub.com, click your profile photo, then click **Your enterprises**.\n2. In the list of enterprises, click the enterprise you want to view. Then in the enterprise account sidebar, click **Settings**.\n3. Under \"Settings\", click **Verified & approved domains**.\n4. Under \"Notification preferences\", select **Restrict email notifications to only approved or verified domains**.\n5. Click **Save**.", + "AuditProcedure": "Only if you have an enterprise account, ensure Source Code Management email notifications are restricted to approved domains only by performing the following:\n\n1. In the top-right corner of GitHub.com, click your profile photo, then click **Your enterprises**.\n2. In the list of enterprises, click the enterprise you want to view. Then in the enterprise account sidebar, click **Settings**.\n3. Under \"Settings\", click **Verified & approved domains**.\n4. Under \"Notification preferences\", verify that **Restrict email notifications to only approved or verified domains** is selected.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.11", + "Description": "As an organization, become an SSH Certificate Authority and provide SSH keys for accessing repositories.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "As an organization, become an SSH Certificate Authority and provide SSH keys for accessing repositories.", + "RationaleStatement": "There are two ways for remotely working with Source Code Management: via HTTPS, which requires authentication by user/password, or via SSH, which requires the use of SSH keys. SSH authentication is better in terms of security; key creation and distribution, however, must be done in a secure manner. This can be accomplished by implementing SSH certificates, which are used to validate the server's identity. A developer will not be able to connect to a Git server if its key cannot be verified by the SSH Certificate Authority (CA) server.\nAs an organization, one can verify the SSH certificate signature used to authenticate if a CA is defined and used. This ensures that only verified developers can access organization repositories, as their SSH key will be the only one signed by the CA certificate. This reduces the risk of misuse and malicious code commits.", + "ImpactStatement": "Members with unverified keys will not be able to clone organization repositories. Signing, certification, and verification might also slow down the development process.", + "RemediationProcedure": "Only if you have an enterprise account, deploy an SSH Certificate Authority server and configure it to provide an SSH certificate with which to sign keys by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. To the right of \"SSH Certificate Authorities\", click **New CA**.\n5. Under \"Key,\" paste your public SSH key.\n6. Click **Add CA**.\n7. Click **Save**.", + "AuditProcedure": "Only if you have an enterprise account, verify that the enterprise organization has an SSH Certificate Authority server and provides an SSH certificate with which to sign keys by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. Verify that there's an SSH certificate authority listed there.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.12", + "Description": "Limit Git access based on IP addresses by having a allowlist of IP addresses from which connection is possible.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Limit Git access based on IP addresses by having a allowlist of IP addresses from which connection is possible.", + "RationaleStatement": "Allowing access to Git repositories (source code) only from specific IP addresses adds yet another layer of restriction and reduces the risk of unauthorized connection to the organization's assets. This will prevent attackers from accessing Source Code Management (SCM), as they would first need to know the allowed IP addresses to gain access to them.", + "ImpactStatement": "Only members with allowlisted IP addresses will be able to access the organization's Git repositories.", + "RemediationProcedure": "Only if you have an enterprise account, create an IP allowlist and forbid all other IPs from accessing the source code by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. At the bottom of the \"IP allow list\" section, enter an IP address, or a range of addresses in CIDR notation. Optionally, enter a description of the allowed IP address or range.\n5. Click **Add**.\n6. After that, under \"IP allow list\", select **Enable IP allow list**.\n7. Click **Save**.", + "AuditProcedure": "Only if you have an enterprise account, in every organization of yours, ensure access is allowed only by IP allowlist, and that access is forbidden for all other IPs by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Authentication security**.\n4. Verify that there's an IP address, or a range of addresses in CIDR notation listed. Also verify that **Enable IP allow list** is selected.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-allowed-ip-addresses-for-your-organization", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.3.13", + "Description": "Track code anomalies.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.3 Contribution Access", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Track code anomalies.", + "RationaleStatement": "Carefully analyze any code anomalies within the organization. For example, a code anomaly could be a push made outside of working hours. Such a code push has a higher likelihood of being the result of an attack, as most if not all members of the organization would likely be outside the office. Another example is an activity that exceeds the average activity of a particular user.\nTracking and auditing such behaviors creates additional layers of security and can aid in early detection of potential attacks.", + "ImpactStatement": "", + "RemediationProcedure": "For every repository in use, track and investigate anomalous code behavior and activity.", + "AuditProcedure": "For every repository in use, ensure code anomalies relevant to the organization are promptly investigated.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.4.1", + "Description": "Ensure an administrator approval is required when installing applications.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.4 Third-Party", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure an administrator approval is required when installing applications.", + "RationaleStatement": "Applications are typically automated integrations that improve the workflow of an organization. They are written by third-party developers, and therefore should be validated before using in case they're malicious or not trustable. Because administrators are expected to be the most qualified and trusted members of the organization, they should review the applications being installed and decide whether they are both trusted and necessary.", + "ImpactStatement": "Applications will not be installed without administrator approval.", + "RemediationProcedure": "Require an administrator approval for every installed application:\n\na. For GitHub Apps, you are compliant by default. That is because by default only organization owners and administrators can install them.\n\nb. For OAuth Apps, perform the following:\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Third-party Access\" section of the sidebar, click **OAuth application policy**.\n4. Under \"Third-party application access policy\", click **Setup application access restrictions**.\n5. After you review the information about third-party access restrictions, click **Restrict third-party application access**.", + "AuditProcedure": "Verify that applications are installed only after receiving administrator approval:\n\na. For GitHub Apps, you are compliant by default. That is because by default only organization owners and administrators can install them.\n\nb. For OAuth Apps, perform the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Third-party Access\" section of the sidebar, click **OAuth application policy**.\n4. Under \"Third-party application access policy\" verify that the policy status is **Access restricted**.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "Maintainers are organization owners." + } + ] + }, + { + "Id": "1.4.2", + "Description": "Ensure stale (inactive) applications are reviewed and removed if no longer in use.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.4 Third-Party", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure stale (inactive) applications are reviewed and removed if no longer in use.", + "RationaleStatement": "Applications that have been inactive for a long period of time are enlarging the surface of attack for data leaks. They are more likely to be improperly managed, and could possibly be accessed by third-party developers as a tool for collecting internal data of the organization or repository in which they are installed. It is important to remove these inactive applications as soon as possible.", + "ImpactStatement": "", + "RemediationProcedure": "Review all stale applications and periodically remove them.", + "AuditProcedure": "Verify that all the applications in the organization are actively used, and remove those that are no longer in use.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.4.3", + "Description": "Ensure installed application permissions are limited to the lowest privilege level required.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.4 Third-Party", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure installed application permissions are limited to the lowest privilege level required.", + "RationaleStatement": "Applications are typically automated integrations that can improve the workflow of an organization. They are written by third-party developers, and therefore should be reviewed carefully before use. It is recommended to use the \"least privilege\" principle, granting applications the lowest level of permissions required. This may prevent harm from a potentially malicious application with unnecessarily high-level permissions leaking data or modifying source code.", + "ImpactStatement": "", + "RemediationProcedure": "Grant permissions to applications by the \"least privilege\" principle, meaning the lowest possible permission necessary:\n\na. For GitHub Apps, perform the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Integrations\" section of the sidebar, click **GitHub Apps**.\n4. Next to every GitHub App, click **Configure**.\n5. Review the GitHub App's permissions and repository access. Edit the permissions granted to the least possible. For example, restrict the number of repositories the App can access.\n6. Click **Save**.", + "AuditProcedure": "Verify that each installed application has the least privilege needed:\n\na. For GitHub Apps, perform the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the \"Integrations\" section of the sidebar, click **GitHub Apps**.\n4. Next to every GitHub App, click **Configure**.\n5. Review the GitHub App's permissions and repository access. Verify that the App permissions are the least possible and that it can access only necessary repositories.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.4.4", + "Description": "Use only secured webhooks in the source code management platform.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.4 Third-Party", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Use only secured webhooks in the source code management platform.", + "RationaleStatement": "A webhook is an event listener, attached to critical and sensitive parts of the software delivery process. It is triggered by a list of events (such as a new code being committed), and when triggered, the webhook sends out a notification with some payload to specific internet endpoints. Since the payload of the webhook contains sensitive organization data, it's important all webhooks are directed to an endpoint (URL) protected by SSL verification (HTTPS). This helps ensure that the data sent is delivered to securely without any man-in-the-middle, who could easily access and even alter the payload of the request.", + "ImpactStatement": "Perform the following to ensure all webhooks used are secured (HTTPS):\n\n1. Navigate to your organization or repository and select **Settings**.\n2. Select **Webhooks** on the side menu.\n3. Verify that each webhook URL starts with 'https'.", + "RemediationProcedure": "Perform the following to secure all webhooks used(over HTTPS):\n\n1. Navigate to your organization or repository and select **Settings**.\n2. Select **Webhooks** on the side menu.\n3. Find the webhooks that starts with 'http' and not 'https'.\n4. Ensure the endpoint (URL) of the webhook listens to secured port (443) and uses certificate.\n5. Click **Edit**.\n6. Change the payload URL to https and ensure **Enable SSL verification** is checked.\n7. Click **Update webhook**.", + "AuditProcedure": "Perform the following to secure all webhooks used(over HTTPS):\n\n1. Navigate to your organization or repository and select **Settings**.\n2. Select **Webhooks** on the side menu.\n3. Ensure all webhooks starts with 'https'.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.5.1", + "Description": "Detect and prevent sensitive data in code, such as confidential ID numbers, passwords, etc.", + "Checks": [ + "repository_secret_scanning_enabled" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.5 Code Risks", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Detect and prevent sensitive data in code, such as confidential ID numbers, passwords, etc.", + "RationaleStatement": "Having sensitive data in the source code makes it easier for attackers to maliciously use such information. In order to avoid this, designate scanners to identify and prevent the existence of sensitive data in the code.", + "ImpactStatement": "", + "RemediationProcedure": "For every repository in use, designate scanners to identify and prevent sensitive data in code by performing the following (enterprise only):\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Code security and analysis**.\n4. Scroll down to the bottom of the page and click **Enable** for secret scanning.", + "AuditProcedure": "For every repository in use, verify that scanners are set to identify and prevent the existence of sensitive data in code by performing the following (enterprise only):\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the \"Security\" section of the sidebar, click **Code security and analysis**.\n4. Scroll down to the bottom of the page. If you see a **Disable** button, it means that secret scanning is already enabled for the repository.", + "AdditionalInformation": "By January 2023, this feature is supposed to be open to all plans. Until then it is only for enterprise users.", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.5.2", + "Description": "Detect and prevent misconfigurations and insecure instructions in CI pipelines", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.5 Code Risks", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Detect and prevent misconfigurations and insecure instructions in CI pipelines", + "RationaleStatement": "Detecting and fixing misconfigurations or insecure instructions in CI pipelines decreases the risk for a successful attack through or on the CI pipeline. The more secure the pipeline, the less risk there is for potential exposure of sensitive data, a deployment being compromised, or external access mistakenly being granted to the CI infrastructure or the source code.", + "ImpactStatement": "", + "RemediationProcedure": "Set a CI instructions scanning tool to identify and prevent misconfigurations and insecure instructions and scans all CI pipelines.", + "AuditProcedure": "Verify that a CI instructions scanning tool is set to identify and prevent misconfigurations and insecure instructions and that it scans all CI pipelines.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.5.3", + "Description": "Detect and prevent misconfigurations or insecure instructions in Infrastructure as Code (IaC) files, such as Terraform files.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.5 Code Risks", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Detect and prevent misconfigurations or insecure instructions in Infrastructure as Code (IaC) files, such as Terraform files.", + "RationaleStatement": "Detecting and fixing misconfigurations and/or insecure instructions in IaC (Infrastructure as Code) files decreases the risk for data leak or data theft. It is important to secure IaC instructions in order to prevent further problems of deployment, exposed assets, or improper configurations, which can ultimately lead to easier ways to attack and steal organization data.", + "ImpactStatement": "", + "RemediationProcedure": "For every repository that holds IaC instructions files, set a scanning tool to identify and prevent misconfigurations and insecure instructions.", + "AuditProcedure": "For every repository that holds IaC instructions files, verify that a scanning tool is set to identify and prevent misconfigurations and insecure instructions.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.5.4", + "Description": "Detect and prevent known open source vulnerabilities in the code.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.5 Code Risks", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Detect and prevent known open source vulnerabilities in the code.", + "RationaleStatement": "Open source code blocks are used a lot in developed software. This has its own advantages, but it also has risks. Because the code is open for everyone, it means that attackers can publish or add malicious code to these open-source code blocks, or use their knowledge to find vulnerabilities in an existing code. Detecting and fixing such code vulnerabilities, by SCA (Software Composition Analysis) prevents insecure flaws from reaching production. It gives another opportunity for developers to secure the source code before it is deployed in production, where it is far more exposed and vulnerable to attacks.", + "ImpactStatement": "", + "RemediationProcedure": "For every repository that is in use, set a scanning tool to identify and prevent code vulnerabilities by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under the repository name, click **Security**.\n3. To the right of \"Code scanning alerts\", click **Set up code scanning**.\n4. Under \"Get started with code scanning\", click Set up this workflow on a workflow of your choice.\n5. To customize how code scanning scans your code, edit the workflow.\n6. Use the **Start commit** drop-down and type a commit message.\n7. Choose whether you'd like to commit directly to the default branch or create a new branch and start a pull request.\n8. Click **Commit new file** or **Propose new file**.", + "AuditProcedure": "For every repository that is in use, verify that a scanning tool is set to identify and prevent code vulnerabilities by performing the following:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under the repository name, click **Security**.\n3. Verify that \"Code scanning alerts\" is **Enabled** or that there is a workflow that scans your code.", + "AdditionalInformation": "All public repositories in all plans can use code scanning in GitHub. In private repositories, only GitHub Enterprise can use code scanning.", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.5.5", + "Description": "Detect, prevent and monitor known open-source vulnerabilities in packages that are being used.", + "Checks": [ + "repository_dependency_scanning_enabled" + ], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.5 Code Risks", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Detect, prevent and monitor known open-source vulnerabilities in packages that are being used.", + "RationaleStatement": "Open-source vulnerabilities might exist before one starts to use a package, but they are also discovered over time. New attacks and vulnerabilities are announced every now and then. It is important to keep track of these and to monitor whether the dependencies used are affected by the recent vulnerability. Detecting and fixing those packages' vulnerabilities decreases the attack surface within deployed and running applications that use such packages. It prevents security flaws from reaching the production environment which could eventually lead to a security breach.", + "ImpactStatement": "", + "RemediationProcedure": "Set scanners that will monitor, identify, and prevent open-source vulnerabilities in packages by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**. In the \"Security\" section of the sidebar, click **Code security and analysis**.\n3. Under \"Code security and analysis\", to the right of Dependabot alerts, click **Disable all** or **Enable all**.\n4. Check the **Enable by default for new repositories** option and then click **Enable Dependabot alerts**.\n\nIt is also recommended to use another additional solution for package scanning because GitHub doesn't always recognize the vulnerabilities.", + "AuditProcedure": "Verify that scanners are set to monitor, identify, and prevent open-source vulnerabilities in packages by performing the following:\n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**. In the \"Security\" section of the sidebar, click **Code security and analysis**.\n3. Verify that the Dependabot alerts is enabled and that **Enable by default for new repositories** is checked.\n\nIt is also recommended to verify that you're using another additional solution for package scanning because GitHub doesn't always recognize the vulnerabilities.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "1.5.6", + "Description": "Detect open-source license problems in used dependencies and fix them.", + "Checks": [], + "Attributes": [ + { + "Section": "1 Source Code", + "Subsection": "1.5 Code Risks", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Detect open-source license problems in used dependencies and fix them.", + "RationaleStatement": "A software license is a legal document that establishes several key conditions between a software company or developer and a user in order to allow the use of software. Software licenses have the potential to create code dependencies. Not following the conditions in the software license can also lead to lawsuits. When using packages with a software license, especially commercial ones (which are the most permissive), it is important to verify what is allowed by that license in order to be protected against lawsuits.", + "ImpactStatement": "", + "RemediationProcedure": "Designate a license scanning tool to identify open-source license problems and fix them and scan every package you use.", + "AuditProcedure": "Ensure a license scanning tool is set up to identify open-source license problems and that every package you use is scanned by it.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.1", + "Description": "Ensure each pipeline has a single responsibility in the build process.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Ensure each pipeline has a single responsibility in the build process.", + "RationaleStatement": "Build pipelines generally have access to multiple secrets depending on their purposes. There are, for example, secrets of the test environment for the test phase, repository and artifact credentials for the build phase, etc. Limiting access to these credentials/secrets is therefore recommended by dividing pipeline responsibilities, as well as having a dedicated pipeline for each phase with the lowest privilege instead of a single pipeline for all. This will ensure that any potential damage caused by attacks on a workflow will be limited.", + "ImpactStatement": "", + "RemediationProcedure": "Divide each multi-responsibility pipeline into multiple pipelines, each having a single responsibility with the least privilege. Additionally, create all new pipelines with a sole purpose going forward.", + "AuditProcedure": "For each pipeline, ensure it has only one responsibility in the build process.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.2", + "Description": "Ensure the pipeline orchestrator and its configuration are immutable.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure the pipeline orchestrator and its configuration are immutable.", + "RationaleStatement": "An immutable infrastructure is one that cannot be changed during execution of the pipeline. This can be done, for example, by using Infrastructure as Code for configuring the pipeline and the pipeline environment. Utilizing such infrastructure creates a more predictable environment because updates will require re-deployment to prevent any previous configuration from interfering. Because it is dependent on automation, it is easier to revert changes. Testing code is also simpler because it is based on virtualization. Most importantly, an immutable pipeline infrastructure ensures that a potential attacker seeking to compromise the build environment itself would not be able to do so if the orchestrator, its configuration, and any other component cannot be changed. Verifying that all aspects of the pipeline infrastructure and configuration are immutable therefore keeps them safe from malicious tampering attempts.", + "ImpactStatement": "", + "RemediationProcedure": "Use an immutable pipeline orchestrator and ensure that its configuration and all other aspects of the built environment are immutable, as well.", + "AuditProcedure": "Verify that the pipeline orchestrator, its configuration, and all other aspects of the build environment are immutable.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.3", + "Description": "Keep build logs of the build environment detailing configuration and all activity within it. Also, consider to store them in a centralized organizational log store.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Keep build logs of the build environment detailing configuration and all activity within it. Also, consider to store them in a centralized organizational log store.", + "RationaleStatement": "Logging the environment is important for two primary reasons: one, for debugging and investigating the environment in case of a bug or security incident; and two, for reproducing the environment easily when needed. Storing these logs in a centralized organizational log store allows the organization to generate useful insights and identify anomalies in the build process faster.", + "ImpactStatement": "", + "RemediationProcedure": "Keep logs of the build environment. For example, use the .buildinfo file for Debian build workers. Also, store the logs in a centralized organizational log store.", + "AuditProcedure": "Verify that the build environment is logged and stored in a centralized organizational log store.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.4", + "Description": "Automate the creation of the build environment.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Automate the creation of the build environment.", + "RationaleStatement": "Automating the deployment of the build environment reduces the risk for human mistakes — such as a wrong configuration or exposure of sensitive data — because it requires less human interaction and intervention. It also eases re-deployment of the environment. It is best to automate with Infrastructure as Code because it offers more control over changes made to the environment creation configuration and stores to a version control platform.", + "ImpactStatement": "", + "RemediationProcedure": "Automate the deployment of the build environment.", + "AuditProcedure": "Verify that the deployment of the build environment is automated and can be easily redeployed.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.5", + "Description": "Restrict access to the build environment (orchestrator, pipeline executor, their environment, etc.) to trusted and qualified users only.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Restrict access to the build environment (orchestrator, pipeline executor, their environment, etc.) to trusted and qualified users only.", + "RationaleStatement": "A build environment contains sensitive data such as environment variables, secrets, and the source code itself. Any user that has access to this environment can make changes to the build process, including changes to the code within it. Restricting access to the build environment to trusted and qualified users only will reduce the risk for mistakes such as exposure of secrets or misconfiguration. Limiting access also reduces the number of accounts that are vulnerable to hijacking in order to potentially harm the build environment.", + "ImpactStatement": "Reducing the number of users who have access to the build process means those users would lose their ability to make direct changes to that process.", + "RemediationProcedure": "Restrict access to the build environment to trusted and qualified users.", + "AuditProcedure": "Verify each build environment is accessible only to known and authorized users.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.6", + "Description": "Require users to login in to access the build environment - where the orchestrator, the pipeline executer, where the build workers are running, etc.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Require users to login in to access the build environment - where the orchestrator, the pipeline executer, where the build workers are running, etc.", + "RationaleStatement": "Requiring users to authenticate and disabling anonymous access to the build environment allows organization to track every action on that environment, good or bad, to its actor. This will help recognizing attack and its attacker because the authentication is required.", + "ImpactStatement": "Anonymous users won't be able to access the build environment.", + "RemediationProcedure": "Require authentication to access the build environment and disable anonymous access.", + "AuditProcedure": "Ensure authentication is required to access the build environment.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.7", + "Description": "Build tools providers offer a secure way to store secrets that should be used during the build process.\nThese secrets will often be credentials used to access other tools, for example for pulling code or for uploading artifacts.\nAccess to these secrets can be defined on various scopes, for example in github it could be on an organization level or a repository level and there is also control on whether these secrets are passed to forked pull request.\nTo protect these critical assets it is important to choose the most restrictive scope necessary.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Build tools providers offer a secure way to store secrets that should be used during the build process.\nThese secrets will often be credentials used to access other tools, for example for pulling code or for uploading artifacts.\nAccess to these secrets can be defined on various scopes, for example in github it could be on an organization level or a repository level and there is also control on whether these secrets are passed to forked pull request.\nTo protect these critical assets it is important to choose the most restrictive scope necessary.", + "RationaleStatement": "Allowing over permissive access to these secrets may affect on their exposure.\nFor example if a secret is defined in an organization level, and users can create new repositories, there is a scenario where a user can create a new repo and run a controlled build just to exfiltrate these secrets.", + "ImpactStatement": "Increased risk of exposure of build related secrets.", + "RemediationProcedure": "For each build tool, review the secrets defined and their permissions scope and change over permissive scopes to more restrictive ones based on the required access.", + "AuditProcedure": "For each build tool in use, review the secrets defined and the permission scopes they are assigned.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.8", + "Description": "Scan the build infrastructure and its dependencies for vulnerabilities. It is recommended that this be done automatically.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Scan the build infrastructure and its dependencies for vulnerabilities. It is recommended that this be done automatically.", + "RationaleStatement": "Automatic scanning for vulnerabilities detects known vulnerabilities in the tooling used by the build infrastructure and its dependencies. These vulnerabilities can lead\nto a potentially massive breach if not handled as fast as possible, as attackers might also be\naware of such vulnerabilities.", + "ImpactStatement": "", + "RemediationProcedure": "Set an automated vulnerability scanning for your build infrastructure.", + "AuditProcedure": "Verify that your build infrastructure is automatically scanned for vulnerabilities.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.9", + "Description": "Do not use default passwords of build tools and components.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Do not use default passwords of build tools and components.", + "RationaleStatement": "Sometimes build tools and components are provided with default passwords for the first login. This password is intended to be used only on the first login and should be changed immediately after. Using the default password substantially increases the attack risk. It is especially important to ensure that default passwords are not used in build tools and components.", + "ImpactStatement": "", + "RemediationProcedure": "For each build tool, change the default password.", + "AuditProcedure": "For each build tool, ensure the password used is not the default one.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.10", + "Description": "Use secured webhooks of the build environment.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Use secured webhooks of the build environment.", + "RationaleStatement": "Webhooks are used for triggering an HTTP request based on an action made in the platform. Typically, build environment feature webhooks for a pipeline trigger based on source code event. Since webhooks are an HTTP POST request, they can be malformed if not secured over SSL. To prevent a potential hack and compromise of the webhook or to the environment or web server excepting the request, use only secured webhooks.", + "ImpactStatement": "", + "RemediationProcedure": "For each webhook in use, change it to secured (over HTTPS).", + "AuditProcedure": "For each webhook in use, ensure it is secured (HTTPS).", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.1.11", + "Description": "Ensure the build environment has a minimum number of administrators.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.1 Build Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure the build environment has a minimum number of administrators.", + "RationaleStatement": "Build environment administrators have the highest level of permissions, including the ability to add/remove users, create or delete pipelines, control build workers, change build trigger permissions and more. Due to the permissive access granted to a build environment administrator, it is highly recommended to keep the number of administrator accounts as minimal as possible.", + "ImpactStatement": "", + "RemediationProcedure": "Set the minimum number of administrators in the build environment.", + "AuditProcedure": "Verify that the build environment has only the minimum number of administrators.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.1", + "Description": "Use a clean instance of build worker for every pipeline run.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Use a clean instance of build worker for every pipeline run.", + "RationaleStatement": "Using a clean instance of build worker for every pipeline run eliminates the risks of data theft, data integrity breaches, and unavailability. It limits the pipeline's access to data stored on the file system from previous runs, and the cache is volatile. This prevents malicious changes from affecting other pipelines or the Continuous Integration/Continuous Delivery system itself.", + "ImpactStatement": "Data and cache will not be saved in different pipeline runs.", + "RemediationProcedure": "Create a clean build worker for every pipeline that is being run, or use build platform-hosted runners, as they typically offer a clean instance for every run.", + "AuditProcedure": "Ensure that every pipeline that is being run has its own clean, new runner.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.2", + "Description": "A worker’s environment can be passed (for example, a pod in a Kubernetes cluster in which an environment variable is passed to it). It also can be pulled, like a virtual machine that is installing a package. Ensure that the environment and commands are passed to the workers and not pulled from it.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "A worker’s environment can be passed (for example, a pod in a Kubernetes cluster in which an environment variable is passed to it). It also can be pulled, like a virtual machine that is installing a package. Ensure that the environment and commands are passed to the workers and not pulled from it.", + "RationaleStatement": "Passing an environment means additional configuration happens in the build time phase and not in run time. It will also pass locally and not remotely. Passing a worker environment, instead of pulling it from an outer source, reduces the possibility for an attacker to gain access and potentially pull malicious code into it. By passing locally and not pulling from remote, there is also less chance of an attack based on the remote connection, such as a man-in-the-middle or malicious scripts that can run from remote. This therefore prevents possible infection of the build worker.", + "ImpactStatement": "", + "RemediationProcedure": "For each build worker, pass its environment and commands to it instead of pulling it.", + "AuditProcedure": "For each build worker, ensure its environment and commands are passed and not pulled.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.3", + "Description": "Separate responsibilities in the build workflow, such as testing, compiling, pushing artifacts, etc., to different build workers so that each worker will have a single duty.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Separate responsibilities in the build workflow, such as testing, compiling, pushing artifacts, etc., to different build workers so that each worker will have a single duty.", + "RationaleStatement": "Separating duties and allocating them to many workers makes it easier to verify each step in the build process and ensure there is no corruption. It also limits the effect of an attack on a build worker, as such an attack would be less critical if the worker has less access and duties that are subject to harm.", + "ImpactStatement": "", + "RemediationProcedure": "For each build worker, limit its responsibility to one duty.", + "AuditProcedure": "For each build worker, ensure it has the least responsibility possible, preferably only one duty.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.4", + "Description": "Ensure that build workers have minimal network connectivity.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure that build workers have minimal network connectivity.", + "RationaleStatement": "Restricting the network connectivity of build workers decreases the possibility that an attacker would be capable of entering the organization from the outside. If the build workers are connected to the public internet without any restriction, it is far simpler for attackers to compromise them. Limiting network connectivity between build workers also protects the organization in case an attacker was successful and subsequently attempts to spread the attack to other components of the environment.", + "ImpactStatement": "Developers will not have connectivity to every resource they might need from the outside. Workers will also only be able to exchange data through shareable storage.", + "RemediationProcedure": "Limit the network connectivity of build workers, environment, and any other components to the necessary minimum.", + "AuditProcedure": "Verify that build workers, environment, and any other components have only the required minimum of network connectivity.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.5", + "Description": "Add traces to build workers' operating systems and installed applications so that in run time, collected events can be analyzed to detect suspicious behavior patterns and malware.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Add traces to build workers' operating systems and installed applications so that in run time, collected events can be analyzed to detect suspicious behavior patterns and malware.", + "RationaleStatement": "Build workers are exposed to data exfiltration attacks, code injection attacks, and more while running. It is important to secure them from such attacks by enforcing run-time security on the build worker itself. This will identify attempted attacks in real time and prevent them.", + "ImpactStatement": "", + "RemediationProcedure": "Deploy and enforce a run-time security solution on build workers.", + "AuditProcedure": "Verify that a run-time security solution is enforced on every active build worker.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.6", + "Description": "Scan build workers for vulnerabilities. It is recommended that this be done automatically.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Scan build workers for vulnerabilities. It is recommended that this be done automatically.", + "RationaleStatement": "Automatic scanning for vulnerabilities detects known weaknesses in environmental sources in use, such as docker images or kernel versions. Such vulnerabilities can lead to a massive breach if these environments are not replaced as fast as possible, since attackers also know about these vulnerabilities and often try to take advantage of them. Setting automatic scanning which scans environmental sources ensures that if any new vulnerability is revealed, it can be replaced quickly and easily. This protects the worker from being exposed to attacks.", + "ImpactStatement": "", + "RemediationProcedure": "For each build worker, automatically scan its environmental sources, such as docker image, for vulnerabilities.", + "AuditProcedure": "For each build worker, ensure the environmental sources it uses are scanned for vulnerabilities.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.7", + "Description": "Store the deployment configuration of build workers in a version control platform, such as Github.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Store the deployment configuration of build workers in a version control platform, such as Github.", + "RationaleStatement": "Build workers are a sensitive part of the build phase. They generally have access to the code repository, the Continuous Integration platform, the deployment platform, etc. This means that an attacker gaining access to a build worker may compromise other platforms in the organization and cause a major incident. One thing that can protect workers is to ensure that their deployment configuration is safe and well-configured. Storing the deployment configuration in version control enables more observability of these configurations because everything is catalogued in a single place. It adds another layer of security, as every change will be reviewed and noticed, and thus malicious changes will theoretically occur less. In the case of a mistake, bug, or security incident, it also offers an easier way to \"revert\" back to a safe version or add a \"hot fix\" quickly.", + "ImpactStatement": "Changes in deployment configuration may only be applied by declaration in the version control platform. This could potentially slow down the development process.", + "RemediationProcedure": "Document and store every deployment configuration of build workers in a version control platform.", + "AuditProcedure": "Verify that the deployment configuration of build workers is stored in a version control platform.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.2.8", + "Description": "Monitor the resource consumption of build workers and set alerts for high consumption that can lead to resource exhaustion.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.2 Build Worker", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Monitor the resource consumption of build workers and set alerts for high consumption that can lead to resource exhaustion.", + "RationaleStatement": "Resource exhaustion is when machine resources or services are highly consumed until exhausted. Resource exhaustion may lead to DOS (Denial of Service). When such a situation happens to build workers, it slows down and even stops the build process, which harms the production of artifacts and the organization's ability to deliver software on schedule. To prevent that, it is recommended to monitor resources consumption in the build workers and set alerts to notify when they are highly consumed. That way resource exhaustion can be acknowledged and prevented at an early stage.", + "ImpactStatement": "", + "RemediationProcedure": "Set reources consumption monitoring for each build worker.", + "AuditProcedure": "Verify that there is monitoring of resources consumption for each build worker.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.1", + "Description": "Use pipeline as code for build pipelines and their defined steps.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Use pipeline as code for build pipelines and their defined steps.", + "RationaleStatement": "Storing pipeline instructions as code in a version control system means automation of the build steps and less room for human error, which could potentially lead to a security breach. Additionally, It creates the ability to revert back to a previous pipeline configuration in order to pinpoint the affected change should a malicious incident occur.", + "ImpactStatement": "", + "RemediationProcedure": "Convert pipeline instructions into code-based syntax and upload them to the organization's version control platform.", + "AuditProcedure": "Verify that all build steps are defined as code and stored in a version control system.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.2", + "Description": "Define clear expected input and output for each build stage.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Define clear expected input and output for each build stage.", + "RationaleStatement": "In order to have more control over data flow in the build pipeline, clearly define the input and output of the pipeline steps. If anything malicious happens during the build stage, it will be recognized more easily and stand out as an anomaly.", + "ImpactStatement": "", + "RemediationProcedure": "For each build stage, clearly define what is expected for input and output.", + "AuditProcedure": "For each build stage, verify that the expected input and output are clearly defined.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.3", + "Description": "Write pipeline output artifacts to a secured storage repository.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Write pipeline output artifacts to a secured storage repository.", + "RationaleStatement": "To maintain output artifacts securely and reduce the potential surface for attack, store such artifacts separately in secure storage. This separation enforces the Single Responsibility Principle by ensuring the orchestration platform will not be the same as the artifact storage, which reduces the potential harm of an attack. Using the same security considerations as the input (for example, the source code) will protect artifacts stored and will make it harder for a malicious actor to successfully execute an attack.", + "ImpactStatement": "", + "RemediationProcedure": "For each pipeline that produces output artifacts, write them to a secured storage repository.", + "AuditProcedure": "For each pipeline that produces output artifacts, ensure that they're written to a secured storage repository.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.4", + "Description": "Track and review changes to pipeline files.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Track and review changes to pipeline files.", + "RationaleStatement": "Pipeline files are sensitive files. They have the ability to access sensitive data and control the build process, thus it is just as important to review changes to pipeline files as it is to verify source code. Malicious actors can potentially add harmful code to these files, which may lead to sensitive data exposure and hijacking of the build environment or artifacts.", + "ImpactStatement": "", + "RemediationProcedure": "For each pipeline file, track changes to it and review them.", + "AuditProcedure": "For each pipeline file, ensure changes to it are being tracked and reviewed.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.5", + "Description": "Restrict access to pipeline triggers.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Restrict access to pipeline triggers.", + "RationaleStatement": "Build pipelines are used for multiple reasons. Some are very sensitive, such as pipelines which deploy to production. In order to protect the environment from malicious acts or human mistakes, such as a developer deploying a bug to production, it is important to apply the Least Privilege principle to pipeline triggering. This principle requires restrictions placed on which users can run which pipeline. It allows for sensitive pipelines to only be run by administrators, who are generally the most trusted and skilled members of the organization.", + "ImpactStatement": "", + "RemediationProcedure": "For every pipeline in use, grant only the necessary users permission to trigger it.", + "AuditProcedure": "For every pipeline in use, verify only the necessary users have permission to trigger it.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.6", + "Description": "Scan the pipeline for misconfigurations. It is recommended that this be performed automatically.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Scan the pipeline for misconfigurations. It is recommended that this be performed automatically.", + "RationaleStatement": "Automatic scans for misconfigurations detect human mistakes and misconfigured tasks. This protects the environment from backdoors caused by such mistakes, which create easier access for attackers. For example, a task that mistakenly configures credentials to persist on the disk makes it easier for an attacker to steal them. This type of incident can be prevented by auto-scanning.", + "ImpactStatement": "", + "RemediationProcedure": "For each pipeline, set automated misconfiguration scanning.", + "AuditProcedure": "For each pipeline, verify that it is automatically scanned for misconfigurations.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.7", + "Description": "Scan pipelines for vulnerabilities. It is recommended that this be implemented automatically.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Scan pipelines for vulnerabilities. It is recommended that this be implemented automatically.", + "RationaleStatement": "Automatic scanning for vulnerabilities detects known vulnerabilities in pipeline instructions and components, allowing faster patching in case one is found. These vulnerabilities can lead to a potentially massive breach if not handled as fast as possible, as attackers might also be aware of such vulnerabilities.", + "ImpactStatement": "", + "RemediationProcedure": "For each pipeline, set automated vulnerability scanning.", + "AuditProcedure": "For each pipeline, verify that it is automatically scanned for vulnerabilities.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.3.8", + "Description": "Detect and prevent sensitive data, such as confidential ID numbers, passwords, etc., in pipelines.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.3 Pipeline Instructions", + "Profile": "Level 2", + "AssessmentStatus": "Automated", + "Description": "Detect and prevent sensitive data, such as confidential ID numbers, passwords, etc., in pipelines.", + "RationaleStatement": "Sensitive data in pipeline configuration, such as cloud provider credentials or repository credentials, create vulnerabilities with which malicious actors could steal such information if they gain access to a pipeline. In order to mitigate this, set scanners that will identify and prevent the existence of sensitive data in the pipeline.", + "ImpactStatement": "", + "RemediationProcedure": "For every pipeline that is in use, set scanners that will identify and prevent sensitive data within it.", + "AuditProcedure": "For every pipeline that is in use, verify that scanners are set to identify and prevent the existence of sensitive data within it.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.4.1", + "Description": "Sign all artifacts in all releases with user or organization keys.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.4 Pipeline Integrity", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Sign all artifacts in all releases with user or organization keys.", + "RationaleStatement": "Signing artifacts is used to validate both their integrity and security. Organizations signal that artifacts may be trusted and they themselves produced them by ensuring that every artifact is properly signed. The presence of this signature also makes potentially malicious activity far more difficult.", + "ImpactStatement": "", + "RemediationProcedure": "For every artifact in every release, verify that all are properly signed.", + "AuditProcedure": "Ensure every artifact in every release is signed.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.4.2", + "Description": "External dependencies may be public packages needed in the pipeline, or perhaps the public image being used for the build worker. Lock these external dependencies in every build pipeline.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.4 Pipeline Integrity", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "External dependencies may be public packages needed in the pipeline, or perhaps the public image being used for the build worker. Lock these external dependencies in every build pipeline.", + "RationaleStatement": "External dependencies are sources of code that aren't under organizational control. They might be intentionally or unintentionally infected with malicious code or have known vulnerabilities, which could result in sensitive data exposure, data harvesting, or the erosion of trust in an organization. Locking each external dependency to a specific, safe version gives more control and less chance for risk.", + "ImpactStatement": "", + "RemediationProcedure": "For all external dependencies being used in pipelines, verify they are locked.", + "AuditProcedure": "Ensure every external dependency being used in pipelines is locked.", + "AdditionalInformation": "", + "References": "https://argon.io/blog/pipeline-composition-analysis-how-your-ci-pipeline-presents-new-opportunities-for-attackers/", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.4.3", + "Description": "Validate every dependency of the pipeline before use.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.4 Pipeline Integrity", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Validate every dependency of the pipeline before use.", + "RationaleStatement": "To ensure that a dependency used in a pipeline is trusted and has not been infected by malicious actor (for example, the codecov incident), validate dependencies before using them. This can be accomplished by comparing the checksum of the dependency to its checksum in a trusted source. If a difference arises, this is a sign that an unknown actor has interfered and may have added malevolent code. If this dependency is used, it will infect the environment, which could end in a massive breach and leave the organization exposed to data leaks, etc.", + "ImpactStatement": "", + "RemediationProcedure": "For every dependency used in every pipeline, validate each one.", + "AuditProcedure": "For every dependency used in every pipeline, ensure it has been validated.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.4.4", + "Description": "Verify that the build pipeline creates reproducible artifacts, meaning that an artifact of the build pipeline is the same in every run when given the same input.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.4 Pipeline Integrity", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Verify that the build pipeline creates reproducible artifacts, meaning that an artifact of the build pipeline is the same in every run when given the same input.", + "RationaleStatement": "A reproducible build is a build that produces the same artifact when given the same input data. Ensuring that the build pipeline produces the same artifact when given the same input helps verify that no change has been made to the artifact. This action allows an organization to trust that its artifacts are built only from safe code that has been reviewed and tested and has not been tainted or changed abruptly.", + "ImpactStatement": "", + "RemediationProcedure": "Create build pipelines that produce the same artifact given the same input (for example, artifacts that do not rely on timestamps).", + "AuditProcedure": "Ensure that build pipelines create reproducible artifacts.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.4.5", + "Description": "SBOM (Software Bill of Materials) is a file that specifies each component of software or a build process. Generate an SBOM after each run of a pipeline.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.4 Pipeline Integrity", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "SBOM (Software Bill of Materials) is a file that specifies each component of software or a build process. Generate an SBOM after each run of a pipeline.", + "RationaleStatement": "Generating a Software Bill of Materials after each run of a pipeline will validate the integrity and security of that pipeline. Recording every step or component role in the pipeline ensures that no malicious acts have been committed during the pipeline's run.", + "ImpactStatement": "", + "RemediationProcedure": "For each pipeline, configure it to produce a Software Bill of Materials on every run.", + "AuditProcedure": "For each pipeline, ensure it produces a Software Bill of Materials on every run.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "2.4.6", + "Description": "SBOM (Software Bill of Materials) is a file that specifies each component of software or a build process. It should be generated after every pipeline run. After it is generated, it must then be signed.", + "Checks": [], + "Attributes": [ + { + "Section": "2 Build Pipelines", + "Subsection": "2.4 Pipeline Integrity", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "SBOM (Software Bill of Materials) is a file that specifies each component of software or a build process. It should be generated after every pipeline run. After it is generated, it must then be signed.", + "RationaleStatement": "Software Bill of Materials (SBOM) is a file used to validate the integrity and security of a build pipeline. Signing it ensures that no one tampered with the file when it was delivered. Such interference can happen if someone tries to hide unusual activity. Validating the SBOM signature can detect this activity and prevent much greater incident.", + "ImpactStatement": "", + "RemediationProcedure": "For each pipeline, configure it to sign its produced Software Bill of Materials on every run.", + "AuditProcedure": "For each pipeline, ensure it signs the Software Bill of Materials it produces on every run.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.1", + "Description": "Ensure third-party artifacts and open-source libraries in use are trusted and verified.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure third-party artifacts and open-source libraries in use are trusted and verified.", + "RationaleStatement": "Verify third-party artifacts used in code are trusted and have not been infected by a malicious actor before use. This can be accomplished, for example, by comparing the checksum of the dependency to its checksum in a trusted source. If a difference arises, this may be a sign that someone interfered and added malicious code. If this dependency is used, it will infect the environment and could end in a massive breach, leaving the organization exposed to data leaks and more.", + "ImpactStatement": "", + "RemediationProcedure": "Verify every GitHub action (building block of a GitHub workflow) in use by performing the following: \n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the left sidebar, click **Actions**, then click **General**.\n4. Under \"Policies\", check **Allow OWNER, and select non-OWNER, actions and reusable workflows**, and then **Allow actions created by GitHub**.\n5. Click **Save**.\n\nAlternatively, perform the following for each repository where GitHub actions are used:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the left sidebar, click **Actions**, then click **General**.\n4. Under \"Actions permissions\", check **Allow OWNER, and select non-OWNER, actions and reusable workflows**, and then **Allow actions created by GitHub**.\n5. Click **Save**.", + "AuditProcedure": "For every GitHub action (building block of a GitHub workflow), ensure verification before use by performing the following: \n\n1. In the top right corner of GitHub.com, click your profile photo, then click **Your organizations**.\n2. Next to the organization, click **Settings**.\n3. In the left sidebar, click **Actions**, then click **General**.\n4. Under \"Policies\", ensure **Allow OWNER, and select non-OWNER, actions and reusable workflows**, and **Allow actions created by GitHub** are checked.\n\nAlternatively, perform the following for each repository where GitHub actions are used:\n\n1. On GitHub.com, navigate to the main page of the repository.\n2. Under your repository name, click **Settings**.\n3. In the left sidebar, click **Actions**, then click **General**.\n4. Under \"Actions permissions\", ensure **Allow OWNER, and select non-OWNER, actions and reusable workflows** and **Allow actions created by GitHub** are checked.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.2", + "Description": "A Software Bill Of Materials (SBOM) is a file that specifies each component of software or a build process. Require an SBOM from every third-party provider.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "A Software Bill Of Materials (SBOM) is a file that specifies each component of software or a build process. Require an SBOM from every third-party provider.", + "RationaleStatement": "A Software Bill of Materials (SBOM) for every third-party artifact helps to ensure an artifact is safe to use and fully compliant. This file lists all important metadata, especially all the dependencies of an artifact, and allows for verification of each dependency. If one of the dependencies/artifacts are attacked or has a new vulnerability (for example, the \"SolarWinds\" or even \"log4j\" attacks), it is easier to detect what has been affected by this incident because dependencies in use are listed in the SBOM file.", + "ImpactStatement": "", + "RemediationProcedure": "For every third-party dependency in use, require a Software Bill of Materials from its supplier.", + "AuditProcedure": "For every third-party dependency in use, ensure it has a Software Bill of Materials.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.3", + "Description": "Require and verify signed metadata of the build process for all dependencies in use.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Require and verify signed metadata of the build process for all dependencies in use.", + "RationaleStatement": "The metadata of a build process lists every action that took place during an artifact build. It is used to ensure that an artifact has not been compromised during the build, that no malicious code was injected into it, and that no nefarious dependencies were added during the build phase. This creates trust between user and vendor that the software supplied is exactly the software that was promised. Signing this metadata adds a checksum to ensure there have been no revisions since its creation, as this checksum changes when the metadata is altered. Verification of proper metadata signature with Certificate Authority confirms that the signature was produced by a trusted entity.", + "ImpactStatement": "", + "RemediationProcedure": "For each artifact in use, require and verify signed metadata of the build process.", + "AuditProcedure": "For each artifact used, ensure it was supplied with verified and signed metadata of its build process. The signature should be the organizational signature and should be verifiable by common Certificate Authority servers.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.4", + "Description": "Monitor, or ask software suppliers to monitor, dependencies between open-source components in use.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Monitor, or ask software suppliers to monitor, dependencies between open-source components in use.", + "RationaleStatement": "Monitoring dependencies between open-source components helps to detect if software has fallen victim to attack on a common open-source component. Swift detection can aid in quick application of a fix. It also helps find potential compliance problems with components usage. Some dependencies might not be compatible with the organization's policies, and other dependencies might have a license that is not compatible with how the organization uses this specific dependency. If dependencies are monitored, such situations can be detected and mitigated sooner, potentially deterring malicious attacks.", + "ImpactStatement": "", + "RemediationProcedure": "For each open-source component, monitor its dependencies.", + "AuditProcedure": "For each open-source component, ensure its dependencies are monitored.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.5", + "Description": "Prioritize trusted package registries over others when pulling a package.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Prioritize trusted package registries over others when pulling a package.", + "RationaleStatement": "When pulling a package by name, the package manager might look for it in several package registries, some of which may be untrusted or badly configured. If the package is pulled from such a registry, there is a higher likelihood that it could prove malicious. In order to avoid this, configure packages to be pulled from trusted package registries.", + "ImpactStatement": "", + "RemediationProcedure": "For each package to be downloaded, configure it to be downloaded from a trusted source.", + "AuditProcedure": "For each package registry in use, ensure it is trusted.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.6", + "Description": "A Software Bill of Materials (SBOM) is a file that specifies each component of software or a build process. When using a dependency, demand its SBOM and ensure it is signed for validation purposes.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "A Software Bill of Materials (SBOM) is a file that specifies each component of software or a build process. When using a dependency, demand its SBOM and ensure it is signed for validation purposes.", + "RationaleStatement": "A Software Bill of Materials (SBOM) creates trust between its provider and its users by ensuring that the software supplied is the software described, without any potential interference in between. Signing an SBOM creates a checksum for it, which will change if the SBOM's content was changed. With that checksum, a software user can be certain nothing had happened to it during the supply chain, engendering trust in the software. When there is no such trust in the software, the risk surface is increased because one cannot know if the software is potentially vulnerable. Demanding a signed SBOM and validating it decreases that risk.", + "ImpactStatement": "", + "RemediationProcedure": "For every artifact supplied, require and verify a signed Software Bill of Materials from its supplier.", + "AuditProcedure": "For every artifact supplied, ensure it has a validated, signed Software Bill of Materials.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.7", + "Description": "Pin dependencies to a specific version. Avoid using the \"latest\" tag or broad version.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Pin dependencies to a specific version. Avoid using the \"latest\" tag or broad version.", + "RationaleStatement": "When using a wildcard version of a package, or the \"latest\" tag, the risk of encountering a new, potentially malicious package increases. The \"latest\" tag pulls the last package pushed to the registry. This means that if an attacker pushes a new, malicious package successfully to the registry, the next user who pulls the \"latest\" will pull it and risk attack. This same rule applies to a wildcard version - assuming one is using version v1.*, it will install the latest version of the major version 1, meaning that if an attacker can push a malicious package with that same version, those using it will be subject to possible attack. By using a secure, verified version, use is restricted to this version only and no other may be pulled, decreasing the risk for any malicious package.", + "ImpactStatement": "", + "RemediationProcedure": "For every dependency in use, pin to a specific version.", + "AuditProcedure": "For every dependency in use, ensure it is pinned to a specific version.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.1.8", + "Description": "Use packages that are more than 60 days old.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.1 Third-Party Packages", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Use packages that are more than 60 days old.", + "RationaleStatement": "Third-party packages are a major risk since an organization cannot control their source code, and there is always the possibility these packages could be malicious. It is therefore good practice to remain cautious with any third-party or open-source package, especially new ones, until they can be verified that they are safe to use. Avoiding a new package allows the organization to fully examine it, its maintainer, and its behavior, and gives enough time to determine whether or not to use it.", + "ImpactStatement": "Developers may not use packages that are less than 60 days old.", + "RemediationProcedure": "If a package used is less than 60 days old, stop using it and find another solution.", + "AuditProcedure": "For every package used, ensure it is more than 60 days old.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.2.1", + "Description": "Enforce a policy for dependency usage across the organization. For example, disallow the use of packages less than 60 days old.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.2 Validate Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Enforce a policy for dependency usage across the organization. For example, disallow the use of packages less than 60 days old.", + "RationaleStatement": "Enforcing a policy for dependency usage in an organization helps to manage dependencies across the organization and ensure that all usage is compliant with security policy. If, for example, the policy limits the package managers that can be used, enforcing it will make sure that every dependency is installed only from these package managers, and limit the risk of installing from any untrusted source.", + "ImpactStatement": "", + "RemediationProcedure": "Enforce policies for dependency usage across the organization.", + "AuditProcedure": "Verify that a policy for dependency usage is enforced across the organization.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.2.2", + "Description": "Automatically scan every package for vulnerabilities.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.2 Validate Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Automatically scan every package for vulnerabilities.", + "RationaleStatement": "Automatic scanning for vulnerabilities detects known vulnerabilities in packages and dependencies in use, allowing faster patching when one is found. Such vulnerabilities can lead to a massive breach if not handled as fast as possible, as attackers will also know about those vulnerabilities and swiftly try to take advantage of them. Scanning packages regularly for vulnerabilities can also verify usage compliance with the organization's security policy.", + "ImpactStatement": "", + "RemediationProcedure": "Set automatic scanning of packages for vulnerabilities.", + "AuditProcedure": "Ensure automatic scanning of packages for vulnerabilities is enabled.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.2.3", + "Description": "A software license is a document that provides legal conditions and guidelines for the use and distribution of software, usually defined by the author. It is recommended to scan for any legal implications automatically.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.2 Validate Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "A software license is a document that provides legal conditions and guidelines for the use and distribution of software, usually defined by the author. It is recommended to scan for any legal implications automatically.", + "RationaleStatement": "When using packages with software licenses, especially commercial ones which tend to be the strictest, it is important to verify that the use of the package meets the conditions of the license. If the use of the package violates the licensing agreement, it exposes the organization to possible lawsuits. Scanning used packages for such license implications leads to faster detection and quicker fixes of such violations, and also reduces the risk for a lawsuit.", + "ImpactStatement": "", + "RemediationProcedure": "Set automatic package scanning for license implications.", + "AuditProcedure": "Ensure license implication rules are configured and are scanned automatically.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "3.2.4", + "Description": "Scan every package automatically for ownership change.", + "Checks": [], + "Attributes": [ + { + "Section": "3 Dependencies", + "Subsection": "3.2 Validate Packages", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Scan every package automatically for ownership change.", + "RationaleStatement": "A change in package ownership is not a regular action. In some cases it can lead to a massive problem (for example, the \"event-stream\" incident). Open-source contributors are not always trusted, since by its very nature everyone can contribute. This means malicious actors can become contributors as well. Package maintainers might transfer their ownership to someone they do not know if maintaining the package is too much for them, in some cases without the other user's knowledge. This has led to known security breaches in the past. It is best to be aware of such activity as soon as it happens and to carefully examine the situation before continuing using the package in order to determine its safety.", + "ImpactStatement": "", + "RemediationProcedure": "Set automatic scanning of packages for ownership change.", + "AuditProcedure": "Ensure automatic scanning of packages for ownership change is set.", + "AdditionalInformation": "", + "References": "https://blog.npmjs.org/post/182828408610/the-security-risks-of-changing-package-owners.html:https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.1.1", + "Description": "Configure the build pipeline to sign every artifact it produces and verify that each artifact has the appropriate signature.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.1 Verification", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Configure the build pipeline to sign every artifact it produces and verify that each artifact has the appropriate signature.", + "RationaleStatement": "A cryptographic signature can be used to verify artifact authenticity. The signature created with a certain key is unique and not reversible, thus making it unique to the author. This means that an attacker tampering with a signed artifact will be noticed immediately using a simple verification step because the signature will change. Signing artifacts by the build pipeline that produces them ensures the integrity of those artifacts.", + "ImpactStatement": "", + "RemediationProcedure": "Sign every artifact produced with the build pipeline that created it. Configure the build pipeline to sign each artifact.\n\nSteps from GitHub Documentation:\n\nYou can follow the steps below to sign artifacts in GitHub actions. The trick involves loading in your private key into GitHub Actions using the gpg command-line commands.\n\nExport your gpg private key from the system that you have created it.\nFind your key-id (using gpg --list-secret-keys --keyid-format=long)\nExport the gpg secret key to an ASCII file using gpg --export-secret-keys -a > secret.txt\nEdit secret.txt using a plain text editor, and replace all newlines with a literal \"\\n\" until everything is on a single line\nSet up GitHub Actions secrets\nCreate a secret called OSSRH_GPG_SECRET_KEY using the text from your edited secret.txt file (the whole text should be in a single line)\nCreate a secret called OSSRH_GPG_SECRET_KEY_PASSWORD containing the password for your gpg secret key\nCreate a GitHub Actions step to install the gpg secret key\nAdd an action similar to:\n```\n- id: install-secret-key\n name: Install gpg secret key\n run: |\n cat <(echo -e \"${{ secrets.OSSRH_GPG_SECRET_KEY }}\") | gpg --batch --import\n gpg --list-secret-keys --keyid-format LONG\n```\nVerify that the secret key is shown in the GitHub Actions logs\nYou can remove the output from list secret keys if you are confident that this action will work, but it is better to leave it in there\nBring it all together, and create a GitHub Actions step to publish\nAdd an action similar to:\n```\n- id: publish-to-central\n name: Publish to Central Repository\n env:\n MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}\n MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}\n run: |\n mvn \\\n --no-transfer-progress \\\n --batch-mode \\\n -Dgpg.passphrase=${{ secrets.OSSRH_GPG_SECRET_KEY_PASSWORD }} \\\n clean deploy\n```\nAfter a couple of hours, verify that the artifact got published to The Central Repository", + "AuditProcedure": "Verify that the build pipeline signs every new artifact it produces and all artifacts are signed.\n\nThere are many different signing tools or options each have there own method or commands to verify that the code or package created is signed.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds:https://gist.github.com/sualeh/ae78dc16123899d7942bc38baba5203c", + "DefaultValue": "Artifacts are not signed by Default." + } + ] + }, + { + "Id": "4.1.2", + "Description": "Encrypt artifacts before they are distributed and ensure only trusted platforms have decryption capabilities.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.1 Verification", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Encrypt artifacts before they are distributed and ensure only trusted platforms have decryption capabilities.", + "RationaleStatement": "Build artifacts might contain sensitive data such as production configurations. In order to protect them and decrease the risk for breach, it is recommended to encrypt them before delivery. Encryption makes data unreadable, so even if attackers gain access to these artifacts, they won't be able to harvest sensitive data from them without the decryption key.", + "ImpactStatement": "", + "RemediationProcedure": "Encrypt every artifact before distribution.", + "AuditProcedure": "Ensure every artifact is encrypted before it is delivered.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "Artifacts do not get encrypted by default." + } + ] + }, + { + "Id": "4.1.3", + "Description": "Grant decryption capabilities of artifacts only to trusted and authorized platforms.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.1 Verification", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Grant decryption capabilities of artifacts only to trusted and authorized platforms.", + "RationaleStatement": "Build artifacts might contain sensitive data such as production configuration. To protect them and decrease the risk of a breach, it is recommended to encrypt them before delivery. This will make them unreadable for every unauthorized user who doesn't have the decryption key. By implementing this, the decryption capabilities become overly sensitive in order to prevent a data leak or theft. Ensuring that only trusted and authorized platforms can decrypt the organization's packages decreases the possibility for an attacker to gain access to the critical data in artifacts.", + "ImpactStatement": "", + "RemediationProcedure": "Grant decryption capabilities of the organization's artifacts only for trusted and authorized platforms.", + "AuditProcedure": "Ensure only trusted and authorized platforms have decryption capabilities of the organization's artifacts.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.2.1", + "Description": "Software certification is used to verify the safety of certain software usage and to establish trust between the supplier and the consumer. Any artifact can be certified. Limit the authority to certify different artifacts.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.2 Access to Artifacts", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Software certification is used to verify the safety of certain software usage and to establish trust between the supplier and the consumer. Any artifact can be certified. Limit the authority to certify different artifacts.", + "RationaleStatement": "Artifact certification is a powerful tool in establishing trust. Clients use a software certificate to verify that the artifact is safe to use according to their security policies. Because of this, certifying artifacts is considered sensitive. If an artifact is for debugging or internal use, or if it were compromised, the organization would not want certification. An attacker gaining access to both certificate authority and the artifact registry might also be able to certify its own artifact and cause a major breach. To prevent these issues, limit which artifacts can be certified by which platform so there will be minimal access to certification.", + "ImpactStatement": "", + "RemediationProcedure": "Limit which artifact can be certified by which authority.", + "AuditProcedure": "Ensure only certain artifacts can be certified by certain parties.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.2.2", + "Description": "Minimize ability to upload artifacts to the lowest number of trusted users possible.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.2 Access to Artifacts", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Minimize ability to upload artifacts to the lowest number of trusted users possible.", + "RationaleStatement": "Artifacts might contain sensitive data. Even the simplest mistake can also lead to trust issues with customers and harm the integrity of the product. To decrease these risks, allow only trusted and qualified users to upload new artifacts. Those users are less likely to make mistakes. Having the lowest number of such users possible will also decrease the risk of hacked user accounts, which could lead to a massive breach or artifact compromising.", + "ImpactStatement": "", + "RemediationProcedure": "Allow only trusted and qualified users to upload new artifacts and limit them in number.", + "AuditProcedure": "Ensure only trusted and qualified users can upload new artifacts, and that their number is the lowest possible.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.2.3", + "Description": "Enforce Multi-Factor Authentication (MFA) for user access to the package registry.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.2 Access to Artifacts", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Enforce Multi-Factor Authentication (MFA) for user access to the package registry.", + "RationaleStatement": "By default, every user authenticates to the system by password only. If a user's password is compromised, the user account and all its related packages are in danger of data theft and malicious builds. It is therefore recommended that each user enables Multi-Factor Authentication. This additional step guarantees that the account stays secure even if the user's password is compromised, as it adds another layer of authentication.", + "ImpactStatement": "", + "RemediationProcedure": "For each package registry in use, enforce Multi-Factor Authentication as the only way to authenticate.", + "AuditProcedure": "For each package registry in use, verify that Multi-Factor Authentication is enforced and is the only way to authenticate.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.2.4", + "Description": "Manage users and their access to the package registry with an external authentication server and not with the package registry itself.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.2 Access to Artifacts", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Manage users and their access to the package registry with an external authentication server and not with the package registry itself.", + "RationaleStatement": "Some package registries offer a tool for user management, aside from the main Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server of the organization. That tool usually offers simple authentication and role-based permissions, which might not be granular enough. Having multiple user management tools in the organization could result in confusion and privilege escalation, as there will be more to manage. To avoid a situation where users escalate their privileges because someone missed them, manage user access to the package registry via the main authentication server and not locally on the package registry.", + "ImpactStatement": "", + "RemediationProcedure": "For each package registry, use the main authentication server of the organization for user management and do not manage locally.", + "AuditProcedure": "For each package registry, verify that its user access is not managed locally, but instead with the main authentication server of the organization.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.2.5", + "Description": "For GitHub Private or Internal repositories anonymous access is not available. Verify that all repos that require access controls are Private or Internal.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.2 Access to Artifacts", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "For GitHub Private or Internal repositories anonymous access is not available. Verify that all repos that require access controls are Private or Internal.", + "RationaleStatement": "Disable the option to view artifacts as an anonymous user in order to protect private artifacts from being exposed.", + "ImpactStatement": "Only logged and authorized users will be able to access artifacts.", + "RemediationProcedure": "Changing a repository's visibility\n\n1. On your GitHub Enterprise Server instance, navigate to the main page of the repository.\n1. Under your repository name, click Settings\n1. Under \"Danger Zone\", to the right of to \"Change repository visibility\", click Change visibility.\n1. Select a visibility.\n\n1. Choose \n - Mark private\n - Make Internal\n\n6. To verify that you're changing the correct repository's visibility, type the name of the repository you want to change the visibility of.", + "AuditProcedure": "To Audit the existing settings:\n\n1. On your GitHub Enterprise Server instance, navigate to the main page of the repository.\n1. Under your repository name, click Settings\n3. Under \"Danger Zone\", to the right of to \"Change repository visibility\", click Change visibility.\n\nReview the current selection.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/enterprise-server@3.3/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.2.6", + "Description": "Ensure the package registry has a minimum number of administrators.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.2 Access to Artifacts", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Ensure the package registry has a minimum number of administrators.", + "RationaleStatement": "Package registry admins have the ability to add/remove users, repositories, packages. Due to the permissive access granted to an admin, it is highly recommended to keep the number of administrator accounts as minimal as possible.", + "ImpactStatement": "Administrator privileges are required to provide and maintain a secure and stable platform but allowing extraneous administrator accounts can create a vulnerability.", + "RemediationProcedure": "Set the minimum number of administrators in your package registry.\n\nTo accomplish this:\n\nFor each repository that you administer on GitHub, you can see an overview of every team or person with access to the repository. From the overview, choose Manage access and provide access to the appropriate people or teams.", + "AuditProcedure": "Verify that your package registry has only the minimum number of administrators.\n\nFor each repository that you administer on GitHub, you can see an overview of every team or person with access to the repository. From the overview, you can also invite new teams or people, change each team or person's role for the repository, or remove access to the repository.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.3.1", + "Description": "Validate artifact signatures before uploading to the package registry.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.3 Package Registries", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Validate artifact signatures before uploading to the package registry.", + "RationaleStatement": "Cryptographic signature is a tool to verify artifact authenticity. Every artifact is supposed to be signed by its creator in order to confirm that it was not compromised before reaching the client. Validating an artifact signature before delivering it is another level of protection which ensures the signature has not been changed, meaning no one tried or succeeded in tampering with the artifact. This creates trust between the supplier and the client.", + "ImpactStatement": "", + "RemediationProcedure": "Validate every artifact with its signature before uploading it to the package registry. It is recommended to do so automatically.", + "AuditProcedure": "Ensure every artifact in the package registry has been validated with its signature.\n\n1. On GitHub, navigate to a pull request\n2. On the pull request, click <> Commits and view the detailed information regarding the signature.", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification:https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits", + "DefaultValue": "Artifacts are not scanned by default." + } + ] + }, + { + "Id": "4.3.2", + "Description": "Validate the signature of all versions of an existing artifact.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.3 Package Registries", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Validate the signature of all versions of an existing artifact.", + "RationaleStatement": "In order to be certain a version of an existing and trusted artifact is not malicious or delivered by someone looking to interfere with the supply chain, it is a good practice to validate the signatures of each version. Doing so decreases the risk of using a compromised artifact, which might lead to a breach.", + "ImpactStatement": "", + "RemediationProcedure": "For each artifact, sign and validate each version before uploading or using the artifact.", + "AuditProcedure": "For each artifact, ensure that all of its versions are signed and validated before it is uploaded or used.\n\nEnsure every artifact in the package registry has been validated with its signature.\n\nOn GitHub, navigate to a pull request\nOn the pull request, click <> Commits and view the detailed information regarding the signature.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.3.3", + "Description": "Audit changes of the package registry configuration.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.3 Package Registries", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Audit changes of the package registry configuration.", + "RationaleStatement": "The package registry is a crucial component in the software supply chain. It stores artifacts with potentially sensitive data that will eventually be deployed and used in production. Every change made to the package registry configuration must be examined carefully to ensure no exposure of the registry's sensitive data. This examination also ensures no malicious actors have performed modifications to a stored artifact. Auditing the configuration and its changes helps in decreasing such risks.", + "ImpactStatement": "", + "RemediationProcedure": "Audit the changes to the package registry configuration.", + "AuditProcedure": "Verify that all changes to the packages registry configuration are audited.\n\nSearch the audit log with\n\nrepo category actions", + "AdditionalInformation": "", + "References": "https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization", + "DefaultValue": "GitHub audits this by default." + } + ] + }, + { + "Id": "4.3.4", + "Description": "Use secured webhooks to reduce the possibility of malicious payloads.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.3 Package Registries", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Use secured webhooks to reduce the possibility of malicious payloads.", + "RationaleStatement": "Webhooks are used for triggering an HTTP request based on an action made in the platform. Typically, package registries feature webhooks when a package receives an update. Since webhooks are an HTTP POST request, they can be malformed if not secured over SSL. To prevent a potential hack and compromise of the webhook or to the registry or web server excepting the request, use only secured webhooks.", + "ImpactStatement": "Reduces the payloads that the web hook can listen for and receive.", + "RemediationProcedure": "For each webhook in use, change it to secured (over HTTPS).", + "AuditProcedure": "", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "4.4.1", + "Description": "When delivering artifacts, ensure they have information about their origin. This may be done by providing a Software Bill of Manufacture (SBOM) or some metadata files.", + "Checks": [], + "Attributes": [ + { + "Section": "4 Artifacts", + "Subsection": "4.4 Origin Traceability", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "When delivering artifacts, ensure they have information about their origin. This may be done by providing a Software Bill of Manufacture (SBOM) or some metadata files.", + "RationaleStatement": "Information about artifact origin can be used for verification purposes. Having this kind of information allows the user to decide if the organization supplying the artifact is trusted. In a case of potential vulnerability or version update, this can be used to verify that the organization issuing it is the actual origin and not someone else. If users need to report problems with the artifact, they will have an address to contact as well.", + "ImpactStatement": "", + "RemediationProcedure": "For each artifact supplied, supply information about its origin. For each artifact in use, ask for information about its origin.", + "AuditProcedure": "For each artifact, ensure it has information about its origin.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.1.1", + "Description": "Deployment configurations are often stored in a version control system. Separate deployment configuration files from source code repositories.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.1 Deployment Configuration", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Deployment configurations are often stored in a version control system. Separate deployment configuration files from source code repositories.", + "RationaleStatement": "Deployment configuration manifests are often stored in version control systems. Storing them in dedicated repositories, separately from source code repositories, has several benefits. First, it adds order to both maintenance and version control history. This makes it easier to track code or manifest changes, as well as spot any malicious code or misconfigurations. Second, it helps achieve the Least Privilege principle. Because access can be configured differently for each repository, fewer users will have access to this configuration, which is typically sensitive.", + "ImpactStatement": "", + "RemediationProcedure": "Store each deployment configuration file in a dedicated repository separately from source code.", + "AuditProcedure": "Ensure each deployment configuration file is stored separately from source code.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.1.2", + "Description": "Audit and track changes made in deployment configuration.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.1 Deployment Configuration", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Audit and track changes made in deployment configuration.", + "RationaleStatement": "Deployment configuration is sensitive in nature. The tiniest mistake can lead to downtime or bugs in production, which consequently may have a direct effect on both product integrity and customer trust. Misconfigurations might also be used by malicious actors to attack the production platform. Because of this, every change in the configuration needs a review and possible \"revert\" in case of a mistake or malicious change. Auditing every change and tracking them helps detect and fix such incidents more quickly.", + "ImpactStatement": "", + "RemediationProcedure": "For each deployment configuration, track and audit changes made to it.", + "AuditProcedure": "For each deployment configuration, ensure changes made to it are audited and tracked.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.1.3", + "Description": "Detect and prevent sensitive data – such as confidential ID numbers, passwords, etc. – in deployment configurations.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.1 Deployment Configuration", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Detect and prevent sensitive data – such as confidential ID numbers, passwords, etc. – in deployment configurations.", + "RationaleStatement": "Sensitive data in deployment configurations might create a major incident if an attacker gains access to it, as this can cause data loss and theft. It is important to keep sensitive data safe and to not expose it in the configuration. In order to prevent a possible exposure, set scanners that will identify and prevent such data in deployment configurations.", + "ImpactStatement": "", + "RemediationProcedure": "For each deployment configuration file, set scanners to identify and prevent sensitive data within it.", + "AuditProcedure": "For each deployment configuration file, verify that scanners are set to identify and prevent the existence of sensitive data within it.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.1.4", + "Description": "Restrict access to the deployment configuration to trusted and qualified users only.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.1 Deployment Configuration", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Restrict access to the deployment configuration to trusted and qualified users only.", + "RationaleStatement": "Deployment configurations are sensitive in nature. The tiniest mistake can lead to downtime or bugs in production, which can have a direct effect on the product's integrity and customer trust. Misconfigurations might also be used by malicious actors to attack the production platform. To avoid such harm as much as possible, ensure only trusted and qualified users have access to such configurations. This will also reduce the number of accounts that might affect the environment in case of an attack.", + "ImpactStatement": "Reducing the number of users who have access to the deployment configuration means those users would lose their ability to make direct changes to that configuration.", + "RemediationProcedure": "Restrict access to the deployment configuration to trusted and qualified users.", + "AuditProcedure": "Verify each deployment configuration is accessible only to known and authorized users.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.1.5", + "Description": "Detect and prevent misconfigurations or insecure instructions in Infrastructure as Code (IaC) files, such as Terraform files.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.1 Deployment Configuration", + "Profile": "Level 2", + "AssessmentStatus": "Manual", + "Description": "Detect and prevent misconfigurations or insecure instructions in Infrastructure as Code (IaC) files, such as Terraform files.", + "RationaleStatement": "Infrastructure as Code (IaC) files are used for production environment and application deployment. These are sensitive parts of the software supply chain because they are always in touch with customers, and thus might affect their opinion of or trust in the product. Attackers often target these environments. Detecting and fixing misconfigurations and/or insecure instructions in IaC files decreases the risk for data leak or data theft. It is important to secure IaC instructions in order to prevent further problems of deployment, exposed assets, or improper configurations, which might ultimately lead to easier ways to attack and steal organization data.", + "ImpactStatement": "", + "RemediationProcedure": "For every Infrastructure as Code (IaC) instructions file, set scanners to identify and prevent misconfigurations and insecure instructions.", + "AuditProcedure": "For every Infrastructure as Code (IaC) instructions file, verify that scanners are set to identify and prevent misconfigurations and insecure instructions.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.1.6", + "Description": "Verify the deployment configuration manifests.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.1 Deployment Configuration", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Verify the deployment configuration manifests.", + "RationaleStatement": "To ensure that the configuration manifests used are trusted and have not been infected by malicious actors before arriving at the platform, it is important to verify the manifests. This may be done by comparing the checksum of the manifest file to its checksum in a trusted source. If a difference arises, this is a sign that an unknown actor has interfered and may have added malicious instructions. If this manifest is used, it might harm the environment and application deployment, which could end in a massive breach and leave the organization exposed to data leaks, etc.", + "ImpactStatement": "", + "RemediationProcedure": "Verify each deployment configuration manifest in use.", + "AuditProcedure": "For each deployment configuration manifest in use, ensure it has been verified.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.1.7", + "Description": "Deployment configuration is often stored in a version control system and is pulled from there. Pin the configuration used to a specific, verified version or commit Secure Hash Algorithm (SHA). Avoid referring configuration without its version tag specified.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.1 Deployment Configuration", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Deployment configuration is often stored in a version control system and is pulled from there. Pin the configuration used to a specific, verified version or commit Secure Hash Algorithm (SHA). Avoid referring configuration without its version tag specified.", + "RationaleStatement": "Deployment configuration manifests are often stored in version control systems and pulled from there either by automation platforms, for example Ansible, or GitOps platforms, such as ArgoCD. When a manifest is pulled from a version control system without tag or commit Secure Hash Algorithm (SHA) specified, it is pulled from the HEAD revision, which is equal to the 'latest' tag, and pulls the last change made. This increases the risk of encountering a new, potentially malicious configuration. If an attacker pushes malicious configuration to the version control system, the next user who pulls the HEAD revision will pull it and risk attack. To avoid that risk, use a version tag of verified version or a commit SHA of a trusted commit, which will ensure this is the only version pulled.", + "ImpactStatement": "Changes in deployment configuration will not be pulled unless their version tag or commit Secure Hash Algorithm (SHA) is specified. This might slow down the deployment process.", + "RemediationProcedure": "For every deployment configuration manifest in use, pin to a specific version or commit Secure Hash Algorithm (SHA).", + "AuditProcedure": "For every deployment configuration manifest in use, ensure it is pinned to a specific version or commit Secure Hash Algorithm (SHA).", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.2.1", + "Description": "Automate deployments of production environment and application.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.2 Deployment Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Automate deployments of production environment and application.", + "RationaleStatement": "Automating the deployments of both production environment and applications reduces the risk for human mistakes — such as a wrong configuration or exposure of sensitive data — because it requires less human interaction or intervention. It also eases redeployment of the environment. It is best to automate with Infrastructure as Code (IaC) because it offers more control over changes made to the environment creation configuration and stores to a version control platform.", + "ImpactStatement": "", + "RemediationProcedure": "Automate each deployment process of the production environment and application.", + "AuditProcedure": "For each deployment process, ensure it is automated.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.2.2", + "Description": "Verify that the deployment environment – the orchestrator and the production environment where the application is deployed – is reproducible. This means that the environment stays the same in each deployment if the configuration has not changed.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.2 Deployment Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Verify that the deployment environment – the orchestrator and the production environment where the application is deployed – is reproducible. This means that the environment stays the same in each deployment if the configuration has not changed.", + "RationaleStatement": "A reproducible build is a build that produces the same artifact when given the same input data, and in this case the same environment. Ensuring that the same environment is produced when given the same input helps verify that no change has been made to it. This action allows an organization to trust that its deployment environment is built only from safe code and configuration that has been reviewed and tested and has not been tainted or changed abruptly.", + "ImpactStatement": "", + "RemediationProcedure": "Adjust the process that deploys the deployment/production environment to build the same environment each time when the configuration has not changed.", + "AuditProcedure": "Verify that the deployment/production environment is reproducible.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.2.3", + "Description": "Restrict access to the production environment to a few trusted and qualified users only.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.2 Deployment Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Restrict access to the production environment to a few trusted and qualified users only.", + "RationaleStatement": "The production environment is an extremely sensitive one. It directly affects the customer experience and trust in a product, which has serious effects on the organization itself. Because of this sensitive nature, it is important to restrict access to the production environment to only a few trusted and qualified users. This will reduce the risk of mistakes such as exposure of secrets or misconfiguration. This restriction also reduces the number of accounts that are vulnerable to hijacking in order to potentially harm the production environment.", + "ImpactStatement": "Reducing the number of users who have access to the production environment means those users would lose their ability to make direct changes to that environment.", + "RemediationProcedure": "Restrict access to the production environment to trusted and qualified users.", + "AuditProcedure": "Verify that the production environment is accessible only to trusted and qualified users.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + }, + { + "Id": "5.2.4", + "Description": "Do not use default passwords of deployment tools and components.", + "Checks": [], + "Attributes": [ + { + "Section": "5 Deployment", + "Subsection": "5.2 Deployment Environment", + "Profile": "Level 1", + "AssessmentStatus": "Manual", + "Description": "Do not use default passwords of deployment tools and components.", + "RationaleStatement": "Many deployment tools and components are provided with default passwords for the first login. This password is intended to be used only on the first login and should be changed immediately after. Using the default password substantially increases the attack risk. It is very important to ensure that default passwords are not used in deployment tools and components.", + "ImpactStatement": "", + "RemediationProcedure": "For each deployment tool, change the password.", + "AuditProcedure": "For each deployment tool, ensure the password is not the default one.", + "AdditionalInformation": "", + "References": "", + "DefaultValue": "" + } + ] + } + ] +}