Add Compliance check: `githubOrgMFA`

[UlisesGascon]

How the Check Works

After some research, it seems like two_factor_requirement_enabled is the best field that can provide us with the information from the table github_organizations, which we populate from the GitHub API.

When the value of two_factor_requirement_enabled is true, the organization requires all members, billing managers, and outside collaborators to enable two-factor authentication. GH API documentation

Main logic:

• If the value is true, it is considered as passed.
• If the value is false, it is considered as failed.
• If the value is NULL, it is considered as unknown.

Logic Edge Cases (multiple GitHub organizations):

1. With a single failed organization, the global check is considered failed.
2. With a single unknown organization (without any failed ones), the global check is considered unknown.
3. Only if all the organizations have passed, the global consideration is passed.

Alerts:

• Trigger alerts only when there are failed organizations in the project. Ignore other scenarios.

Tasks:

• Same as alerts.

Pending Tasks

• 1. Define a Good Implementation
  • Read the documentation (guidelines, best practices...)
  • Brainstorm how to implement this check (logic, alerts, tasks, validations, edge cases...).
  • Achieve an agreement on the implementation details before starting to work on this.
• 2. Update Check Record
  • Update the compliance_checks row with the following fields: how_to_url, implementation_status, implementation_type and implementation_details_reference
  • Check the migration scripts using npm run db:migrate and npm run db:rollback
  • Update the database schema by running npm run db:generate-schema
• 3. Implement the Business Logic
  • Add the specific validator in src/checks/validators/index.js
  • Add the check logic in src/checks/complianceChecks
  • Ensure that the check is in scope for the organization (use isCheckApplicableToProjectCategory)
  • Ensure that the severity value is well calculated (use getSeverityFromPriorityGroup)
  • Add the alert row in the compliance_checks_alerts table when is needed.
  • Add the task row in the compliance_checks_tasks table when is needed.
  • Add the result row in the compliance_checks_results table.
• 4. Ensure It Works as Expected
  • Add new unit tests for the validator check.
  • Add new integration test cases for this check.
  • Verify that all tests are passing.
  • Run the command check run --name {check_code_name} and verify the changes in the database. Update the seed script if needed (npm run db:seed)
• 5. Update the website
  • Review the current content it in https://openjs-security-program-standards.netlify.app/details/{check_code_name}
  • Create a PR in https://github.com/secure-dashboards/openjs-security-program-standards to include how we calculate this check and include additional information on the mitigation if needed.

[UlisesGascon]

After some research, it seems like two_factor_requirement_enabled is the best field that can provide us with the information from the table github_organizations, which we populate from the GitHub API.

When the value of two_factor_requirement_enabled is true, the organization requires all members, billing managers, and outside collaborators to enable two-factor authentication. GH API documentation

Main logic:

• If the value is true, it is considered as passed.
• If the value is false, it is considered as failed.
• If the value is NULL, it is considered as unknown.

Logic Edge Cases (multiple GitHub organizations):

1. With a single failed organization, the global check is considered failed.
2. With a single unknown organization (without any failed ones), the global check is considered unknown.
3. Only if all the organizations have passed, the global consideration is passed.

Alerts:

• Trigger alerts only when there are failed organizations in the project. Ignore other scenarios.

Tasks:

• Same as alerts.

[UlisesGascon]

Both PRs are landed, so this check is considered completed at this stage 🥳