Try   HackMD

Category Indexes

Category Option 1.1

1. User Authentication

  1. Multi Factor Authentication (MFA) Enforced Across the Github Organization
  2. Multi Factor Authentication (MFA) Enforced Across the npm Organization
  3. Multi Factor Authentication (MFA) Enforced in All Tools Wherever Techncially Feasible
  4. Use Multi Factor Authentication (MFA) Methods that Defend Against Impersonation when Available
  5. Use SSH keys for developer access to source code repositories and use a passphrase
  6. Github.com: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
  7. Non-Interactive Github: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
  8. All Other Contexts: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics

2. User Account Permissions

  1. Default Github Org Member Permissions Should Be Restricted
  2. Only Admins Should Be Able To Create Public Repositories
  3. [For Projects with Two or more Admins] Do not allow Admins to Bypass Branch Protection Settings
  4. Define roles aligned to functional responsibilities
  5. Define Individuals/Teams who Write Access to a Github Repo
  6. [For Projects with Two or more Owners] Have at least Two Owners Configured for Access Continuity
  7. Github Organization Admins Should Have Activity In The Last 6 Months
  8. Github Organization Members with Write Permissions Should Have Activity In The Last 6 Months
  9. Limit Number of Github Org Owners (ideally Fewer Than Three)
  10. Limit Number of Github Repository Admins (ideally Fewer Than Three)

3. Service Authentication

  1. No Secrets and Credentials in Source Code
  2. Secrets are injected at runtime, such as environment variables or as a file (eg: use Github Secrets)
  3. Publish to npm using an MFA-enabled account rather than single factor legacy or granular access tokens
  4. Github Webhooks Use Secrets

4. Github Workflows

  1. Github Org Default Workflow Token Permissions are Set to Read Only
  2. Workflows are not Allowed To Create or Approve Pull Requests
  3. GitHub Organization Secrets are Restricted to Selected Repositories
  4. GitHub Actions Should Be Limited To Verified or Explicitly Trusted Actions
  5. Consistent and Automated Build Process is Documented and Used
  6. Disable use of Self-Hosted Runners in Github Org
  7. Build Pipeline Cannot Execute Arbitrary Code from Outside of a Build Script
  8. Only Allow Workflows Write Permissions at the Job-Level
  9. Avoid Script Injection from Untrusted Context Variables
  10. Pin Actions with Access to Secrets to a Full Length Commit SHA
  11. Limit changes from forks to workflows by requiring approval for all outside collaborators
  12. Use a Workflow Security Scanner
  13. Use a Github Runner Security Scanner

Category Option 1.2

1. User Authentication

1.1. Multi Factor Authentication (MFA) Enforced Across the Github Organization
1.2. Multi Factor Authentication (MFA) Enforced Across the npm Organization
1.3. Multi Factor Authentication (MFA) Enforced in All Tools Wherever Techncially Feasible
1.4. Use Multi Factor Authentication (MFA) Methods that Defend Against Impersonation when Available
1.5. Use SSH keys for developer access to source code repositories and use a passphrase
1.6. Github.com: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
1.7. Non-Interactive Github: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
1.8. All Other Contexts: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics

2. User Account Permissions

2.1. Default Github Org Member Permissions Should Be Restricted
2.2. Only Admins Should Be Able To Create Public Repositories
2.3. [For Projects with Two or more Admins] Do not allow Admins to Bypass Branch Protection Settings
2.4. Define roles aligned to functional responsibilities
2.5. Define Individuals/Teams who Write Access to a Github Repo
2.6. [For Projects with Two or more Owners] Have at least Two Owners Configured for Access Continuity
2.7. Github Organization Admins Should Have Activity In The Last 6 Months
2.8. Github Organization Members with Write Permissions Should Have Activity In The Last 6 Months
2.9. Limit Number of Github Org Owners (ideally Fewer Than Three)
2.10. Limit Number of Github Repository Admins (ideally Fewer Than Three)

3. Service Authentication

3.1. No Secrets and Credentials in Source Code
3.2. Secrets are injected at runtime, such as environment variables or as a file (eg: use Github Secrets)
3.3. Publish to npm using an MFA-enabled account rather than single factor legacy or granular access tokens
3.4. Github Webhooks Use Secrets

4. Github Workflows

4.1. Github Org Default Workflow Token Permissions are Set to Read Only
4.2. Workflows are not Allowed To Create or Approve Pull Requests
4.3. GitHub Organization Secrets are Restricted to Selected Repositories
4.4. GitHub Actions Should Be Limited To Verified or Explicitly Trusted Actions
4.5. Consistent and Automated Build Process is Documented and Used
4.6. Disable use of Self-Hosted Runners in Github Org
4.7. Build Pipeline Cannot Execute Arbitrary Code from Outside of a Build Script
4.8. Only Allow Workflows Write Permissions at the Job-Level
4.9. Avoid Script Injection from Untrusted Context Variables
4.10. Pin Actions with Access to Secrets to a Full Length Commit SHA
4.11. Limit changes from forks to workflows by requiring approval for all outside collaborators
4.12. Use a Workflow Security Scanner
4.13. Use a Github Runner Security Scanner

Category Option 2.1

1. User Authentication

ID Guideline
1.1 Multi Factor Authentication (MFA) Enforced Across the Github Organization
1.2 Multi Factor Authentication (MFA) Enforced Across the npm Organization
1.3 Multi Factor Authentication (MFA) Enforced in All Tools Wherever Techncially Feasible
1.4 Use Multi Factor Authentication (MFA) Methods that Defend Against Impersonation when Available
1.5 Use SSH keys for developer access to source code repositories and use a passphrase
1.6 Github.com: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
1.7 Non-Interactive Github: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
1.8 All Other Contexts: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics

2. User Account Permissions

ID Guideline
2.1 Default Github Org Member Permissions Should Be Restricted
2.2 Only Admins Should Be Able To Create Public Repositories
2.3 [For Projects with Two or more Admins] Do not allow Admins to Bypass Branch Protection Settings
2.4 Define roles aligned to functional responsibilities
2.5 Define Individuals/Teams who Write Access to a Github Repo
2.6 [For Projects with Two or more Owners] Have at least Two Owners Configured for Access Continuity
2.7 Github Organization Admins Should Have Activity In The Last 6 Months
2.8 Github Organization Members with Write Permissions Should Have Activity In The Last 6 Months
2.9 Limit Number of Github Org Owners (ideally Fewer Than Three)
2.10 Limit Number of Github Repository Admins (ideally Fewer Than Three)

3. Service Authentication

ID Guideline
3.1 No Secrets and Credentials in Source Code
3.2 Secrets are injected at runtime, such as environment variables or as a file (eg: use Github Secrets)
3.3 Publish to npm using an MFA-enabled account rather than single factor legacy or granular access tokens
3.4 Github Webhooks Use Secrets

4. Github Workflows

ID Guideline
4.1 Github Org Default Workflow Token Permissions are Set to Read Only
4.2 Workflows are not Allowed To Create or Approve Pull Requests
4.3 GitHub Organization Secrets are Restricted to Selected Repositories
4.4 GitHub Actions Should Be Limited To Verified or Explicitly Trusted Actions
4.5 Consistent and Automated Build Process is Documented and Used
4.6 Disable use of Self-Hosted Runners in Github Org
4.7 Build Pipeline Cannot Execute Arbitrary Code from Outside of a Build Script
4.8 Only Allow Workflows Write Permissions at the Job-Level
4.9 Avoid Script Injection from Untrusted Context Variables
4.10 Pin Actions with Access to Secrets to a Full Length Commit SHA
4.11 Limit changes from forks to workflows by requiring approval for all outside collaborators
4.12 Use a Workflow Security Scanner
4.13 Use a Github Runner Security Scanner

Category Option 2.2

1. User Authentication

ID Inc AL&I Ar Guideline
UA:MFG E E E Multi Factor Authentication (MFA) Enforced Across the Github Organization
UA:MFN E E E Multi Factor Authentication (MFA) Enforced Across the npm Organization
UA:MFO E E E Multi Factor Authentication (MFA) Enforced in All Tools Wherever Techncially Feasible
UA:MFI E E E Use Multi Factor Authentication (MFA) Methods that Defend Against Impersonation when Available
UA:SSH E E E Use SSH keys for developer access to source code repositories and use a passphrase
UA:AAL3I R R R Github.com: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
UA:AAL3NI R R R Non-Interactive Github: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics
UA:AAL3O R R R All Other Contexts: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics

2. User Account Permissions

ID I A R Guideline
2.1 E E E Default Github Org Member Permissions Should Be Restricted
2.2 E E E Only Admins Should Be Able To Create Public Repositories
2.3 E E E [For Projects with Two or more Admins] Do not allow Admins to Bypass Branch Protection Settings
2.4 E E E Define roles aligned to functional responsibilities
2.5 E E E Define Individuals/Teams who Write Access to a Github Repo
2.6 E E E [For Projects with Two or more Owners] Have at least Two Owners Configured for Access Continuity
2.7 R R NA Github Organization Admins Should Have Activity In The Last 6 Months
2.8 R R NA Github Organization Members with Write Permissions Should Have Activity In The Last 6 Months
2.9 R R R Limit Number of Github Org Owners (ideally Fewer Than Three)
2.10 R R R Limit Number of Github Repository Admins (ideally Fewer Than Three)

3. Service Authentication

ID I A R Guideline
3.1 E E E No Secrets and Credentials in Source Code
3.2 E E E Secrets are injected at runtime, such as environment variables or as a file (eg: use Github Secrets)
3.3 E E E Publish to npm using an MFA-enabled account rather than single factor legacy or granular access tokens
3.4 E E E Github Webhooks Use Secrets

4. Github Workflows

ID I A R Guideline
4.1 E E NA Github Org Default Workflow Token Permissions are Set to Read Only
4.2 E E E Workflows are not Allowed To Create or Approve Pull Requests
4.3 E E NA GitHub Organization Secrets are Restricted to Selected Repositories
4.4 E E NA GitHub Actions Should Be Limited To Verified or Explicitly Trusted Actions
4.5 E E NA Consistent and Automated Build Process is Documented and Used
4.6 E E E Disable use of Self-Hosted Runners in Github Org
4.7 E E NA Build Pipeline Cannot Execute Arbitrary Code from Outside of a Build Script
4.8 E E E Only Allow Workflows Write Permissions at the Job-Level
4.9 E E NA Avoid Script Injection from Untrusted Context Variables
4.10 D E NA Pin Actions with Access to Secrets to a Full Length Commit SHA
4.11 R R R Limit changes from forks to workflows by requiring approval for all outside collaborators
4.12 R R R Use a Workflow Security Scanner
4.13 R R R Use a Github Runner Security Scanner

Category Option 3.2

1. User Authentication

ID Guideline In AL&I Ar
UA:MFG Multi Factor Authentication (MFA) Enforced Across the Github Organization E E E
UA:MFN Multi Factor Authentication (MFA) Enforced Across the npm Organization E E E
UA:MFO Multi Factor Authentication (MFA) Enforced in All Tools Wherever Techncially Feasible E E E
UA:MFI Use Multi Factor Authentication (MFA) Methods that Defend Against Impersonation when Available E E E
UA:SSH Use SSH keys for developer access to source code repositories and use a passphrase E E E
UA:AAL3I Github.com: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics R R R
UA:AAL3NI Non-Interactive Github: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics R R R
UA:AAL3O All Other Contexts: Use a passkey (AAL2) or hardware key (AAL3) that activates using a password or biometrics R R R

2. User Account Permissions

ID Guideline In AL&I Ar
UP:GHOP Default Github Org Member Permissions Should Be Restricted E E E
UP:ADMPR Only Admins Should Be Able To Create Public Repositories E E E
UP:ADMBP [For Projects with Two or more Admins] Do not allow Admins to Bypass Branch Protection Settings E E E
UP:RAFR Define roles aligned to functional responsibilities E E E
UP:RWA Define Individuals/Teams who Write Access to a Github Repo E E E
UP:OAC [For Projects with Two or more Owners] Have at least Two Owners Configured for Access Continuity E E E
UP:GHADA Github Organization Admins Should Have Activity In The Last 6 Months R R NA
UP:GHWPA Github Organization Members with Write Permissions Should Have Activity In The Last 6 Months R R NA
UP:LGHO Limit Number of Github Org Owners (ideally Fewer Than Three) R R R
UP:LGHAD Limit Number of Github Repository Admins (ideally Fewer Than Three) R R R