Are code check-ins gated by code collaborators and source control to prevent anyone from accidentally or intentionally submitting unreviewed code changes?

As part of a check-in process, once of the control is to allow no code that has not been peer or lead reviewed to be checked-in to a source control repository.

Reference: ESF - Securing the Software Supply Chain - Recommended practices for Developers - 2.2.1 Modification or Exploitation of Source Code by Insiders

Fundamental to the protection of the source code repository and its contents are the methods used to control access to it and the validation process used to ascertain whether a check-in is “good.” Access and validation start with good source code management (SCM) principles to track modifications to a source code repository.

The configuration specifies the minimal protection rules that must be enabled on the configured branches to pass this checkpoint:

Follow the instructions to add protected branches rules in GitHub, GitLab or BitBucket.

Please note that in certain special cases the rules may need to be suspended. For example, if a past commit includes illegal or critical content, it may be necessary to use a force push to rewrite the history rather than simply hide the commit.

For fetching certain protection rules for branches, this checkpoint may need administrative access to the target repository. If the access token provided does not have administrator role, and the associated protecting rule is required for the checkpoint, the checkpoint will not be given a "pass" state, as the status of protection rule cannot be determined.