Add Compliance check: `scanCommitsForSensitiveInfo`

[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]

Blocked until #143 is solved

[telekosmos]

#143 points also back here 😬 . The other references in #143, #67 and #68 are already closed, so I can pick this one.

Validation logic

I've notice this is quite similar to #67 and some checks can overlap as well and we can follow the logic at this comment.

And, after checking the link in the spreadsheet for this check and checking the available properties in both org and repo schemas, additionally to the checks given in the link above, we should check the following extra properties:

• organization level
  • secret_scanning_enabled_for_new_repositories
  • secret_scanning_push_protection_enabled_for_new_repositories (enable secret scanning on push for new repos)
• repo level
  • secret_scanning_status
  • secret_scanning_push_protection_status (enable secret scanning on push for the repo)
  • secret_scanning_non_provider_patterns_status (enable secret scanning even for secrets which don't have provider pattern)

If any of these conditions are not met, the check will be considered as failed. Conditions met means they have to set to enabled (as opposite to disabled or null).

Reporting

In a similar way as comented in #67, there will be a combination of cases depending on the values for organizations and the repos. Alerts should be generated as a combination, sending if any org or repo don't have the secret scanning in place.

[UlisesGascon]

Thanks for the deep research @telekosmos! It seems solid and aligned on what we have being doing so far... do you want to work on the implementation?