Acceso a la configuración del conjunto de reglas

1. Vaya al separador Valores del repositorio en GitHub.
2. En la barra lateral izquierda, en Reglas, haga clic en Reglas para acceder a la página de configuración de reglas.
3. Haga clic en el botón verde Nuevo RuleSet rama
4. Añada la información necesaria para definir el conjunto de reglas y haga clic en Crear.

Añadir reglas de protección en Rulesets

Al hacer clic en el botón verde New Branch RuleSet, aparece una página para rellenar los detalles del conjunto de reglas.

1. Asigne un nombre a RuleSet y active/desactive/evalúe el conjunto de reglas seleccionándolo en el menú desplegable Estado de activación

2. Configure las ramas de destino haciendo clic en Añadir destino. Seleccione Incluir**, Excluir****, Predeterminado** o Todos para configurar los criterios de selección de sucursales. GitHub admite la sintaxis fnmatch para la orientación basada en patrones.

3. Configure los permisos de bypass en la lista de bypass haciendo clic en Añadir bypass. Puede añadir las funciones necesarias que pueden eludir las comprobaciones. Puede dejar la lista vacía (esto equivale a activar No permitir eludir estos ajustes en los ajustes tradicionales de protección de la Rama).

4. Active la opción Requerir un pull request antes de fusionar en Reglas de rama.

5. Habilite la opción Requerir aprobaciones y establezca el Número necesario de aprobaciones antes de fusionar establecido en al menos 1 o el número de aprobaciones necesarias en el equipo.

6. Habilite la opción Descartar aprobaciones de solicitudes de extracción obsoletas cuando se envíen nuevas confirmaciones para revisar todos los cambios más recientes antes de que se puedan fusionar en otra rama.

Limitación

Actualmente, la lista de actores de bypass sólo puede recuperarse de los conjuntos de reglas a nivel de repositorio. Si se define un conjunto de reglas a nivel de la organización, esta información no se puede recuperar de esos conjuntos de reglas, bajo los permisos estándar.

Para recuperar la lista de actores de derivación de los conjuntos de reglas a nivel de organización, revise el acceso necesario y conceda privilegios elevados (acceso de propietario a la organización ) a la cuenta Functional ID/GitHub que ejecuta la canalización. Esto se debe al modelo de permisos GitHub's, que restringe la visibilidad de los metadatos de los actores que omiten las reglas del nivel de organización sin la autorización adecuada para evitar la fuga de información confidencial.

Para más información, consulte la documentación oficial de GitHub sobre conjuntos de reglas de organización y actores de bypass.

Configuración de comprobaciones de estado para el conjunto de reglas

1. Habilite la opción Require status checks to pass before merging.

Para poder establecerlos como comprobaciones de estado necesarias, primero debe desencadenar un conducto PR/CI de antemano (sólo se listan las comprobaciones de estado existentes en la interfaz de usuario).

Después de habilitar la opción Require status checks to pass before merging, debe configurar las comprobaciones de estado específicas que deben pasar antes de fusionar una solicitud de extracción.

2. En la lista de comprobaciones de estado disponibles, habilite las opciones siguientes para comprobaciones:

• tekton/code-branch-protection
• tekton/code-cis-check
• tekton/code-detect-secrets
• tekton/code-unit-tests
• tekton/code-vulnerability-scan

Estas comprobaciones son las que se esperan por defecto en el pipeline.

Añadir todas las reglas predeterminadas (configuración completa)

Este comando CURL configura tanto las comprobaciones de estado requeridas por defecto como los ajustes de revisión de las solicitudes pull.

curl -H "Authorization: Bearer $(cat ${APP_TOKEN_PATH})" "${APP_API_URL}/repos/${APP_REPO_OWNER}/${APP_REPO_NAME}/rulesets" \
    -XPUT -d '{
  "name": "Branch Protection Equivalent Ruleset",
  "target": "branch",
  "enforcement": "active",
  "bypass_actors": [], // as the list is empty no one can bypass which is equivalent to enforce_admins: true with no restriction
  "conditions": {
    "ref_name": {
      "include": ["refs/heads/master"],
      "exclude": []
    }
  },
  "rules": [
    {
      "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": true,
        "required_status_checks": [
          {
            "context": "tekton/code-unit-tests"
          },
          {
            "context": "tekton/code-branch-protection"
          },
          {
            "context": "tekton/code-cis-check"
          },
          {
            "context": "tekton/code-vulnerability-scan"
          },
          {
            "context": "tekton/code-detect-secrets"
          }
        ]
      }
    },
    {
      "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": false,
        "require_last_push_approval": false,
        "required_review_thread_resolution": false
      }
    }
  ]
}'

Acceso a los valores de protección de ramificación

1. Vaya al separador Valores del repositorio en GitHub.
2. En la barra lateral izquierda, pulse Ramas para acceder a la página de valores de rama.
3. Desplácese hacia abajo hasta la sección Reglas de protección de ramificación.
4. Localice la rama que desea configurar (normalmente la rama "principal").
5. Seleccione el botón Editar situado junto al nombre de la rama para modificar sus reglas de protección.

Adición de reglas de protección de ramificación

Si no hay reglas existentes configuradas, pulse el botón Añadir regla y especifique el nombre de rama correspondiente en el campo **Branch name pattern**. A continuación, siga los siguientes pasos:

1. Habilite la opción Requerir una solicitud de extracción antes de fusionar.
2. Habilite la opción Requerir aprobaciones y establezca el Número necesario de aprobaciones antes de fusionar establecido en al menos 1 o el número de aprobaciones necesarias en el equipo.
3. Habilite la opción Descartar aprobaciones de solicitudes de extracción obsoletas cuando se envíen nuevas confirmaciones para revisar todos los cambios más recientes antes de que se puedan fusionar en otra rama.

4. Active la opción No permitir la omisión de la configuración para evitar que los administradores y los roles personalizados con el permiso de omisión de protecciones de rama omitan las comprobaciones de protección de rama necesarias.

Actualmente, las advertencias aparecen en los registros si la comprobación de Do not allow bypassing these settings no está activada. No suspenderá el control de protección de las sucursales hasta que el control sea obligatorio a mediados de marzo. Le rogamos que active la comprobación antes de mediados de marzo para evitar fallos en las tuberías.

Las solicitudes de extracción deben aprobarse antes de fusionarlas en la rama maestra. Esta regla garantiza que los cambios se sometan a revisión y escrutinio por parte de los miembros del equipo, promueve la colaboración, la calidad del código y el cumplimiento de los estándares del proyecto.

Configuración de comprobaciones de estado

Se requieren verificaciones de estado enDevSecOps para hacer cumplir un conjunto integral de medidas de calidad y seguridad en el código. Esto garantiza que los cambios de código sean seguros y fiables antes de que se fusionen en una rama protegida. Al requerir que las comprobaciones de estado pasen antes de la fusión, puede evitar que el código roto o no probado se despliegue en producción.

Cuando se envía una solicitud de extracción, el conducto PR/CI desencadena automáticamente una serie de pruebas, validaciones y otras comprobaciones para verificar los cambios propuestos.

Sólo cuando todas las comprobaciones de estado necesarias pasen correctamente, la solicitud de extracción se considerará apta para fusionarse en la rama protegida.

Aprovechando las comprobaciones de estado dentroDevSecOps, puede mantener la calidad del código, cumplir con los estándares de codificación y garantizar la ausencia de vulnerabilidades o fallas críticas antes de incorporar cambios en la rama protegida de su proyecto.

Para obtener más información sobre la configuración de comprobaciones de estado, consulte la sección Configuración sólo de comprobaciones de estado(Configuración de comprobaciones de estado) para obtener una implementación de referencia.

1. Habilite la opción Require status checks to pass before merging.

Para poder establecerlos como comprobaciones de estado necesarias, primero debe desencadenar un conducto PR/CI de antemano (sólo se listan las comprobaciones de estado existentes en la interfaz de usuario).

Después de habilitar la opción Require status checks to pass before merging, debe configurar las comprobaciones de estado específicas que deben pasar antes de fusionar una solicitud de extracción.

2. En la lista de comprobaciones de estado disponibles, habilite las opciones siguientes para comprobaciones:

• tekton/code-branch-protection
• tekton/code-cis-check
• tekton/code-detect-secrets
• tekton/code-unit-tests
• tekton/code-vulnerability-scan

Las comprobaciones de estado mostradas deben pasar antes de fusionar una solicitud de extracción.

Estas comprobaciones son las que se esperan por defecto en el pipeline.

[{
  "type": "branch-protection",
  "name": "code-review",
  "params": {
    "checks": [
      "tekton/code-branch-protection",
      "tekton/code-unit-tests",
      "tekton/code-cis-check",
      "tekton/code-vulnerability-scan",
      "tekton/code-detect-secrets"
    ]
  }
}]

Valores opcionales

Además de los valores anteriores, tiene la opción de configurar los siguientes valores adicionales para las reglas de protección de ramificación. Tenga en cuenta que las comprobaciones de estado proporcionadas porDevSecOps no validará ni aplicará estas configuraciones.

• Requerir confirmaciones firmadas: este valor requiere que se firmen todas las confirmaciones en la rama protegida, evitando que se realicen cambios maliciosos en el código.

• Requerir historial lineal: este valor requiere que todas las confirmaciones en la rama protegida tengan un historial lineal. Esto significa que cualquier solicitud de extracción fusionada en la rama protegida debe utilizar una fusión de squash o una fusión de cambio de base. Un historial de confirmación estrictamente lineal puede ayudar a los equipos a invertir los cambios más fácilmente.

Estos valores adicionales son opcionales y se pueden personalizar en función de sus requisitos y preferencias específicos.

Adición de todas las reglas de protección de ramificación (configuración completa)

Las reglas de protección de ramificaciones también se pueden establecer mediante el siguiente mandato curl, después de sustituir las variables $GH_TOKEN, $OWNER, $APP_API_URL $REPO, $BRANCH.

curl -u ":$GH_TOKEN" $APP_API_URL/repos/$OWNER/$REPO/branches/$BRANCH/protection -XPUT -d '{"required_pull_request_reviews":{"dismiss_stale_reviews":true},"required_status_checks":{"strict":true,"contexts":["tekton/code-branch-protection","tekton/code-unit-tests","tekton/code-cis-check","tekton/code-vulnerability-scan","tekton/code-detect-secrets"]},"enforce_admins":null,"restrictions":null}'

Este mandato CURL configura tanto las comprobaciones de estado necesarias como los valores de revisión de solicitud de extracción.

Una vez que se hayan configurado estos valores, cualquier intento de fusionar una solicitud de extracción con $BRANCH se rechazará a menos que la solicitud de extracción haya sido aprobada por al menos otro usuario.

Configuración sólo de comprobaciones de estado (Configuración de comprobaciones de estado)

Si sólo desea configurar las comprobaciones de estado necesarias, puede utilizar el siguiente mandato CURL como referencia:

curl -H "Authorization: Bearer $(cat ${APP_TOKEN_PATH})" "${APP_API_URL}/repos/${APP_REPO_OWNER}/${APP_REPO_NAME}/branches/master/protection" \
    -XPUT -d '{"required_pull_request_reviews":{"dismiss_stale_reviews":true},"required_status_checks":{"strict":true,"contexts":["tekton/code-branch-protection","tekton/code-unit-tests","tekton/code-cis-check","tekton/code-vulnerability-scan","tekton/code-detect-secrets"]},"enforce_admins":null,"restrictions":null}'

En nuestra implementación de referencia, ya hemos proporcionado una configuración de ejemplo para el repositorio hello-compliance-app, para que pueda utilizarlo como punto de partida y personalizarlo según sus necesidades.

Siga el ejemplo anterior para garantizar la calidad del código y el cumplimiento de las medidas de seguridad para el repositorio. Para asegurarse de que esto sucede, configure las reglas de protección de ramificación y las comprobaciones de estado necesarias.