Add Compliance check: noSensitiveInfoInRepositories

[UlisesGascon]

How the Check Works

Provide a clear definition based on the spreadsheet

Pending Tasks

You can find more details in the contributing guide

• 1. Define a Good Implementation Example
  • 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 Example
  • 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 Validator Example and Check Example
  • 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 Example
  • 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 "No Secrets and Credentials in Source Code" can be achieved by enabling the secret scanning capabilities in GitHub.

Organizational and Repository Settings

It appears that organizations have dedicated settings to enable this feature, and individual projects (repositories) can enable or disable it independently. Based on the API information we can collect for organizations and repositories, we have the data necessary to perform a comprehensive query.

Criteria for Validation

Organization-Level Validation

We want to ensure that the organization has these settings enabled by default. Specifically, we expect the following columns in the github_organizations table to have positive values:

• secret_scanning_enabled_for_new_repositories = true

Repository-Level Validation

For every project that belongs to the organization, we expect the following columns in the github_repositories table to have positive values:

• secret_scanning_status = enabled

If any of these conditions are not met, the check will be considered as failed.

Reporting and Alerts

The alerts should be generated as a combination of organizational and repository-level compliance. For example:

1. Case 1: "The organization has not enabled secret scanning by default. 20 projects (45%) do not have the scanner enabled."
2. Case 2: "The organization has a proper configuration. 20 projects (45%) do not have the scanner enabled."
3. Case 3: "The organization has not enabled secret scanning by default. All projects have the secret scanner enabled."

[bjohansebas]

If no one else is working on this, I'm going to do it.