diff --git a/.regal/config.yaml b/.regal/config.yaml index a8633f90..b106eaf0 100644 --- a/.regal/config.yaml +++ b/.regal/config.yaml @@ -5,8 +5,8 @@ rules: level: ignore style: file-length: - # Override default of 500 as one file has 515 lines - max-file-length: 550 + # Override default of 500 as one file has 690 lines + max-file-length: 750 line-length: # Violations here mostly from metadata annotation values. # These could be fixed by using |> and newlines, but we'll diff --git a/policies/bundle_test.go b/policies/bundle_test.go index e73caea0..d3ce159b 100644 --- a/policies/bundle_test.go +++ b/policies/bundle_test.go @@ -2,9 +2,10 @@ package policies import ( "embed" - "github.com/stretchr/testify/require" "path" "testing" + + "github.com/stretchr/testify/require" ) func countFiles(fs embed.FS, p string) (int, error) { @@ -46,5 +47,5 @@ func TestPoliciesBundle(t *testing.T) { count, err := countBundles() require.Nilf(t, err, "counting files: %v", err) - require.Equal(t, count, 10, "Expecting 10 files in bundle") + require.Equal(t, count, 9, "Expecting 9 files in bundle") } diff --git a/policies/github/actions.rego b/policies/github/actions.rego index 8d10bd3e..2ff0c443 100644 --- a/policies/github/actions.rego +++ b/policies/github/actions.rego @@ -6,16 +6,21 @@ package actions # description: By not limiting GitHub Actions to specific repositories, every user in the organization is able to run arbitrary workflows. This could enable malicious activity such as accessing organization secrets, crypto-mining, etc. # custom: # requiredEnrichers: [organizationId] -# remediationSteps: [Make sure you have admin permissions, Go to the org's settings page, Enter the "Actions - General" tab, Under "Policies", Change "All repositories" to "Selected repositories" and select repositories that should be able to run actions, Click "Save"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the org's settings page +# - 3. Enter the 'Actions - General' tab +# - 4. Under 'Policies', Change 'All repositories' to 'Selected repositories' and select repositories that should be able to run actions +# - 5. Click 'Save' # severity: MEDIUM # requiredScopes: [admin:org] -# threat: -# - "This misconfiguration could lead to the following attack:" -# - "1. Prerequisite: the attacker is part of your GitHub organization" -# - "2. Attacker creates new repository in the organization" -# - "3. Attacker creates a workflow file that reads all organization secrets and exfiltrate them" -# - "4. Attacker trigger the workflow" -# - "5. Attacker receives all organization secrets and uses them maliciously" +# threat: +# - This misconfiguration could lead to the following attack: +# - 1. Prerequisite: the attacker is part of your GitHub organization +# - 2. Attacker creates new repository in the organization +# - 3. Attacker creates a workflow file that reads all organization secrets and exfiltrate them +# - 4. Attacker trigger the workflow +# - 5. Attacker receives all organization secrets and uses them maliciously # requiredScopes: [admin:org] default all_repositories_can_run_github_actions := true @@ -29,14 +34,21 @@ all_repositories_can_run_github_actions := false { # description: It is recommended to only use GitHub Actions by Marketplace verified creators or explicitly trusted actions. By not restricting which actions are permitted, developers may use actions that were not audited and may be malicious, thus exposing your pipeline to supply chain attacks. # custom: # requiredEnrichers: [organizationId] -# remediationSteps: [Make sure you have admin permissions, Go to the org's settings page, Enter "Actions - General" tab, Under "Policies", 'Select "Allow enterprise, and select non-enterprise, actions and reusable workflows"', Check "Allow actions created by GitHub" and "Allow actions by Marketplace verified creators", Set any other used trusted actions under "Allow specified actions and reusable workflows", Click "Save"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the org's settings page +# - 3. Enter 'Actions - General' tab +# - 4. Under 'Policies', Select 'Allow enterprise, and select non-enterprise, actions and reusable workflows' +# - 5. Check 'Allow actions created by GitHub' and 'Allow actions by Marketplace verified creators' +# - 6. Set any other used trusted actions under 'Allow specified actions and reusable workflows' +# - 7. Click 'Save' # severity: MEDIUM # requiredScopes: [admin:org] # threat: -# - "This misconfiguration could lead to the following attack:" -# - "1. Attacker creates a repository with a tempting but malicious custom GitHub Action" -# - "2. An innocent developer / DevOps engineer uses this malicious action" -# - "3. The malicious action has access to the developer repository and could steal its secrets or modify its content" +# - This misconfiguration could lead to the following attack: +# - 1. Attacker creates a repository with a tempting but malicious custom GitHub Action +# - 2. An innocent developer / DevOps engineer uses this malicious action +# - 3. The malicious action has access to the developer repository and could steal its secrets or modify its content default all_github_actions_are_allowed := true all_github_actions_are_allowed := false { @@ -50,12 +62,12 @@ all_github_actions_are_allowed := false { # custom: # requiredEnrichers: [organizationId] # remediationSteps: -# - Make sure you have admin permissions -# - Go to the org's settings page -# - Enter "Actions - General" tab -# - Under 'Workflow permissions' -# - Select 'Read repository contents permission' -# - Click 'Save' +# - 1. Make sure you have admin permissions +# - 2. Go to the org's settings page +# - 3. Enter 'Actions - General' tab +# - 4. Under 'Workflow permissions' +# - 5. Select 'Read repository contents permission' +# - 6. Click 'Save' # severity: MEDIUM # requiredScopes: [admin:org] # threat: In case of token compromise (due to a vulnerability or malicious third-party GitHub actions), an attacker can use this token to sabotage various assets in your CI/CD pipeline, such as packages, pull-requests, deployments, and more. @@ -72,12 +84,12 @@ token_default_permissions_is_read_write := false { # custom: # requiredEnrichers: [organizationId] # remediationSteps: -# - Make sure you have admin permissions -# - Go to the org's settings page -# - Enter "Actions - General" tab -# - Under 'Workflow permissions' -# - Uncheck 'Allow GitHub actions to create and approve pull requests. -# - Click 'Save' +# - 1. Make sure you have admin permissions +# - 2. Go to the org's settings page +# - 3. Enter 'Actions - General' tab +# - 4. Under 'Workflow permissions' +# - 5. Uncheck 'Allow GitHub actions to create and approve pull requests' +# - 6. Click 'Save' # severity: HIGH # requiredScopes: [admin:org] # threat: Attackers can exploit this misconfiguration to bypass code-review restrictions by creating a workflow that approves their own pull request and then merging the pull request without anyone noticing, introducing malicious code that would go straight ahead to production. diff --git a/policies/github/enterprise.rego b/policies/github/enterprise.rego index 2695aa81..9fb4d0b2 100644 --- a/policies/github/enterprise.rego +++ b/policies/github/enterprise.rego @@ -3,13 +3,16 @@ package enterprise # METADATA # scope: rule # title: Enterprise Should Prevent Repository Admins From Changing Repository Visibility -# description: The enterprise's Repository visibility change policy should be set to DISABLED. This will prevents users from creating private repositories and change them to be public. Malicous actors could leak code if enabled. +# description: The enterprise's Repository visibility change policy should be set to DISABLED. This will prevent users from creating private repositories and changing them to be public. Malicious actors could leak code if enabled. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the policies page, Under the "Repository visibility change" section, choose the "Disabled" option] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the policies page +# - 3. Under the 'Repository visibility change' section, choose the 'Disabled' option # requiredScopes: [admin:enterprise] # threat: -# - "A member of the organization could inadvertently or maliciously make public an internal repository exposing confidential data." +# - A member of the organization could inadvertently or maliciously make public an internal repository exposing confidential data. default enterprise_not_using_visibility_change_disable_policy := true enterprise_not_using_visibility_change_disable_policy := false { @@ -23,7 +26,10 @@ enterprise_not_using_visibility_change_disable_policy := false { # description: The enterprise's repository forking policy should be set to DISABLED. Forking a repository can lead to loss of control and potential exposure of source code. If you do not need forking, it is recommended to turn it off in the project's configuration. The option to fork should be enabled only by owners deliberately when opting to create a fork. # custom: # severity: LOW -# remediationSteps: [Make sure you are an enterprise owner, Go to the policies page, Under the "Repository Forking" section, Choose the "Disabled" option] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the policies page +# - 3. Under the 'Repository Forking' section, Choose the 'Disabled' option # requiredScopes: [admin:enterprise] # threat: # - Forking to external namespaces could result in loss of control over proprietary information and potentially expose the organization to security risks, such as data leaks. @@ -36,14 +42,17 @@ enterprise_allows_forking_repos := false { # METADATA # scope: rule -# title: Enterprise Should Prevent Members From Creating public Repositories -# description: The enterprise's repository creation policy should be set to private/internal repositories only. This will prevents non-admin users from creating public repositories and potentially exposing source code. +# title: Enterprise Should Prevent Members From Creating Public Repositories +# description: The enterprise's repository creation policy should be set to private/internal repositories only. This will prevent non-admin users from creating public repositories and potentially exposing source code. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the policies page, Under the "Repository creation" section, Choose the "Members can create repositories" option and uncheck 'Public'] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the policies page +# - 3. Under the 'Repository creation' section, Choose the 'Members can create repositories' option and uncheck 'Public' # requiredScopes: [admin:enterprise] # threat: -# - Users can accidentaly create public repositories and expose source code. +# - Users can accidentally create public repositories and expose source code. default enterprise_allows_creating_public_repos := true enterprise_allows_creating_public_repos := false { @@ -54,10 +63,13 @@ enterprise_allows_creating_public_repos := false { # METADATA # scope: rule # title: Enterprise Should Prevent Members From Inviting Outside Collaborators -# description: The enterprise's external collaborators invite policy should be set to enterprise/organization owners only. Allowing members to invite external collaborators might result in unauthorized access to the internal projects. +# description: The enterprise's external collaborators invite policy should be set to enterprise/organization owners only. Allowing members to invite external collaborators might result in unauthorized access to internal projects. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the policies page, Under the "Repository outside collaborators" section - choose the "Enterprise Owners Only" or the "Organization Owners Only" option] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the policies page +# - 3. Under the 'Repository outside collaborators' section, choose the 'Enterprise Owners Only' or the 'Organization Owners Only' option # requiredScopes: [admin:enterprise] # threat: # - Inviting external collaborators could result in a loss of control over proprietary information and potentially expose the organization to security risks, such as data leaks. @@ -70,13 +82,17 @@ enterprise_allows_inviting_externals_collaborators := false { # METADATA # scope: rule # title: Two-Factor Authentication Should Be Enforced For The Enterprise -# description: The two-factor authentication requirement should be enforced at the enterprise level. Regardless of whether users are managed externally by SSO, it is highly recommended to enable this option to reduce the risk of a deliberate or accidental user creation without MFA. +# description: The two-factor authentication requirement should be enforced at the enterprise level. Regardless of whether users are managed externally by SSO, it is highly recommended to enable this option to reduce the risk of deliberate or accidental user creation without MFA. # custom: # severity: HIGH -# remediationSteps: [Make sure you are an enterprise owner, Go to the Settings page, Go to the Authentication security tab, Check the "Require two-factor authentication for all organizations in the enterprise" checkbox] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Settings page +# - 3. Go to the Authentication security tab +# - 4. Check the 'Require two-factor authentication for all organizations in the enterprise' checkbox # requiredScopes: [admin:enterprise] # threat: -# - If an attacker gets the valid credentials for one of the enterprise’s users they can authenticate to your GitHub enterprise. +# - If an attacker gets valid credentials for one of the enterprise’s users they can authenticate to your GitHub enterprise. default enterprise_enforce_two_factor_authentication := true enterprise_enforce_two_factor_authentication := false { @@ -87,10 +103,16 @@ enterprise_enforce_two_factor_authentication := false { # METADATA # scope: rule # title: Enterprise Should Use Single-Sign-On -# description: It is recommended to enable access to an enterprise via SAML single sign-on (SSO) by authenticating through an identity provider (IdP). This allows for central account control and for timely access revocations. +# description: It is recommended to enable access to an enterprise via SAML single sign-on (SSO) by authenticating through an identity provider (IdP). This allows for central account control and timely access revocations. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the Settings page, Go to the Authentication security tab, Toggle on "Enable SAML authentication", Fill in the remaining SSO configuration as instructed on the screen, Click "Save"] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Settings page +# - 3. Go to the Authentication security tab +# - 4. Toggle on 'Enable SAML authentication' +# - 5. Fill in the remaining SSO configuration as instructed on the screen +# - 6. Click 'Save' # requiredScopes: [admin:enterprise] # threat: Not using an SSO solution makes it more difficult to track a potentially compromised user's actions across different systems, prevents common password policy throughout the enterprise, and makes it challenging to audit different aspects of the user's behavior. default enterprise_not_using_single_sign_on := true @@ -101,11 +123,15 @@ enterprise_not_using_single_sign_on := false { # METADATA # scope: rule -# title: Enterprise Should Define Base Permissions As “No Permission” For All Members +# title: Enterprise Should Define Base Permissions As 'No Permission' For All Members # description: Collaborators in your organizations should receive access to specific organizations and repositories as necessary, and not have read and write access to all repositories across the enterprise. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the Settings page, Under the ‘Policies’ tab, choose ‘Repositories’, Under ‘Base Permission’ choose ‘No Permission’] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Settings page +# - 3. Under the 'Policies' tab, choose 'Repositories' +# - 4. Under 'Base Permission' choose 'No Permission' # requiredScopes: [admin:enterprise] # threat: An adversary will have access to all repositories in the enterprise, instead of just a part of them. default repository_no_permission_enforced_by_default := true @@ -120,7 +146,11 @@ repository_no_permission_enforced_by_default := false { # description: The enterprise’s Repository deletion and transfer policy should be set to DISABLED. This will prevent repository admins from deleting a repo or transferring it to a different owner or organization. Malicious actors could leak code if enabled. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the Enterprise Settings page, Under the ‘Policies’ tab choose ‘Repositories’, Go to the ‘Admin repository permissions' section, under ‘Repository deletion and transfer' and select 'Disabled'] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Enterprise Settings page +# - 3. Under the ‘Policies’ tab choose ‘Repositories’ +# - 4. Go to the ‘Admin repository permissions' section, under ‘Repository deletion and transfer' and select 'Disabled' # requiredScopes: [admin:enterprise] # threat: A member of the organization could inadvertently or maliciously transfer a repository to an external namespace and expose confidential data. default memberes_allowed_repository_move_or_deletion := true @@ -131,12 +161,15 @@ memberes_allowed_repository_move_or_deletion := false { # METADATA # scope: rule -# custom: -# severity: MEDIUM # title: Enterprise Should Automatically Enable Advanced Security Across All Organizations/Repositories # description: Advanced Security includes code scanning, secret scanning and dependency review. These features protect your repositories from containing vulnerable data. Prevents the risk of unauthorized access or exploitation of vulnerabilities. # custom: -# remediationSteps: [Make sure you are an enterprise owner, Go to the Enterprise Settings page, Under the ‘Settings’ tab choose ‘Code security and analysis’, Check 'Automatically enable for new repositories'] +# severity: MEDIUM +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Enterprise Settings page +# - 3. Under the ‘Settings’ tab choose ‘Code security and analysis’ +# - 4. Check 'Automatically enable for new repositories' # requiredScopes: [admin:enterprise] default enable_ghas_for_new_orgs := true @@ -150,7 +183,11 @@ enable_ghas_for_new_orgs := false { # description: Enable GitHub Advanced Security secret scanning to alert on sensitive data that exists in your enterprise. Secrets shouldn’t be hard-coded in to your repositories as they will be retrievable by anyone with access to the repository. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the Enterprise Settings page, Under the ‘Settings’ tab choose ‘Code security and analysis’, Check 'Automatically enable for new repositories with Advanced Security enabled'] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Enterprise Settings page +# - 3. Under the ‘Settings’ tab choose ‘Code security and analysis’ +# - 4. Check 'Automatically enable for new repositories with Advanced Security enabled' # requiredScopes: [admin:enterprise] default enable_secret_scanning_for_new_orgs := true @@ -164,7 +201,11 @@ enable_secret_scanning_for_new_orgs := false { # description: The enterprise should prevent sensitive data from being pushed to all repositories, to prevent it from being exposed to anyone with access to the repository. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the Enterprise Settings page, Under the ‘Settings’ tab choose ‘Code security and analysis’, Check 'Automatically enable for repositories added to secret scanning'] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Enterprise Settings page +# - 3. Under the ‘Settings’ tab choose ‘Code security and analysis’ +# - 4. Check 'Automatically enable for repositories added to secret scanning' # requiredScopes: [admin:enterprise] default enable_push_protection_secret_scanning := true @@ -178,7 +219,13 @@ enable_push_protection_secret_scanning := false { # description: The enterprise should mitigate the leakage of sensitive data by allowing email notifications to be sent only to verified or approved domains. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you are an enterprise owner, Go to the Enterprise Landing page, Under the ‘Settings’ tab on the left click ‘Verified & approved domains’, Press the 'Add a domain' button and follow the instructions in the menu, Check the 'Restrict email notifications to only approved or verified domains' box, Press 'Save'] +# remediationSteps: +# - 1. Make sure you are an enterprise owner +# - 2. Go to the Enterprise Landing page +# - 3. Under the ‘Settings’ tab on the left click ‘Verified & approved domains’ +# - 4. Press the 'Add a domain' button and follow the instructions in the menu +# - 5. Check the 'Restrict email notifications to only approved or verified domains' box +# - 6. Press 'Save' # requiredScopes: [admin:enterprise] default enable_email_notification_to_verified_domains := true diff --git a/policies/github/member.rego b/policies/github/member.rego index 53803e55..f4d59871 100644 --- a/policies/github/member.rego +++ b/policies/github/member.rego @@ -6,13 +6,17 @@ import data.common.members as memberUtils # title: Organization Should Have Fewer Than Three Owners # description: Organization owners are highly privileged and could create great damage if they are compromised. It is recommended to limit the number of Organizational Admins to the minimum needed (recommended maximum 3 owners). # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the organization People page, Select the unwanted owners, Using the "X members selected" - change role to member] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the organization People page +# - 3. Select the unwanted owners +# - 4. Using the 'X members selected' - change role to member # severity: MEDIUM # requiredScopes: [admin:org] # threat: -# - "1. An organization has a permissive attitude and provides an owner role to all developers." -# - "2. One of the developers has decided to collaborate with an evil ransomware gang, and uses his high privileges to add a malicious external collaborator" -# - "3. The malicious collaborator, being an owner, has a wide range of destructive operations he can do (e.g. remove security settings)" +# - 1. An organization has a permissive attitude and provides an owner role to all developers +# - 2. One of the developers has decided to collaborate with an evil ransomware gang, and uses his high privileges to add a malicious external collaborator +# - 3. The malicious collaborator, being an owner, has a wide range of destructive operations he can do (e.g. remove security settings) default organization_has_too_many_admins := true organization_has_too_many_admins := false { @@ -26,12 +30,16 @@ organization_has_too_many_admins := false { # description: A member did not perform any action in the last 6 months. Stale members can pose a potential risk if they are compromised. Consider removing the user's access completely. # custom: # requiredEnrichers: [entityId, violatedUsers] -# remediationSteps: [Make sure you have admin permissions, Go to the org's People page, Select all stale members, Using the "X members selected" - remove members from organization] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the org's People page +# - 3. Select all stale members +# - 4. Using the 'X members selected' - remove members from organization # severity: LOW # requiredScopes: [admin:org] # prerequisites: [premium] # threat: -# - "Stale members are most likely not managed and monitored, increasing the possibility of being compromised." +# - Stale members are most likely not managed and monitored, increasing the possibility of being compromised. stale_member_found[mem] := true { some member mem := input.members[member] @@ -42,17 +50,20 @@ stale_member_found[mem] := true { # METADATA # scope: rule -# custom: # title: Organization Admins Should Have Activity In The Last 6 Months # description: A member with organizational admin permissions did not perform any action in the last 6 months. Admin users are extremely powerful and common compliance standards demand keeping the number of admins to a minimum. Consider revoking this member’s admin credentials by downgrading to regular user or removing the user completely. # custom: # requiredEnrichers: [entityId, violatedUsers] -# remediationSteps: [Make sure you have admin permissions, Go to the org's People page, Select all stale admins, Using the "X members selected" - remove members from organization] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the org's People page +# - 3. Select all stale admins +# - 4. Using the 'X members selected' - remove members from organization # severity: MEDIUM # requiredScopes: [admin:org] # prerequisites: [premium] # threat: -# - "Stale admins are most likely not managed and monitored, increasing the possibility of being compromised." +# - Stale admins are most likely not managed and monitored, increasing the possibility of being compromised. stale_admin_found[mem] := true { some member mem := input.members[member] diff --git a/policies/github/organization.rego b/policies/github/organization.rego index 968862fe..0dd09a90 100644 --- a/policies/github/organization.rego +++ b/policies/github/organization.rego @@ -10,11 +10,17 @@ import data.common.secrets as secretUtils # custom: # requiredEnrichers: [hooksList] # severity: LOW -# remediationSteps: [Make sure you have admin permissions, Go to the organization settings page, Select "Webhooks", Press on the insecure webhook, Configure a secret , Click "Update webhook"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the organization settings page +# - 3. Select 'Webhooks' +# - 4. Press on the insecure webhook +# - 5. Configure a secret +# - 6. Click 'Update webhook' # requiredScopes: [admin:org_hook] # threat: -# - "Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request." -# - "This allows attackers to masquerade as your organization, potentially creating an unstable or insecure state in other systems." +# - Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request. +# - This allows attackers to masquerade as your organization, potentially creating an unstable or insecure state in other systems. organization_webhook_no_secret[violated] := true { some index hook := input.hooks[index] @@ -32,11 +38,18 @@ organization_webhook_no_secret[violated] := true { # custom: # requiredEnrichers: [hooksList] # severity: LOW -# remediationSteps: [Make sure you have admin permissions, Go to the organization settings page, Select "Webhooks", Press on the insecure webhook, Verify url starts with https, Enable "SSL verification" , Click "Update webhook"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the organization settings page +# - 3. Select 'Webhooks' +# - 4. Press on the insecure webhook +# - 5. Verify URL starts with https +# - 6. Enable 'SSL verification' +# - 7. Click 'Update webhook' # requiredScopes: [admin:org_hook] # threat: -# - "If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request." -# - "In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain." +# - If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request. +# - In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain. organization_webhook_doesnt_require_ssl[violated] := true { some index hook := input.hooks[index] @@ -53,7 +66,13 @@ organization_webhook_doesnt_require_ssl[violated] := true { # description: The two-factor authentication requirement is not enabled at the organization level. Regardless of whether users are managed externally by SSO, it is highly recommended to enable this option to reduce the risk of a deliberate or accidental user creation without MFA. # custom: # severity: HIGH -# remediationSteps: [Make sure you have admin permissions, Go to the organization settings page, Enter "Authentication security" tab, Under "Two-factor authentication", Toggle on "Require two-factor authentication for everyone in the organization", Click "Save"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the organization settings page +# - 3. Enter 'Authentication security' tab +# - 4. Under 'Two-factor authentication' +# - 5. Toggle on 'Require two-factor authentication for everyone in the organization' +# - 6. Click 'Save' # requiredScopes: [admin:org] # threat: # - If an attacker gets the valid credentials for one of the organization’s users they can authenticate to your GitHub organization. @@ -67,13 +86,19 @@ two_factor_authentication_not_required_for_org := false { # scope: rule # title: Only Admins Should Be Able To Create Public Repositories # description: >- -# The organization should be configured to prevent non-admin members creating public repositories. Creating a public repository may expose sensitive organization code, which, once exposed, may be copied, cached or stored by external parties. Therefore, it is highly recommended to restrict the option to create public repositories to admins only and reduce the risk of unintentional code exposure. NOTE: You should also verify that repositories owners can't change existing repositories visibility to be public. If allowed, a malicious user could create a private repo and change it to public. See: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization for further information +# The organization should be configured to prevent non-admin members from creating public repositories. Creating a public repository may expose sensitive organization code, which, once exposed, may be copied, cached, or stored by external parties. Therefore, it is highly recommended to restrict the option to create public repositories to admins only and reduce the risk of unintentional code exposure. NOTE: You should also verify that repository owners can't change existing repository visibility to be public. If allowed, a malicious user could create a private repo and change it to public. See: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization for further information # custom: # severity: MEDIUM -# remediationSteps: [Make sure you have admin permissions, Go to the organization settings page, Enter "Member privileges" tab, Under "Repository creation", Toggle off "Public", Click "Save"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the organization settings page +# - 3. Enter 'Member privileges' tab +# - 4. Under 'Repository creation' +# - 5. Toggle off 'Public' +# - 6. Click 'Save' # requiredScopes: [read:org] # threat: -# - "A member of the organization could inadvertently or maliciously make public an internal repository exposing confidential data." +# - A member of the organization could inadvertently or maliciously make public an internal repository exposing confidential data. default non_admins_can_create_public_repositories := true non_admins_can_create_public_repositories := false { @@ -86,10 +111,16 @@ non_admins_can_create_public_repositories := false { # description: Default repository permissions configuration is not set in the organization, thus every new repository will be accessible by default to all users. It is strongly recommended to remove the default permissions and assign them on demand. # custom: # severity: HIGH -# remediationSteps: [Make sure you have admin permissions, Go to the organization settings page, Enter "Member privileges" tab, Under "Base permissions", Set permissions to "No permissions", Click "Save"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the organization settings page +# - 3. Enter 'Member privileges' tab +# - 4. Under 'Base permissions' +# - 5. Set permissions to 'No permissions' +# - 6. Click 'Save' # requiredScopes: [read:enterprise] # threat: -# - "Organization members can see the content of freshly created repositories, even if they should be restricted." +# - Organization members can see the content of freshly created repositories, even if they should be restricted. default default_repository_permission_is_not_none := true default_repository_permission_is_not_none := false { @@ -98,14 +129,20 @@ default_repository_permission_is_not_none := false { # METADATA # scope: rule -# custom: -# severity: MEDIUM # title: Organization Should Use Single-Sign-On # description: It is recommended to enable access to an organization via SAML single sign-on (SSO) by authenticating through an identity provider (IdP). This allows for central account control and for timely access revocations. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the organization settings page, Enter "Authentication security" tab, Toggle on "Enable SAML authentication", Fill in the remaining SSO configuration as instructed on the screen, Click "Save"] +# severity: MEDIUM +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the organization settings page +# - 3. Enter 'Authentication security' tab +# - 4. Toggle on 'Enable SAML authentication' +# - 5. Fill in the remaining SSO configuration as instructed on the screen +# - 6. Click 'Save' # requiredScopes: [admin:org] -# threat: Not using an SSO solution makes it more difficult to track a potentially compromised user's actions accross different systems, prevents the organization from defining a common password policy, and makes it challenging to audit different aspects of the user's behavior. +# threat: +# - Not using an SSO solution makes it more difficult to track a potentially compromised user's actions across different systems, prevents the organization from defining a common password policy, and makes it challenging to audit different aspects of the user's behavior. default organization_not_using_single_sign_on := true organization_not_using_single_sign_on := false { @@ -114,7 +151,7 @@ organization_not_using_single_sign_on := false { # METADATA # scope: rule -# title: Organization Has Stale Secrets +# title: Organization Secrets Should Be Updated At Least Yearly # description: Some of the organizations secrets have not been updated for over a year. It is recommended to refresh secret values regularly in order to minimize the risk of breach in case of an information leak. # custom: # requiredEnrichers: [secretsList] diff --git a/policies/github/repository.rego b/policies/github/repository.rego index f1e914de..804e0bd0 100644 --- a/policies/github/repository.rego +++ b/policies/github/repository.rego @@ -1,14 +1,18 @@ package repository import data.common.webhooks as webhookUtils +import data.common.secrets as secretUtils + # METADATA # scope: rule # title: Repository Should Be Updated At Least Quarterly # description: A project which is not actively maintained may not be patched against security issues within its code and dependencies, and is therefore at higher risk of including known vulnerabilities. # custom: -# remediationSteps: [Make sure you have admin permissions, Either Delete or Archive the repository] # severity: HIGH +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Either Delete or Archive the repository # requiredScopes: [repo] # threat: As new vulnerabilities are found over time, unmaintained repositories are more likely to point to dependencies that have known vulnerabilities, exposing these repositories to 1-day attacks. default repository_not_maintained := true @@ -28,14 +32,19 @@ repository_not_maintained := false { # METADATA # scope: rule # title: Repository Should Have Fewer Than Three Admins -# description: Repository admins are highly privileged and could create great damage if they are compromised. It is recommeneded to limit the number of Repository Admins to the minimum required (recommended maximum 3 admins). +# description: Repository admins are highly privileged and could create great damage if they are compromised. It is recommended to limit the number of Repository Admins to the minimum required (recommended maximum 3 admins). # custom: # severity: LOW -# remediationSteps: [Make sure you have admin permissions, Go to the repository settings page, Press "Collaborators and teams", Select the unwanted admin users, Select "Change Role"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repository settings page +# - 3. Press 'Collaborators and teams' +# - 4. Select the unwanted admin users +# - 5. Select 'Change Role' # requiredScopes: [read:org,repo] # threat: -# - "A compromised user with admin permissions can initiate a supply chain attack in a plethora of ways." -# - "Having many admin users increases the overall risk of user compromise, and makes it more likely to lose track of unused admin permissions given to users in the past." +# - A compromised user with admin permissions can initiate a supply chain attack in a plethora of ways. +# - Having many admin users increases the overall risk of user compromise, and makes it more likely to lose track of unused admin permissions given to users in the past. default repository_has_too_many_admins := true repository_has_too_many_admins := false { @@ -50,11 +59,17 @@ repository_has_too_many_admins := false { # custom: # requiredEnrichers: [hooksList] # severity: LOW -# remediationSteps: [Make sure you can manage webhooks for the repository, Go to the repository settings page, Select "Webhooks", Press on the insecure webhook, Confiure a secret, Click "Update webhook"] +# remediationSteps: +# - 1. Make sure you can manage webhooks for the repository +# - 2. Go to the repository settings page +# - 3. Select 'Webhooks' +# - 4. Press on the insecure webhook +# - 5. Configure a secret +# - 6. Click 'Update webhook' # requiredScopes: [read:repo_hook, repo] # threat: -# - "Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request." -# - "This allows attackers to masquerade as your repository, potentially creating an unstable or insecure state in other systems." +# - 'Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request.' +# - 'This allows attackers to masquerade as your repository, potentially creating an unstable or insecure state in other systems.' repository_webhook_no_secret[violated] := true { some index hook := input.hooks[index] @@ -68,15 +83,22 @@ repository_webhook_no_secret[violated] := true { # METADATA # scope: rule # title: Webhooks Should Be Configured To Use SSL -# description: Webhooks that are not configured with SSL enabled could expose your sofware to man in the middle attacks (MITM). +# description: Webhooks that are not configured with SSL enabled could expose your software to man-in-the-middle attacks (MITM). # custom: # requiredEnrichers: [hooksList] # severity: LOW -# remediationSteps: [Make sure you can manage webhooks for the repository, Go to the repository settings page, Select "Webhooks", Verify url starts with https, Press on the insecure webhook, Enable "SSL verfication", Click "Update webhook"] +# remediationSteps: +# - 1. Make sure you can manage webhooks for the repository +# - 2. Go to the repository settings page +# - 3. Select 'Webhooks' +# - 4. Verify URL starts with https +# - 5. Press on the insecure webhook +# - 6. Enable 'SSL verification' +# - 7. Click 'Update webhook' # requiredScopes: [read:repo_hook, repo] # threat: -# - "If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request." -# - "In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain." +# - 'If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it to freely read and affect the response of any webhook request.' +# - 'In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain.' repository_webhook_doesnt_require_ssl[violated] := true { some index hook := input.hooks[index] @@ -92,7 +114,11 @@ repository_webhook_doesnt_require_ssl[violated] := true { # title: Forking Should Not Be Allowed for This Repository # description: Forking a repository can lead to loss of control and potential exposure of the source code. If you do not need forking, it is recommended to turn it off in the repository configuration. If needed, forking should be turned on by admins deliberately when opting to create a fork. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "General" tab, Under "Features", Toggle off "Allow forking"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'General' tab +# - 4. Under 'Features', Toggle off 'Allow forking' # severity: LOW # requiredScopes: [read:org] # threat: Forked repositories cause more code and secret sprawl in the organization as forks are independent copies of the repository and need to be tracked separately, making it more difficult to keep track of sensitive assets and contain potential incidents. @@ -108,7 +134,15 @@ forking_allowed_for_repository := false { # title: Default Branch Should Be Protected # description: Branch protection is not enabled for this repository’s default branch. Protecting branches ensures new code changes must go through a controlled merge process and allows enforcement of code review as well as other security tests. This issue is raised if the default branch protection is turned off. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Add rule", Set "Branch name pattern" as the default branch name (usually "main" or "master"), Set desired protections, Click "Create" and save the rule] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Add rule' +# - 6. Set 'Branch name pattern' as the default branch name (usually 'main' or 'master') +# - 7. Set desired protections +# - 8. Click 'Create' and save the rule # severity: MEDIUM # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -131,13 +165,13 @@ missing_default_branch_protection := false { # description: The history of the default branch is not protected against deletion for this repository. # custom: # remediationSteps: -# - Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page -# - Make sure you have admin permissions -# - Go to the repo's settings page -# - Enter "Branches" tab -# - Under "Branch protection rules" -# - Click "Edit" on the default branch rule -# - Uncheck "Allow deletions", Click "Save changes" +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Uncheck 'Allow deletions', Click 'Save changes' # severity: MEDIUM # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -159,7 +193,15 @@ missing_default_branch_protection_deletion := false { # title: Default Branch Should Not Allow Force Pushes # description: The history of the default branch is not protected against changes for this repository. Protecting branch history ensures every change that was made to code can be retained and later examined. This issue is raised if the default branch history can be modified using force push. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Uncheck "Allow force pushes", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Uncheck 'Allow force pushes' +# - 7. Click 'Save changes' # severity: MEDIUM # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -179,9 +221,18 @@ missing_default_branch_protection_force_push := false { # METADATA # scope: rule # title: Default Branch Should Require All Checks To Pass Before Merge -# description: Branch protection is enabled. However, the checks which validate the quality and security of the code are not required to pass before submitting new changes. The default check ensures code is up-to-date in order to prevent faulty merges and unexpected behaviors, as well as other custom checks that test security and quality. It is advised to turn this control on to ensure any existing or future check will be required to pass. +# description: Branch protection is enabled. However, the checks that validate the quality and security of the code are not required to pass before submitting new changes. The default check ensures the code is up-to-date to prevent faulty merges and unexpected behaviors, as well as other custom checks that test security and quality. It is advised to turn this control on to ensure any existing or future check will be required to pass. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require status checks to pass before merging", "Add the required checks that must pass before merging (tests, lint, etc...)", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require status checks to pass before merging' +# - 7. Add the required checks that must pass before merging (tests, lint, etc...) +# - 8. Click 'Save changes' # severity: MEDIUM # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -204,7 +255,16 @@ requires_status_checks := false { # title: Default Branch Should Require Branches To Be Up To Date Before Merge # description: Status checks are required, but branches that are not up to date can be merged. This can result in previously remediated issues being merged in over fixes. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require status checks to pass before merging", Check "Require branches to be up to date before merging", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require status checks to pass before merging' +# - 7. Check 'Require branches to be up to date before merging' +# - 8. Click 'Save changes' # severity: MEDIUM # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -229,7 +289,16 @@ requires_branches_up_to_date_before_merge := false { # title: Default Branch Should Require New Code Changes After Approval To Be Re-Approved # description: This security control prevents merging code that was approved but later on changed. Turning it on ensures any new changes must be reviewed again. This setting is part of the branch protection and code-review settings, and hardens the review process. If turned off - a developer can change the code after approval, and push code that is different from the one that was previously allowed. This option is found in the branch protection setting for the repository. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require a pull request before merging", Check "Dismiss stale pull request approvals when new commits are pushed", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require a pull request before merging' +# - 7. Check 'Dismiss stale pull request approvals when new commits are pushed' +# - 8. Click 'Save changes' # severity: LOW # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -252,7 +321,17 @@ dismisses_stale_reviews := false { # title: Default Branch Should Require Code Review # description: In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management system's built-in enforcement. This option is found in the branch protection setting of the repository. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require a pull request before merging", Check "Require approvals", Set "Required number of approvals before merging" to 1 or more, Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require a pull request before merging' +# - 7. Check 'Require approvals' +# - 8. Set 'Required number of approvals before merging' to 1 or more +# - 9. Click 'Save changes' # severity: HIGH # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -276,13 +355,23 @@ code_review_not_required := false { # title: Default Branch Should Require Code Review By At Least Two Reviewers # description: In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management built-in enforcement. This option is found in the branch protection setting of the repository. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require a pull request before merging", Check "Require approvals", Set "Required number of approvals before merging" to 1 or more, Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require a pull request before merging' +# - 7. Check 'Require approvals' +# - 8. Set 'Required number of approvals before merging' to 2 or more +# - 9. Click 'Save changes' # severity: MEDIUM # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] # threat: -# - "Users can merge code without being reviewed, which can lead to insecure code reaching the main branch and production." -# - "Requiring code review by at least two reviewers further decreases the risk of an insider threat (as merging code requires compromising at least 2 identities with write permissions), and decreases the likelihood of human error in the review process." +# - Users can merge code without being reviewed, which can lead to insecure code reaching the main branch and production. +# - Requiring code review by at least two reviewers further decreases the risk of an insider threat (as merging code requires compromising at least 2 identities with write permissions), and decreases the likelihood of human error in the review process. default code_review_by_two_members_not_required := true code_review_by_two_members_not_required := false { @@ -301,7 +390,16 @@ code_review_by_two_members_not_required := false { # title: Default Branch Should Limit Code Review to Code-Owners # description: It is recommended to require code review only from designated individuals specified in CODEOWNERS file. Turning this option on enforces that only the allowed owners can approve a code change. This option is found in the branch protection setting of the repository. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require a pull request before merging", Check "Require review from Code Owners", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require a pull request before merging' +# - 7. Check 'Require review from Code Owners' +# - 8. Click 'Save changes' # severity: LOW # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -324,7 +422,15 @@ code_review_not_limited_to_code_owners := false { # title: Default Branch Should Require Linear History # description: Prevent merge commits from being pushed to protected branches. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require linear history", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require linear history' +# - 7. Click 'Save changes' # severity: MEDIUM # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -344,9 +450,17 @@ non_linear_history := false { # METADATA # scope: rule # title: Default Branch Should Require All Conversations To Be Resolved Before Merge -# description: Require all Pull Request conversations to be resolved before merging. Check this to avoid bypassing/missing a Pull Reuqest comment. +# description: Require all Pull Request conversations to be resolved before merging. Check this to avoid bypassing/missing a Pull Request comment. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require conversation resolution before merging", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require conversation resolution before merging' +# - 7. Click 'Save changes' # severity: LOW # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -369,7 +483,15 @@ no_conversation_resolution := false { # title: Default Branch Should Require All Commits To Be Signed # description: Require all commits to be signed and verified # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Require signed commits", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Require signed commits' +# - 7. Click 'Save changes' # severity: LOW # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -391,7 +513,15 @@ no_signed_commits := false { # title: Default Branch Should Restrict Who Can Dismiss Reviews # description: Any user with write access to the repository can dismiss pull-request reviews. Pull-request review contains essential information on the work that needs to be done and helps keep track of the changes. Dismissing it might cause a loss of this information and should be restricted to a limited number of users. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Restrict who can dismiss pull request reviews", Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Restrict who can dismiss pull request reviews' +# - 7. Click 'Save changes' # severity: LOW # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -407,7 +537,16 @@ review_dismissal_allowed := false { # title: Default Branch Should Restrict Who Can Push To It # description: By default, commits can be pushed directly to protected branches without going through a Pull Request. Restrict who can push commits to protected branches so that commits can be added only via merges, which require Pull Request. # custom: -# remediationSteps: ["Note: The remediation steps applys to legacy branch protections, rules set based protection should be updated from the rules set page", Make sure you have admin permissions, Go to the repo's settings page, Enter "Branches" tab, Under "Branch protection rules", Click "Edit" on the default branch rule, Check "Restrict who can push to matching branches", Choose who should be allowed to push, Click "Save changes"] +# remediationSteps: +# - "Note: The remediation steps apply to legacy branch protections, rules set-based protection should be updated from the rules set page" +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Branches' tab +# - 4. Under 'Branch protection rules' +# - 5. Click 'Edit' on the default branch rule +# - 6. Check 'Restrict who can push to matching branches' +# - 7. Choose who should be allowed to push +# - 8. Click 'Save changes' # severity: LOW # requiredScopes: [repo] # prerequisites: [has_branch_protection_permission] @@ -427,7 +566,11 @@ pushes_are_not_restricted := false { # title: Vulnerability Alerts Should Be Enabled # description: Enable GitHub Dependabot to regularly scan for open source vulnerabilities. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Code security and analysis" tab, Set "Dependabot alerts" as Enabled] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Code security and analysis' tab +# - 4. Set 'Dependabot alerts' as Enabled # severity: MEDIUM # requiredScopes: [repo] # threat: An open source vulnerability may be affecting your code without your knowledge, making it vulnerable to exploitation. @@ -443,7 +586,11 @@ vulnerability_alerts_not_enabled := false { # title: GitHub Advanced Security – Dependency Review Should Be Enabled For A Repository # description: Enable GitHub Advanced Security dependency review to avoid introducing new vulnerabilities and detect newly discovered vulnerabilities in existing packages. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Code security and analysis" tab, Set "Dependency graph" as Enabled] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Code security and analysis' tab +# - 4. Set 'Dependency graph' as Enabled # severity: MEDIUM # requiredScopes: [repo] # threat: A contributor may add vulnerable third-party dependencies to the repository, introducing vulnerabilities to your application that will only be detected after merge. @@ -456,10 +603,14 @@ ghas_dependency_review_not_enabled := false { # METADATA # scope: rule # title: OSSF Scorecard Score Should Be Above 7 -# description: Scorecard is an open-source tool from the OSSF that helps to asses the security posture of repositories. A low scorecard score means your repository may be at risk. +# description: Scorecard is an open-source tool from the OSSF that helps to assess the security posture of repositories. A low scorecard score means your repository may be at risk. # custom: # requiredEnrichers: [scorecard] -# remediationSteps: [Get scorecard output by either:, "- Run legitify with --scorecard verbose", "- Run scorecard manually", Fix the failed checks] +# remediationSteps: +# - 1. Get scorecard output by either: +# - 2. - Run legitify with --scorecard verbose +# - 3. - Run scorecard manually +# - 4. Fix the failed checks # severity: MEDIUM # requiredScopes: [repo, read:repo_hook] # prerequisites: [scorecard_enabled] @@ -477,12 +628,12 @@ scorecard_score_too_low := false { # custom: # requiredEnrichers: [organizationId] # remediationSteps: -# - Make sure you have admin permissions -# - Go to the org's settings page -# - Enter "Actions - General" tab -# - Under 'Workflow permissions' -# - Select 'Read repository contents permission' -# - Click 'Save' +# - 1. Make sure you have admin permissions +# - 2. Go to the org's settings page +# - 3. Enter 'Actions - General' tab +# - 4. Under 'Workflow permissions' +# - 5. Select 'Read repository contents permission' +# - 6. Click 'Save' # severity: MEDIUM # requiredScopes: [admin:org] # threat: In case of token compromise (due to a vulnerability or malicious third-party GitHub actions), an attacker can use this token to sabotage various assets in your CI/CD pipeline, such as packages, pull-requests, deployments, and more. @@ -499,12 +650,12 @@ token_default_permissions_is_read_write := false { # custom: # requiredEnrichers: [organizationId] # remediationSteps: -# - Make sure you have admin permissions -# - Go to the org's settings page -# - Enter "Actions - General" tab -# - Under 'Workflow permissions' -# - Uncheck 'Allow GitHub actions to create and approve pull requests. -# - Click 'Save' +# - 1. Make sure you have admin permissions +# - 2. Go to the org's settings page +# - 3. Enter 'Actions - General' tab +# - 4. Under 'Workflow permissions' +# - 5. Uncheck 'Allow GitHub actions to create and approve pull requests.' +# - 6. Click 'Save' # severity: HIGH # requiredScopes: [admin:org] # threat: Attackers can exploit this misconfiguration to bypass code-review restrictions by creating a workflow that approves their own pull request and then merging the pull request without anyone noticing, introducing malicious code that would go straight ahead to production. @@ -520,11 +671,11 @@ actions_can_approve_pull_requests := false{ # description: Rulesets rules are not enforced for some users. When defining rulesets it is recommended to make sure that no one is allowed to bypass these rules in order to avoid inadvertent or intentional alterations to critical code which can lead to potential errors or vulnerabilities in the software. # custom: # remediationSteps: -# - Go to the repository settings page -# - Under "Code and automation", select "Rules -> Rulesets" -# - Find the relevant ruleset -# - Empty the "Bypass list" -# - Press "Save Changes" +# - 1. Go to the repository settings page +# - 2. Under 'Code and automation', select 'Rules -> Rulesets' +# - 3. Find the relevant ruleset +# - 4. Empty the 'Bypass list' +# - 5. Press 'Save Changes' # severity: MEDIUM # requiredScopes: [repo] # threat: Attackers that gain access to a user that can bypass the ruleset rules can compromise the codebase without anyone noticing, introducing malicious code that would go straight ahead to production. @@ -539,3 +690,30 @@ users_allowed_to_bypass_ruleset := false { rule := input.rules_set[index] count(rule.ruleset.bypass_actors) == 0 } + +# METADATA +# scope: rule +# title: Repository Secrets Should Be Updated At Least Yearly +# description: Some of the repository secrets have not been updated for over a year. It is recommended to refresh secret values regularly in order to minimize the risk of breach in case of an information leak. +# custom: +# requiredEnrichers: [secretsList] +# remediationSteps: +# - 1. Enter your repository's landing page +# - 2. Go to the settings tab +# - 3. Under the 'Security' title on the left, choose 'Secrets and variables' +# - 4. Click 'Actions' +# - 5. Sort secrets by 'Last Updated' +# - 6. Regenerate every secret older than one year and add the new value to GitHub's secret manager +# severity: MEDIUM +# requiredScopes: [repo] +# threat: Sensitive data may have been inadvertently made public in the past, and an attacker who holds this data may gain access to your current CI and services. In addition, there may be old or unnecessary tokens that have not been inspected and can be used to access sensitive information. +repository_secret_is_stale[stale] := true{ + some index + secret := input.repository_secrets[index] + secretUtils.is_stale(secret.updated_at) + stale := { + "name" : secret.name, + "update date" : time.format(secret.updated_at), + } + +} \ No newline at end of file diff --git a/policies/github/repository_two.rego b/policies/github/repository_two.rego deleted file mode 100644 index 1d04bc99..00000000 --- a/policies/github/repository_two.rego +++ /dev/null @@ -1,30 +0,0 @@ -package repository - -import data.common.secrets as secretUtils - -# METADATA -# scope: rule -# title: Repository Has Stale Secrets -# description: Some of the repository secrets have not been updated for over a year. It is recommended to refresh secret values regularly in order to minimize the risk of breach in case of an information leak. -# custom: -# requiredEnrichers: [secretsList] -# remediationSteps: -# - Enter your repository's landing page -# - Go to the settings tab -# - Under the 'Security' title on the left, choose 'Secrets and variables' -# - Click 'Actions' -# - Sort secrets by 'Last Updated' -# - Regenerate every secret older than one year and add the new value to GitHub's secret manager -# severity: MEDIUM -# requiredScopes: [repo] -# threat: Sensitive data may have been inadvertently made public in the past, and an attacker who holds this data may gain access to your current CI and services. In addition, there may be old or unnecessary tokens that have not been inspected and can be used to access sensitive information. -repository_secret_is_stale[stale] := true{ - some index - secret := input.repository_secrets[index] - secretUtils.is_stale(secret.updated_at) - stale := { - "name" : secret.name, - "update date" : time.format(secret.updated_at), - } - -} diff --git a/policies/github/runner_group.rego b/policies/github/runner_group.rego index ee177280..4f34b16d 100644 --- a/policies/github/runner_group.rego +++ b/policies/github/runner_group.rego @@ -16,15 +16,15 @@ package runner_group # requiredEnrichers: [organizationId] # requiredScopes: [admin:org] # remediationSteps: -# - "Go to the organization settings page" -# - "Press Actions ➝ Runner groups" -# - "Select the violating repository" -# - "Uncheck Allow public repositories" +# - 1. Go to the organization settings page +# - 2. Press Actions ➝ Runner groups +# - 3. Select the violating repository +# - 4. Uncheck Allow public repositories # threat: -# - "Hosted runners are usually part of the organization's private network and can be easily misconfigured." -# - "If the hosted runner is insecurely configured, any GitHub user could:" -# - "1. Create a workflow that runs on the public hosted runner" -# - "2. Exploit the misconfigurations to execute code inside the private network" +# - Hosted runners are usually part of the organization's private network and can be easily misconfigured. +# - If the hosted runner is insecurely configured, any GitHub user could: +# - 1. Create a workflow that runs on the public hosted runner +# - 2. Exploit the misconfigurations to execute code inside the private network default runner_group_can_be_used_by_public_repositories := true runner_group_can_be_used_by_public_repositories := false { @@ -43,15 +43,15 @@ runner_group_can_be_used_by_public_repositories := false { # requiredEnrichers: [organizationId] # requiredScopes: [admin:org] # remediationSteps: -# - "Go to the organization settings page" -# - "Go to Actions ➝ Runner groups" -# - "Under the 'Repository Access' section, select 'Selected repositories'" -# - "Select the required repositories" +# - 1. Go to the organization settings page +# - 2. Go to Actions ➝ Runner groups +# - 3. Under the 'Repository Access' section, select 'Selected repositories' +# - 4. Select the required repositories # threat: -# - "Hosted runners are usually part of the organization's private network and can be easily misconfigured." -# - "If the hosted runner is insecurely configured, any user in the organization could:" -# - "1. Create a workflow that runs on the hosted runner" -# - "2. Exploit the runner misconfigurations/known CVE's to execute code inside the private network" +# - Hosted runners are usually part of the organization's private network and can be easily misconfigured. +# - If the hosted runner is insecurely configured, any user in the organization could: +# - 1. Create a workflow that runs on the hosted runner +# - 2. Exploit the runner misconfigurations/known CVE's to execute code inside the private network default runner_group_not_limited_to_selected_repositories := true runner_group_not_limited_to_selected_repositories := false { diff --git a/policies/gitlab/enterprise.rego b/policies/gitlab/enterprise.rego index 6c7f8831..b278e838 100644 --- a/policies/gitlab/enterprise.rego +++ b/policies/gitlab/enterprise.rego @@ -10,11 +10,11 @@ package enterprise # custom: # severity: HIGH # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> General -# - Expand "Sign-in restrictions" section -# - Toggle "Two-factor authentication" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> General +# - 3. Expand 'Sign-in restrictions' section +# - 4. Toggle 'Two-factor authentication' +# - 5. Press 'Save Changes' default require_two_factor_authentication_not_globally_enforced := true require_two_factor_authentication_not_globally_enforced := false { @@ -30,11 +30,11 @@ require_two_factor_authentication_not_globally_enforced := false { # custom: # severity: LOW # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> General -# - Expand "Sign-in restrictions" section -# - Un toggle "Allow password authentication for Git over HTTP(S)" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> General +# - 3. Expand 'Sign-in restrictions' section +# - 4. Un toggle 'Allow password authentication for Git over HTTP(S)' +# - 5. Press 'Save Changes' default password_authentication_enabled_for_git_is_enabled := true password_authentication_enabled_for_git_is_enabled := false { @@ -50,11 +50,11 @@ password_authentication_enabled_for_git_is_enabled := false { # custom: # severity: LOW # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> Network -# - Expand "User and IP rate limit" section -# - Toggle "Enable authenticated API request rate limit -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> Network +# - 3. Expand 'User and IP rate limit' section +# - 4. Toggle 'Enable authenticated API request rate limit' +# - 5. Press 'Save Changes' default throttle_authenticated_api_not_enabled := true throttle_authenticated_api_not_enabled := false { @@ -70,11 +70,11 @@ throttle_authenticated_api_not_enabled := false { # custom: # severity: MEDIUM # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> Repository -# - Expand "Default Branch" section -# - Toggle "Fully protected" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> Repository +# - 3. Expand 'Default Branch' section +# - 4. Toggle 'Fully protected' +# - 5. Press 'Save Changes' default default_branch_protection_not_globally_enforced := true default_branch_protection_not_globally_enforced := false { @@ -91,11 +91,11 @@ default_branch_protection_not_globally_enforced := false { # custom: # severity: HIGH # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> General -# - Expand "Visibility and access controls" section -# - Under "Restricted visibility levels" toggle "Public" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> General +# - 3. Expand 'Visibility and access controls' section +# - 4. Under 'Restricted visibility levels' toggle 'Public' +# - 5. Press 'Save Changes' default all_users_are_allowed_to_create_public_projects := true all_users_are_allowed_to_create_public_projects := false { @@ -112,11 +112,11 @@ all_users_are_allowed_to_create_public_projects := false { # custom: # severity: HIGH # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> General -# - Expand "Visibility and access controls" section -# - Under "Default group visibility" toggle "Private" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> General +# - 3. Expand 'Visibility and access controls' section +# - 4. Under 'Default group visibility' toggle 'Private' +# - 5. Press 'Save Changes' default default_group_visibility_is_public := true default_group_visibility_is_public := false { @@ -132,11 +132,11 @@ default_group_visibility_is_public := false { # custom: # severity: HIGH # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> General -# - Expand "Visibility and access controls" section -# - Under "Default project visibility" toggle "Private" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> General +# - 3. Expand 'Visibility and access controls' section +# - 4. Under 'Default project visibility' toggle 'Private' +# - 5. Press 'Save Changes' default default_project_visibility_is_public := true default_project_visibility_is_public := false { @@ -152,11 +152,11 @@ default_project_visibility_is_public := false { # custom: # severity: MEDIUM # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> General -# - Expand "Sign-up restrictions" section -# - Toggle "Send confirmation email on sign-up" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> General +# - 3. Expand 'Sign-up restrictions' section +# - 4. Toggle 'Send confirmation email on sign-up' +# - 5. Press 'Save Changes' default send_user_confirmation_email_not_enabled := true send_user_confirmation_email_not_enabled := false { @@ -172,11 +172,11 @@ send_user_confirmation_email_not_enabled := false { # custom: # severity: MEDIUM # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> Network -# - Expand "User and IP rate limit" section -# - Toggle "Enable unauthenticated API request rate limit" and "Enable unauthenticated web request rate limit" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> Network +# - 3. Expand 'User and IP rate limit' section +# - 4. Toggle 'Enable unauthenticated API request rate limit' and 'Enable unauthenticated web request rate limit' +# - 5. Press 'Save Changes' default throttle_unauthenticated_request_not_enabled := true throttle_unauthenticated_request_not_enabled := false { @@ -194,11 +194,11 @@ throttle_unauthenticated_request_not_enabled := false { # custom: # severity: LOW # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> Network -# - Expand "Outbound requests" section -# - Un toggle "Allow requests to the local network from web hooks and services" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> Network +# - 3. Expand 'Outbound requests' section +# - 4. Un toggle 'Allow requests to the local network from web hooks and services' +# - 5. Press 'Save Changes' default webhooks_are_allowed_to_be_sent_to_local_network := true webhooks_are_allowed_to_be_sent_to_local_network := false { @@ -212,11 +212,11 @@ webhooks_are_allowed_to_be_sent_to_local_network := false { # custom: # severity: HIGH # remediationSteps: -# - Go to the admin page: Menu -> Admin -# - Press Settings -> General -# - Expand "Sign-up restrictions" section -# - Un toggle "Sign-up enabled" -# - Press "Save Changes" +# - 1. Go to the admin page: Menu -> Admin +# - 2. Press Settings -> General +# - 3. Expand 'Sign-up restrictions' section +# - 4. Un toggle 'Sign-up enabled' +# - 5. Press 'Save Changes' default unauthenticated_signup_enabled := true unauthenticated_signup_enabled := false { diff --git a/policies/gitlab/member.rego b/policies/gitlab/member.rego index 728728f1..3c90e59a 100644 --- a/policies/gitlab/member.rego +++ b/policies/gitlab/member.rego @@ -8,11 +8,12 @@ package member # severity: HIGH # prerequisites: [enterprise] # remediationSteps: -# - Login with the user credentials -# - Go to the user settings page -# - Select "Account" on the left navigation bar -# - Press "Enable two-factor authentication" -# threat: Collaborators without two-factor authentication are prime targets for phising and social engineering attacks, as compromise only requires acquiring the collaborator's password. +# - 1. Login with the user credentials +# - 2. Go to the user settings page +# - 3. Select 'Account' on the left navigation bar +# - 4. Press 'Enable two-factor authentication' +# threat: +# - Collaborators without two-factor authentication are prime targets for phishing and social engineering attacks, as compromise only requires acquiring the collaborator's password. default two_factor_authentication_is_disabled_for_a_collaborator := true two_factor_authentication_is_disabled_for_a_collaborator := false { @@ -27,13 +28,13 @@ two_factor_authentication_is_disabled_for_a_collaborator := false { # severity: HIGH # prerequisites: [enterprise] # remediationSteps: -# - Login with the user credentials -# - Go to the user settings page -# - Select "Account" on the left navigation bar -# - Press "Enable two-factor authentication" +# - 1. Login with the user credentials +# - 2. Go to the user settings page +# - 3. Select 'Account' on the left navigation bar +# - 4. Press 'Enable two-factor authentication' # threat: -# - "Collaborators without two-factor authentication are prime targets for phising and social engineering attacks, as compromise only requires acquiring the collaborator's password." -# - "This is doubly important for external collaborators, as these are identities that aren't likely managed by you or your organization and may be easier to compromise." +# - Collaborators without two-factor authentication are prime targets for phishing and social engineering attacks, as compromise only requires acquiring the collaborator's password. +# - This is doubly important for external collaborators, as these are identities that aren't likely managed by you or your organization and may be easier to compromise. default two_factor_authentication_is_disabled_for_an_external_collaborator := true two_factor_authentication_is_disabled_for_an_external_collaborator := false { @@ -43,16 +44,16 @@ two_factor_authentication_is_disabled_for_an_external_collaborator := false { # METADATA # scope: rule -# title: Admininistrators Should Have Activity in the Last 6 Months -# description: A collaborator with global admin permissions didn't do any action in the last 6 months. Admin users are extremely powerful and common compliance standards demand keeping the number of admins at minimum. Consider revoking this collaborator admin credentials (downgrade to regular user), or remove the user completely. +# title: Administrators Should Have Activity in the Last 6 Months +# description: A collaborator with global admin permissions didn't perform any action in the last 6 months. Admin users are extremely powerful, and common compliance standards demand keeping the number of admins to a minimum. Consider revoking this collaborator's admin credentials (downgrade to regular user) or removing the user completely. # custom: # severity: MEDIUM # remediationSteps: -# - Go to admin menu -# - Select "Overview -> Users" on the left navigation bar -# - Find the stale admin and either delete of block it +# - 1. Go to the admin menu +# - 2. Select 'Overview -> Users' on the left navigation bar +# - 3. Find the stale admin and either delete or block it # threat: -# - "Stale admins are most likely not managed and monitored, increasing the possibility of being compromised." +# - Stale admins are most likely not managed and monitored, increasing the possibility of being compromised. default stale_admin_found := true stale_admin_found := false { diff --git a/policies/gitlab/organization.rego b/policies/gitlab/organization.rego index cdd0b8f0..baf24776 100644 --- a/policies/gitlab/organization.rego +++ b/policies/gitlab/organization.rego @@ -7,13 +7,13 @@ package organization # custom: # severity: HIGH # remediationSteps: -# - Go to the group page -# - Press Settings -> General -# - Expand "Permissions and group features" -# - Toggle "Require all users in this group to set up two-factor authentication" -# - Press "Save Changes" +# - 1. Go to the group page +# - 2. Press Settings -> General +# - 3. Expand 'Permissions and group features' +# - 4. Toggle 'Require all users in this group to set up two-factor authentication' +# - 5. Press 'Save Changes' # threat: -# - If an attacker gets the valid credentials for one of the organization’s users they can authenticate to your GitHub organization. +# - If an attacker gets valid credentials for one of the organization’s users, they can authenticate to your GitHub organization. default two_factor_authentication_not_required_for_group := true two_factor_authentication_not_required_for_group := false { @@ -23,14 +23,14 @@ two_factor_authentication_not_required_for_group := false { # METADATA # scope: rule # title: Forking of Repositories to External Namespaces Should Be Disabled. -# description: The ability to fork project to external namespaces is turned on. Forking a repository can lead to loss of control and potential exposure of source code. If you do not need forking, it is recommended to turn it off in the project's configuration. The option to fork should be enabled only by owners deliberately when opting to create a fork. +# description: The ability to fork a project to external namespaces is turned on. Forking a repository can lead to loss of control and potential exposure of source code. If you do not need forking, it is recommended to turn it off in the project's configuration. The option to fork should be enabled only by owners deliberately when opting to create a fork. # custom: # severity: MEDIUM # remediationSteps: -# - "Go to the top-level groups Settings > General page" -# - "Expand the Permissions and group features section" -# - "Check Prevent project forking outside current group" -# - "Select Save changes" +# - 1. Go to the top-level groups Settings > General page +# - 2. Expand the Permissions and group features section +# - 3. Check 'Prevent project forking outside current group' +# - 4. Select 'Save changes' # threat: # - Forking to external namespaces could result in loss of control over proprietary information and potentially expose the organization to security risks, such as data leaks. default collaborators_can_fork_repositories_to_external_namespaces := true @@ -42,18 +42,18 @@ collaborators_can_fork_repositories_to_external_namespaces := false { # METADATA # scope: rule # title: Webhooks Should Be Configured To Use SSL -# description: Webhooks that are not configured with SSL enabled could expose your sofware to man in the middle attacks (MITM). +# description: Webhooks that are not configured with SSL enabled could expose your software to man-in-the-middle attacks (MITM). # custom: # severity: LOW # requiredEnrichers: [hooksList] # remediationSteps: -# - Go to the group Settings -> Webhooks page -# - Find the misconfigured webhook and press "Edit" -# - Toggle "Enable SSL verification" -# - Press "Save Changes" +# - 1. Go to the group Settings -> Webhooks page +# - 2. Find the misconfigured webhook and press 'Edit' +# - 3. Toggle 'Enable SSL verification' +# - 4. Press 'Save Changes' # threat: -# - "If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request." -# - "In the case of GitLab Self-Managed, it may be sufficient only to control the DNS configuration of the network where the instance is deployed." +# - Webhooks with SSL verification disabled can be exploited by any party with access to the target DNS domain, allowing them to masquerade as your designated payload URL and freely read and affect the response of any webhook request. +# - In the case of GitLab Self-Managed, it may be sufficient only to control the DNS configuration of the network where the instance is deployed. organization_webhook_doesnt_require_ssl[violation] := true { some index hook := input.hooks[index] @@ -68,14 +68,14 @@ organization_webhook_doesnt_require_ssl[violation] := true { # custom: # severity: MEDIUM # remediationSteps: -# - Go to the group page -# - Press Settings -> Repository -# - Expand "Default Branch" section -# - Toggle the required protection rule -# - Press "Save Changes" +# - 1. Go to the group page +# - 2. Press Settings -> Repository +# - 3. Expand 'Default Branch' section +# - 4. Toggle the required protection rule +# - 5. Press 'Save Changes' # threat: # - A developer creates a repository without any branch protection rules -# - Attacker that get access to the repository can modify its main branch without any restrictions +# - An attacker that gains access to the repository can modify its main branch without any restrictions default group_does_not_enforce_branch_protection_by_default := true group_does_not_enforce_branch_protection_by_default := false { @@ -89,13 +89,13 @@ group_does_not_enforce_branch_protection_by_default := false { # custom: # severity: MEDIUM # remediationSteps: -# - Go to the group page -# - Press Settings -> General -# - Expand "Permissions and group features" -# - 'In the box titled: "Delay 2FA enforcement (hours)", enter a number under 168 (preferably 0)' -# - Press "Save Changes" +# - 1. Go to the group page +# - 2. Press Settings -> General +# - 3. Expand 'Permissions and group features' +# - "4. In the box titled: 'Delay 2FA enforcement (hours)', enter a number under 168 (preferably 0)" +# - 5. Press 'Save Changes' # threat: -# - Any new group membmer effectivly acts as an attack surface until two-factor authentication is enabled. The risk is compounded as new members may be more vulnerable to phising and identity theft attacks. +# - Any new group member effectively acts as an attack surface until two-factor authentication is enabled. The risk is compounded as new members may be more vulnerable to phishing and identity theft attacks. default group_allows_excessive_mfa_grace_period := true group_allows_excessive_mfa_grace_period := false{ diff --git a/policies/gitlab/repository.rego b/policies/gitlab/repository.rego index e05522d7..a5d61aaf 100644 --- a/policies/gitlab/repository.rego +++ b/policies/gitlab/repository.rego @@ -5,7 +5,9 @@ package repository # title: Project Should Be Updated At Least Quarterly # description: A project which is not actively maintained may not be patched against security issues within its code and dependencies, and is therefore at higher risk of including known vulnerabilities. # custom: -# remediationSteps: [Make sure you have admin permissions, Either Delete or Archive the project] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Either Delete or Archive the project # severity: HIGH # threat: As new vulnerabilities are found over time, unmaintained repositories are more likely to point to dependencies that have known vulnerabilities, exposing these repositories to 1-day attacks. default project_not_maintained := true @@ -25,13 +27,16 @@ project_not_maintained := false { # METADATA # scope: rule # title: Project Should Have Fewer Than Three Owners -# description: Projects owners are highly privileged and could create great damage if they are compromised. It is recommeneded to limit the number of Project OWners to the minimum required (recommended maximum 3 admins). +# description: Projects owners are highly privileged and could create great damage if they are compromised. It is recommended to limit the number of Project Owners to the minimum required (recommended maximum 3 admins). # custom: # severity: LOW -# remediationSteps: [Make sure you have owner permissions, Go to the Project Information -> Members page, Select the unwanted owner users and remove the selected owners] +# remediationSteps: +# - 1. Make sure you have owner permissions +# - 2. Go to the Project Information -> Members page +# - 3. Select the unwanted owner users and remove the selected owners # threat: -# - "A compromised user with owner permissions can initiate a supply chain attack in a plethora of ways." -# - "Having many admin users increases the overall risk of user compromise, and makes it more likely to lose track of unused admin permissions given to users in the past." +# - A compromised user with owner permissions can initiate a supply chain attack in a plethora of ways. +# - Having many admin users increases the overall risk of user compromise, and makes it more likely to lose track of unused admin permissions given to users in the past. default project_has_too_many_admins := true project_has_too_many_admins := false { @@ -44,9 +49,13 @@ project_has_too_many_admins := false { # title: Forking Should Not Be Allowed # description: Forking a repository can lead to loss of control and potential exposure of source code. If you do not need forking, it is recommended to turn it off in the project's configuration. The option to fork should be enabled only by owners deliberately when opting to create a fork. # custom: -# remediationSteps: [Make sure you have owner permissions, Go to the project's settings page, Enter "General" tab, Under "Visibility, project features, permissions", Toggle off "Forks"] +# remediationSteps: +# - 1. Make sure you have owner permissions +# - 2. Go to the project's settings page +# - 3. Enter 'General' tab +# - 4. Under 'Visibility, project features, permissions', Toggle off 'Forks' # severity: LOW -# threat: Forked repositories may leak important code assets or sensitive secrets embedded in the code to anyone outside your organization, as the code becomes publicy-accessible +# threat: Forked repositories may leak important code assets or sensitive secrets embedded in the code to anyone outside your organization, as the code becomes publicly accessible. default forking_allowed_for_repository := true forking_allowed_for_repository := false { @@ -63,7 +72,12 @@ forking_allowed_for_repository := false { # title: Default Branch Should Be Protected # description: Branch protection is not enabled for this repository’s default branch. Protecting branches ensures new code changes must go through a controlled merge process and allows enforcement of code review as well as other security tests. This issue is raised if the default branch protection is turned off. # custom: -# remediationSteps: [Make sure you have owner permissions, Go to the projects's settings -> Repository page, Enter "Protected branches" tab, select the default branch. Set the allowed to merge to "maintainers" and the allowed to push to "No one"] +# remediationSteps: +# - 1. Make sure you have owner permissions +# - 2. Go to the project's settings -> Repository page +# - 3. Enter 'Protected branches' tab +# - 4. Select the default branch +# - 5. Set the allowed to merge to 'maintainers' and the allowed to push to 'No one' # severity: MEDIUM # prerequisites: [premium] # threat: Any contributor with write access may push potentially dangerous code to this repository, making it easier to compromise and difficult to audit. @@ -79,7 +93,12 @@ missing_default_branch_protection := false { # title: Default Branch Should Not Allow Force Pushes # description: The history of the default branch is not protected against changes for this repository. Protecting branch history ensures every change that was made to code can be retained and later examined. This issue is raised if the default branch history can be modified using force push. # custom: -# remediationSteps: [Make sure you have owner permissions, Go to the projects's settings -> Repository page, Enter "Protected branches" tab, select the default branch. Set the allowed to merge to "maintainers" and the allowed to push to "No one"] +# remediationSteps: +# - 1. Make sure you have owner permissions +# - 2. Go to the project's settings -> Repository page +# - 3. Enter 'Protected branches' tab +# - 4. Select the default branch +# - 5. Set the allowed to merge to 'maintainers' and the allowed to push to 'No one' # severity: MEDIUM # prerequisites: [premium] # threat: Rewriting project history can make it difficult to trace back when bugs or security issues were introduced, making them more difficult to remediate. @@ -98,7 +117,12 @@ missing_default_branch_protection_force_push := false { # title: Default Branch Should Limit Code Review to Code-Owners # description: It is recommended to require code review only from designated individuals specified in CODEOWNERS file. Turning this option on enforces that only the allowed owners can approve a code change. This option is found in the branch protection setting of the project. # custom: -# remediationSteps: [Make sure you have owner permissions, Go to the projects's settings -> Repository page, Enter "Protected branches" tab, select the default branch. Check the "Code owner approval"] +# remediationSteps: +# - 1. Make sure you have owner permissions +# - 2. Go to the project's settings -> Repository page +# - 3. Enter 'Protected branches' tab +# - 4. Select the default branch +# - 5. Check the 'Code owner approval' # severity: LOW # prerequisites: [premium] # threat: A pull request may be approved by any contributor with write access. Specifying specific code owners can ensure review is only done by individuals with the correct expertise required for the review of the changed files, potentially preventing bugs and security risks. @@ -113,13 +137,18 @@ repository_require_code_owner_reviews_policy := false { # METADATA # scope: rule # title: Webhook Configured Without SSL Verification -# description: Webhooks that are not configured with SSL verification enabled could expose your sofware to man in the middle attacks (MITM). +# description: Webhooks that are not configured with SSL verification enabled could expose your software to man-in-the-middle attacks (MITM). # custom: # severity: LOW -# remediationSteps: [Make sure you can manage webhooks for the project, Go to the project's settings page, Select "Webhooks", Press on the "Enable SSL verfication", Click "Save changes"] +# remediationSteps: +# - 1. Make sure you can manage webhooks for the project +# - 2. Go to the project's settings page +# - 3. Select 'Webhooks' +# - 4. Press on the 'Enable SSL verification' +# - 5. Click 'Save changes' # threat: -# - "If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request." -# - "In the case of GitLab Self-Managed, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain." +# - If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it to freely read and affect the response of any webhook request. +# - In the case of GitLab Self-Managed, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain. default project_webhook_doesnt_require_ssl := true project_webhook_doesnt_require_ssl := false{ @@ -133,7 +162,12 @@ project_webhook_doesnt_require_ssl := false{ # description: Checks that validate the quality and security of the code are not required to pass before submitting new changes. It is advised to turn this flag on to ensure any existing or future check will be required to pass. # custom: # severity: MEDIUM -# remediationSteps: [Make sure you can manage project merge requests permissions, Go to the project's settings page, Select "Merge Requests", Press on the "Pipelines must succeed", Click "Save changes"] +# remediationSteps: +# - 1. Make sure you can manage project merge requests permissions +# - 2. Go to the project's settings page +# - 3. Select 'Merge Requests' +# - 4. Press on the 'Pipelines must succeed' +# - 5. Click 'Save changes' # threat: Not defining a set of required status checks can make it easy for contributors to introduce buggy or insecure code as manual review, whether mandated or optional, is the only line of defense. default requires_status_checks := true @@ -144,10 +178,15 @@ requires_status_checks := false { # METADATA # scope: rule # title: Project Should Require All Conversations To Be Resolved Before Merge -# description: Require all merge request conversations to be resolved before merging. Check this to avoid bypassing/missing a Pull Reuqest comment. +# description: Require all merge request conversations to be resolved before merging. Check this to avoid bypassing/missing a Pull Request comment. # custom: # severity: LOW -# remediationSteps: [Make sure you can manage project merge requests permissions, Go to the project's settings page, Select "Merge Requests", Press on the "All threads must be resolved", Click "Save changes"] +# remediationSteps: +# - 1. Make sure you can manage project merge requests permissions +# - 2. Go to the project's settings page +# - 3. Select 'Merge Requests' +# - 4. Press on the 'All threads must be resolved' +# - 5. Click 'Save changes' # threat: Allowing the merging of code without resolving all conversations can promote poor and vulnerable code, as important comments may be forgotten or deliberately ignored when the code is merged. default no_conversation_resolution := true @@ -160,7 +199,11 @@ no_conversation_resolution := false { # title: Default Branch Should Require All Commits To Be Signed # description: Require all commits to be signed and verified # custom: -# remediationSteps: [Make sure you have owner permissions, Go to the projects's settings -> Repository page, Enter "Push Rules" tab. Set the "Reject unsigned commits" checkbox ] +# remediationSteps: +# - 1. Make sure you have owner permissions +# - 2. Go to the project's settings -> Repository page +# - 3. Enter 'Push Rules' tab +# - 4. Set the 'Reject unsigned commits' checkbox # severity: LOW # prerequisites: [premium] # threat: A commit containing malicious code may be crafted by a malicious actor that has acquired write access to the repository to initiate a supply chain attack. Commit signing provides another layer of defense that can prevent this type of compromise. @@ -176,11 +219,18 @@ no_signed_commits := false { # title: Default Branch Should Require Code Review # description: In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management built-in enforcement. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Merge Requests" tab, Under "Merge request approvals", Click "Add approval rule" on the default branch rule, Select "Approvals required" and enter at least 1 approvers", Select "Add approvers" and select the desired members, Click "Add approval rule"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Merge Requests' tab +# - 4. Under 'Merge request approvals', Click 'Add approval rule' on the default branch rule +# - 5. Select 'Approvals required' and enter at least 1 approvers +# - 6. Select 'Add approvers' and select the desired members +# - 7. Click 'Add approval rule' # severity: HIGH # prerequisites: [premium] # threat: -# - "Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production." +# - Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production. default code_review_not_required := true code_review_not_required := false { @@ -192,11 +242,18 @@ code_review_not_required := false { # title: Default Branch Should Require Code Review By At Least Two Reviewers # description: In order to comply with separation of duties principle and enforce secure code practices, a code review should be mandatory using the source-code-management built-in enforcement. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Merge Requests" tab, Under "Merge request approvals", Click "Add approval rule" on the default branch rule, Select "Approvals required" and enter at least 2 approvers", Select "Add approvers" and select the desired members, Click "Add approval rule"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Merge Requests' tab +# - 4. Under 'Merge request approvals', Click 'Add approval rule' on the default branch rule +# - 5. Select 'Approvals required' and enter at least 2 approvers +# - 6. Select 'Add approvers' and select the desired members +# - 7. Click 'Add approval rule' # severity: MEDIUM # prerequisites: [premium] # threat: -# - "Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production." +# - Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production. default code_review_by_two_members_not_required := true code_review_by_two_members_not_required := false { @@ -208,10 +265,15 @@ code_review_by_two_members_not_required := false { # title: Repository Should Not Allow Review Requester To Approve Their Own Request # description: To comply with separation of duties and enforce secure code practices, the repository should prohibit pull request owners from approving their own changes. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Merge Requests" tab, Under "Approval settings", Check "Prevent approval by author", Click "Save Changes"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Merge Requests' tab +# - 4. Under 'Approval settings', Check 'Prevent approval by author' +# - 5. Click 'Save Changes' # severity: MEDIUM # threat: -# - "Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production." +# - Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production. default repository_allows_review_requester_to_approve_their_own_request := true repository_allows_review_requester_to_approve_their_own_request := false { @@ -223,11 +285,16 @@ repository_allows_review_requester_to_approve_their_own_request := false { # title: Merge Request Authors Should Not Be Able To Override the Approvers List # description: A repository should not allow merge request authors to freely edit the list of required approvers. To enforce code review only by authorized personnel, the option to override the list of valid approvers for the merge request must be toggled off. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Merge Requests" tab, Under "Approval settings", Check "Prevent editing approval rules in merge requests", Click "Save Changes"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Merge Requests' tab +# - 4. Under 'Approval settings', Check 'Prevent editing approval rules in merge requests' +# - 5. Click 'Save Changes' # severity: MEDIUM # prerequisites: [premium] # threat: -# - "Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production." +# - Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production. default repository_allows_overriding_approvers := true repository_allows_overriding_approvers := false { @@ -239,11 +306,16 @@ repository_allows_overriding_approvers := false { # title: Repository Should Not Allow Committer Approvals # description: The repository allows merge request contributors (that aren't the merge request author), to approve the merge request. To ensure merge request review is done objectively, it is recommended to toggle this option off. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Merge Requests" tab, Under "Approval settings", Check "Prevent approvals by users who add commits", Click "Save Changes"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Merge Requests' tab +# - 4. Under 'Approval settings', Check 'Prevent approvals by users who add commits' +# - 5. Click 'Save Changes' # severity: LOW # prerequisites: [premium] # threat: -# - "Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production." +# - Users can merge code without being reviewed which can lead to insecure code reaching the main branch and production. default repository_allows_committer_approvals_policy := true repository_allows_committer_approvals_policy := false { @@ -255,7 +327,12 @@ repository_allows_committer_approvals_policy := false { # title: Default Branch Should Require New Code Changes After Approval To Be Re-Approved # description: This security control prevents merging code that was approved but later on changed. Turning it on ensures new changes are required to be reviewed again. This setting is part of the Merge request approval settings, and hardens the code-review process. If turned off - a developer can change the code after approval, and push code that is different from the one that was previously allowed. # custom: -# remediationSteps: [Make sure you have admin permissions, Go to the repo's settings page, Enter "Merge Requests" tab, Under "Approval settings", Check "Remove all approvals", Click "Save Changes"] +# remediationSteps: +# - 1. Make sure you have admin permissions +# - 2. Go to the repo's settings page +# - 3. Enter 'Merge Requests' tab +# - 4. Under 'Approval settings', Check 'Remove all approvals' +# - 5. Click 'Save Changes' # severity: LOW # prerequisites: [premium] # threat: Buggy or insecure code may be committed after approval and will reach the main branch without review. Alternatively, an attacker can attempt a just-in-time attack to introduce dangerous code just before merge. diff --git a/scripts/gen-gh-pages-docs.py b/scripts/gen-gh-pages-docs.py index 032cc414..da55b859 100755 --- a/scripts/gen-gh-pages-docs.py +++ b/scripts/gen-gh-pages-docs.py @@ -1,6 +1,5 @@ #!/usr/bin/env python3 -import sys import yaml import os import argparse @@ -46,7 +45,7 @@ def gen_policy_markdown(policy): threat = policy["threat"] remediation_string = "".join( - [f"{index+1}. {line}\n" for index, line in enumerate(remediation)] + [f"{line}\n" for line in remediation] ) remediation = f""" {format_header(HeaderSize.H3, "Remediation")} @@ -96,7 +95,7 @@ def create_ns_policies(output_dir, ns, docs_yaml, parent): os.mkdir(ns_dir) title = f"{ns.title()} Policies" - file_path = os.path.join(ns_dir, f"index.md") + file_path = os.path.join(ns_dir, "index.md") file_header = f"""--- layout: default title: {title} @@ -117,7 +116,7 @@ def create_ns_policies(output_dir, ns, docs_yaml, parent): def create_scm_policy_docs(scm, docs_yaml, output_dir): scm_outdir = os.path.join(output_dir, scm) os.mkdir(scm_outdir) - file_path = os.path.join(scm_outdir, f"index.md") + file_path = os.path.join(scm_outdir, "index.md") title = f"{scm_to_pretty_name(scm)} Policies" file_header = f"""--- layout: default