update docs

Legit-Labs · May 19, 2024 · 0c02705 · 0c02705
1 parent 492be5d
commit 0c02705
Show file tree

Hide file tree

Showing 87 changed files with 390 additions and 441 deletions.
diff --git a/docs/CNAME b/docs/CNAME
@@ -1 +1 @@
-policies.legitify.dev
+legitify.dev
diff --git a/docs/Gemfile b/docs/Gemfile
diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock
diff --git a/docs/github/actions/actions_can_approve_pull_requests.md b/docs/github/actions/actions_can_approve_pull_requests.md
@@ -22,9 +22,9 @@ Attackers can exploit this misconfiguration to bypass code-review restrictions b
 ### Remediation
 1. Make sure you have admin permissions
 2. Go to the org's settings page
-3. Enter "Actions - General" tab
+3. Enter 'Actions - General' tab
 4. Under 'Workflow permissions'
-5. Uncheck 'Allow GitHub actions to create and approve pull requests.
+5. Uncheck 'Allow GitHub actions to create and approve pull requests'
 6. Click 'Save'
 
 

diff --git a/docs/github/actions/all_github_actions_are_allowed.md b/docs/github/actions/all_github_actions_are_allowed.md
@@ -15,7 +15,6 @@ severity: MEDIUM
 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.
 
 ### Threat Example(s)
-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
@@ -25,12 +24,11 @@ This misconfiguration could lead to the following attack:
 ### Remediation
 1. Make sure you have admin permissions
 2. Go to the org's settings page
-3. Enter "Actions - General" tab
-4. Under "Policies"
-5. Select "Allow enterprise, and select non-enterprise, actions and reusable workflows"
-6. Check "Allow actions created by GitHub" and "Allow actions by Marketplace verified creators"
-7. Set any other used trusted actions under "Allow specified actions and reusable workflows"
-8. Click "Save"
+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'
 
 
 
diff --git a/docs/github/actions/all_repositories_can_run_github_actions.md b/docs/github/actions/all_repositories_can_run_github_actions.md
@@ -15,8 +15,6 @@ severity: MEDIUM
 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.
 
 ### Threat Example(s)
-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
@@ -27,10 +25,9 @@ This misconfiguration could lead to the following attack:
 ### Remediation
 1. Make sure you have admin permissions
 2. Go to the org's settings page
-3. Enter the "Actions - General" tab
-4. Under "Policies"
-5. Change "All repositories" to "Selected repositories" and select repositories that should be able to run actions
-6. Click "Save"
+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'
 
 
 
diff --git a/docs/github/actions/token_default_permissions_is_read_write.md b/docs/github/actions/token_default_permissions_is_read_write.md
@@ -22,7 +22,7 @@ In case of token compromise (due to a vulnerability or malicious third-party Git
 ### Remediation
 1. Make sure you have admin permissions
 2. Go to the org's settings page
-3. Enter "Actions - General" tab
+3. Enter 'Actions - General' tab
 4. Under 'Workflow permissions'
 5. Select 'Read repository contents permission'
 6. Click 'Save'

diff --git a/docs/github/enterprise/enterprise_allows_creating_public_repos.md b/docs/github/enterprise/enterprise_allows_creating_public_repos.md
@@ -1,29 +1,28 @@
 ---
 layout: default
-title: Enterprise Should Prevent Members From Creating public Repositories
+title: Enterprise Should Prevent Members From Creating Public Repositories
 parent: Enterprise Policies
 grand_parent: GitHub Policies
 ---
 
 
-## Enterprise Should Prevent Members From Creating public Repositories
+## Enterprise Should Prevent Members From Creating Public Repositories
 policy name: enterprise_allows_creating_public_repos
 
 severity: MEDIUM
 
 ### 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.
+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.
 
 ### Threat Example(s)
-Users can accidentaly create public repositories and expose source code.
+Users can accidentally create public repositories and expose source code.
 
 
 
 ### Remediation
 1. Make sure you are an enterprise owner
 2. Go to the policies page
-3. Under the "Repository creation" section
-4. Choose the "Members can create repositories" option and uncheck 'Public'
+3. Under the 'Repository creation' section, Choose the 'Members can create repositories' option and uncheck 'Public'
 
 
 
diff --git a/docs/github/enterprise/enterprise_allows_forking_repos.md b/docs/github/enterprise/enterprise_allows_forking_repos.md
@@ -22,8 +22,7 @@ Forking to external namespaces could result in loss of control over proprietary
 ### Remediation
 1. Make sure you are an enterprise owner
 2. Go to the policies page
-3. Under the "Repository Forking" section
-4. Choose the "Disabled" option
+3. Under the 'Repository Forking' section, Choose the 'Disabled' option
 
 
 
diff --git a/docs/github/enterprise/enterprise_allows_inviting_externals_collaborators.md b/docs/github/enterprise/enterprise_allows_inviting_externals_collaborators.md
@@ -12,7 +12,7 @@ policy name: enterprise_allows_inviting_externals_collaborators
 severity: MEDIUM
 
 ### 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.
+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.
 
 ### Threat Example(s)
 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.
@@ -22,7 +22,7 @@ Inviting external collaborators could result in a loss of control over proprieta
 ### Remediation
 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
+3. Under the 'Repository outside collaborators' section, choose the 'Enterprise Owners Only' or the 'Organization Owners Only' option
 
 
 
diff --git a/docs/github/enterprise/enterprise_enforce_two_factor_authentication.md b/docs/github/enterprise/enterprise_enforce_two_factor_authentication.md
@@ -12,18 +12,18 @@ policy name: enterprise_enforce_two_factor_authentication
 severity: HIGH
 
 ### 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.
+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.
 
 ### Threat Example(s)
-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.
 
 
 
 ### Remediation
 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
+4. Check the 'Require two-factor authentication for all organizations in the enterprise' checkbox
 
 
 
diff --git a/docs/github/enterprise/enterprise_not_using_single_sign_on.md b/docs/github/enterprise/enterprise_not_using_single_sign_on.md
@@ -12,7 +12,7 @@ policy name: enterprise_not_using_single_sign_on
 severity: MEDIUM
 
 ### 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.
+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.
 
 ### Threat Example(s)
 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.
@@ -23,9 +23,9 @@ Not using an SSO solution makes it more difficult to track a potentially comprom
 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"
+4. Toggle on 'Enable SAML authentication'
 5. Fill in the remaining SSO configuration as instructed on the screen
-6. Click "Save"
+6. Click 'Save'
 
 
 
diff --git a/docs/github/enterprise/enterprise_not_using_visibility_change_disable_policy.md b/docs/github/enterprise/enterprise_not_using_visibility_change_disable_policy.md
@@ -12,7 +12,7 @@ policy name: enterprise_not_using_visibility_change_disable_policy
 severity: MEDIUM
 
 ### 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.
+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.
 
 ### Threat Example(s)
 A member of the organization could inadvertently or maliciously make public an internal repository exposing confidential data.
@@ -22,8 +22,7 @@ A member of the organization could inadvertently or maliciously make public an i
 ### Remediation
 1. Make sure you are an enterprise owner
 2. Go to the policies page
-3. Under the "Repository visibility change" section
-4. choose the "Disabled" option
+3. Under the 'Repository visibility change' section, choose the 'Disabled' option
 
 
 
diff --git a/docs/github/enterprise/memberes_allowed_repository_move_or_deletion.md b/docs/github/enterprise/memberes_allowed_repository_move_or_deletion.md
@@ -23,8 +23,7 @@ A member of the organization could inadvertently or maliciously transfer a repos
 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
-5. under ‘Repository deletion and transfer' and select 'Disabled'
+4. Go to the ‘Admin repository permissions' section, under ‘Repository deletion and transfer' and select 'Disabled'
 
 
 
diff --git a/docs/github/enterprise/repository_no_permission_enforced_by_default.md b/docs/github/enterprise/repository_no_permission_enforced_by_default.md
@@ -1,12 +1,12 @@
 ---
 layout: default
-title: Enterprise Should Define Base Permissions As “No Permission” For All Members
+title: Enterprise Should Define Base Permissions As 'No Permission' For All Members
 parent: Enterprise Policies
 grand_parent: GitHub Policies
 ---
 
 
-## Enterprise Should Define Base Permissions As “No Permission” For All Members
+## Enterprise Should Define Base Permissions As 'No Permission' For All Members
 policy name: repository_no_permission_enforced_by_default
 
 severity: MEDIUM
@@ -22,9 +22,8 @@ An adversary will have access to all repositories in the enterprise, instead of
 ### Remediation
 1. Make sure you are an enterprise owner
 2. Go to the Settings page
-3. Under the ‘Policies’ tab
-4. choose ‘Repositories’
-5. Under ‘Base Permission’ choose ‘No Permission’
+3. Under the 'Policies' tab, choose 'Repositories'
+4. Under 'Base Permission' choose 'No Permission'
 
 
 
diff --git a/docs/github/member/organization_has_too_many_admins.md b/docs/github/member/organization_has_too_many_admins.md
@@ -15,7 +15,7 @@ severity: MEDIUM
 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).
 
 ### Threat Example(s)
-1. An organization has a permissive attitude and provides an owner role to all developers.
+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)
 
@@ -25,7 +25,7 @@ Organization owners are highly privileged and could create great damage if they
 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
+4. Using the 'X members selected' - change role to member
 
 
 
diff --git a/docs/github/member/stale_admin_found.md b/docs/github/member/stale_admin_found.md
@@ -23,7 +23,7 @@ Stale admins are most likely not managed and monitored, increasing the possibili
 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
+4. Using the 'X members selected' - remove members from organization
 
 
 
diff --git a/docs/github/member/stale_member_found.md b/docs/github/member/stale_member_found.md
@@ -23,7 +23,7 @@ Stale members are most likely not managed and monitored, increasing the possibil
 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
+4. Using the 'X members selected' - remove members from organization
 
 
 
diff --git a/docs/github/organization/default_repository_permission_is_not_none.md b/docs/github/organization/default_repository_permission_is_not_none.md
@@ -22,10 +22,10 @@ Organization members can see the content of freshly created repositories, even i
 ### Remediation
 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"
+3. Enter 'Member privileges' tab
+4. Under 'Base permissions'
+5. Set permissions to 'No permissions'
+6. Click 'Save'