Skip to main content

​
Resumen

​
Qué hace

Las reglas de bloqueo son barreras de control que definen qué hallazgos deben hacer fallar una comprobación de pull request o un pipeline de CI. Así se garantiza que la base de código cumpla los estándares de seguridad y calidad de la organización. Puedes crear tres tipos de reglas de bloqueo:
  • Reglas de vulnerabilidades de código: Bloquean PR en función de las vulnerabilidades, los hallazgos de calidad del código o ambos
  • Reglas de vulnerabilidades de dependencias: Bloquean PR en función de las dependencias vulnerables detectadas mediante el escaneo de SCA
  • Reglas de License Compliance: Bloquean dependencias con licencias SPDX concretas o familias de licencias

​
Para quién es

Las reglas de bloqueo están diseñadas principalmente para:
  • Equipos de desarrollo
  • Gestores de proyecto
  • Profesionales de la seguridad
Esta función resulta especialmente útil para las organizaciones con requisitos normativos estrictos o que desarrollan aplicaciones críticas en las que la calidad y la seguridad son esenciales.

​
Características y beneficios principales

Define reglas basadas en categorías CWE para bloquear las pull requests que introduzcan determinados tipos de vulnerabilidades o problemas de calidad.
Asigna niveles de urgencia (por ejemplo, crítico, alto, medio, bajo) a diferentes tipos de problemas, permitiéndote priorizar y gestionarlos en consecuencia.
En las reglas de vulnerabilidades de dependencias, define un intervalo inclusivo de puntuaciones CVSS para bloquear las dependencias vulnerables que se encuentren dentro de él.
Bloquea dependencias por identificadores SPDX concretos o por las familias de licencias Copyleft, Permissive y Commercial.
Aplica reglas de bloqueo a proyectos específicos, etiquetas de proyecto o a toda tu organización, dándote un control detallado sobre qué proyectos están sujetos a qué reglas.
Crea, edita y elimina fácilmente las reglas de bloqueo a través de una interfaz fácil de usar, asegurando que tus normas se mantengan actualizadas con tus requisitos cambiantes.
Cambia el estado de las reglas para activarlas o desactivarlas temporalmente sin perder su configuración.

​
Tipos de reglas

Las reglas de bloqueo admiten tres tipos distintos para una cobertura de seguridad completa:

Code Vulnerability

Bloquea las pull requests basadas en vulnerabilidades de seguridad, hallazgos de calidad de código o ambos.Configuración:
  • Selecciona un tipo de hallazgo: All, Vulnerabilities o Code Quality
  • Selecciona categorías CWE concretas
  • Establece niveles de urgencia o gravedad
Utilízalo para evitar problemas como la inyección SQL, XSS, criptografía insegura y otras vulnerabilidades a nivel de código.

Dependency Vulnerability

Bloquea pull requests en función de las dependencias vulnerables detectadas mediante el análisis de composición de software (SCA).Configuración:
  • Establece niveles de urgencia o gravedad (Critical, High, Medium, Low)
  • O bien establece un intervalo inclusivo de puntuaciones CVSS entre 0,0 y 10,0
Utiliza esto para evitar la introducción de paquetes con vulnerabilidades de seguridad conocidas, asegurando que tu cadena de suministro siga siendo segura.

License Compliance

Bloquea pull requests o pipelines de CI cuando una dependencia usa una licencia denegada.Configuración:
  • Selecciona una o más familias de licencias: Copyleft, Permissive o Commercial
  • Introduce identificadores SPDX concretos, como AGPL-3.0
Úsalo para aplicar la política de licencias open source y comerciales de tu organización.

​
Cómo funciona con GitHub

Requisito previo: Debes haber instalado y configurado la aplicación de GitHub de Corgea con los permisos necesarios en el repositorio.
1

Envío de pull requests

El desarrollador envía una pull request con cambios en el código
2

Análisis automatizado

El sistema analiza los cambios según las reglas de bloqueo activas
3

Validación de reglas

Si se detectan infracciones, la pull request se bloquea automáticamente
4

Notificación al desarrollador

El desarrollador recibe información detallada sobre las infracciones de las reglas
5

Resolución

El desarrollador debe corregir las infracciones y marcarlas como Fixed, o como False Positive o Accepted Risk antes de permitir la fusión

​
Cómo funciona con Azure DevOps

Requisito previo: Asegúrate de que la integración de Azure DevOps con Corgea esté configurada y de que tengas los permisos necesarios.
1

Envío de pull requests

Un desarrollador envía una pull request con cambios de código en Azure DevOps.
2

Análisis automatizado

El sistema evalúa los cambios según las reglas de bloqueo activas configuradas en Corgea.
3

Validación de reglas

Si se detectan infracciones, la pull request se bloquea automáticamente.
El desarrollador no puede fusionar la PR hasta que se resuelva.
4

Notificación al desarrollador

El desarrollador recibe un enlace a la página del escaneo de Corgea con información detallada sobre los hallazgos que han provocado el fallo.
5

Resolución

El desarrollador debe resolver las infracciones corrigiéndolas o marcándolas como False Positive o Accepted Risk antes de que la fusión pueda continuar.

​
Guía de uso

​
Creación de una nueva regla de bloqueo

1

Iniciar la creación

Haz clic en el botón “Add Blocking Rule”
2

Elegir tipo de regla

Selecciona el tipo de regla:
  • Code Vulnerability: Bloquea pull requests según los hallazgos de SAST
  • Dependency Vulnerability: Bloquea pull requests según los hallazgos de SCA
  • License Compliance: Bloquea dependencias según licencias SPDX denegadas o familias de licencias
Add Blocking Rule modal with Applies To, rule types, and Issue Type
3

Información básica

Introduce el nombre y la descripción de la regla y elige Applies To:
  • Pull Requests aplica automáticamente la regla en las comprobaciones de pull request.
  • CI aplica la regla solo cuando un pipeline la nombra con corgea scan --block-on <slug>. Las reglas de CI no bloquean pull requests.
Las reglas nuevas usan Pull Requests por defecto. Corgea genera el slug a partir del nombre de la regla y lo muestra en la lista de reglas.
Add Blocking Rule modal with CI selected and License Compliance configured
4

Configurar ajustes

Para las reglas de Code Vulnerability, elige un Issue Type para aplicarlas a All los hallazgos, solo a Vulnerabilities o solo a los hallazgos de Code Quality. All es el valor predeterminado y conserva el comportamiento de las reglas existentes. Después, selecciona niveles de urgencia (Critical, High, Medium o Low), categorías CWE o ambas opciones. Debes definir al menos una para que la regla sea válida.Para las reglas de Dependency Vulnerability: Elige si filtrar por gravedad o por puntuación CVSS. Selecciona los niveles de urgencia (Critical, High, Medium o Low), o introduce una puntuación CVSS mínima y máxima de 0,0 a 10,0 para bloquear dependencias vulnerables dentro de ese rango inclusivo.Para las reglas de License Compliance: Selecciona al menos una familia de licencias denegada (Copyleft, Permissive o Commercial) o introduce uno o más identificadores SPDX. Una dependencia se bloquea cuando alguna licencia notificada coincide con una familia seleccionada o con un ID concreto.
5

Definir el ámbito

Selecciona proyectos, etiquetas de proyecto o ambas opciones. La regla se aplica a los proyectos seleccionados directamente o que tengan alguna de las etiquetas seleccionadas. Si no eliges ningún proyecto ni etiqueta, se aplica a todos los proyectos.
6

Guardar

Revisa y haz clic en “Create”

​
Gestión de las reglas existentes

Usa la búsqueda para encontrar reglas por nombre o configuración, o filtra la lista por etiqueta de proyecto o por el destino de Applies To. La tabla de reglas muestra el slug de cada regla en la columna ID y presenta el alcance del proyecto, el tipo de regla y el destino Pull Requests o CI en Triggers On. Selecciona un slug para copiarlo y usarlo en un comando de CI. Las reglas sin alcance de proyecto o etiqueta se aplican a todos los proyectos, y las listas de alcance más largas se agrupan detrás de un tooltip +N more.
Blocking rules list showing slug, Triggers On chips, and CI badge

​
Aplicar reglas en CI

Crea una regla activa con Applies To establecido en CI y pasa su slug al comando de escaneo. Nombra las reglas según la condición que las dispara — por ejemplo criticals, no no-criticals — para que --block-on se lea como una afirmación directa. --block-on requiere Corgea CLI 1.10.0 o posterior.
Para aplicar varias reglas de CI, proporciona sus slugs como una lista separada por comas. El comando falla cuando un hallazgo incumple cualquiera de las reglas nombradas. Un slug desconocido, una regla inactiva o una regla que se aplica a pull requests se tratan como error de configuración y no se omiten. --block-on solo es compatible con el escáner BLAST y no se puede combinar con --fail ni --fail-on.
  1. Localiza la regla en la tabla
  2. Haz clic en “Edit”
  3. Modifica la configuración según sea necesario
  4. Haz clic en “Update” para guardar

​
Consultar las reglas aplicadas a los escaneos

Puedes ver las reglas de bloqueo que se aplican a tus escaneos en dos lugares:
  1. En la página de detalles del escaneo, verás una sección de “Blocking Rules” que muestra todas las reglas evaluadas:
  1. En cada hallazgo, puedes consultar las reglas de bloqueo activadas desde la vista de detalles:
Esto permite saber qué reglas afectan a cada escaneo y hallazgo, y por qué se han bloqueado determinados cambios.

​
Ejemplos

Tipo de regla: Code VulnerabilityCrea una regla para CWE-326 (Inadequate Encryption Strength) y CWE-327 (Use of a Broken or Risky Cryptographic Algorithm), con urgencia “Critical”, para impedir el uso de cifrado débil.
Tipo de regla: Code VulnerabilitySelecciona Code Quality como tipo de hallazgo. Después, crea una regla para CWE-398 (Indicator of Poor Code Quality) y CWE-477 (Use of Obsolete Functions), con urgencia “Medium”, para mantener los estándares del código.
Tipo de regla: Dependency VulnerabilityCrea una regla con los niveles de urgencia “Critical” y “High” seleccionados para bloquear automáticamente cualquier pull request que introduzca dependencias con vulnerabilidades críticas o de alta gravedad. Esto garantiza que tu cadena de suministro siga siendo segura y evita que los paquetes vulnerables conocidos entren en tu base de código.
Tipo de regla: Dependency VulnerabilityCrea una regla que filtre por puntuación CVSS, como de 7.0 a 10.0, para bloquear las pull requests que introducen dependencias vulnerables dentro de ese rango de puntuación.
Tipo de regla: License ComplianceSelecciona la familia Copyleft para bloquear dependencias cuyas licencias notificadas pertenecen a esa familia. Añade identificadores SPDX concretos cuando tu política necesite una lista de denegación más estrecha.

​
Mejores prácticas

Consejos de implementación

  • Empieza con las reglas esenciales y ve ampliando poco a poco
  • Para reglas de Dependency Vulnerability, comienza solo con gravedad Critical o un rango CVSS enfocado, y luego amplía a medida que tu equipo se ajuste
  • Para reglas de Code Vulnerability, céntrate primero en los CWEs más impactantes (por ejemplo, fallos de inyección, problemas de autenticación)
  • Revisión y actualizaciones periódicas
  • Documentación clara y formación del equipo
  • Fomenta los comentarios y la colaboración
  • Uso estratégico de los niveles de urgencia
  • Considera las etiquetas de proyecto cuando la misma regla debería cubrir un grupo de proyectos relacionados

​
Resolución de problemas

Si una pull request se bloquea inesperadamente, verifica primero las reglas activas y sus configuraciones.
  • Comportamiento inesperado de bloqueo
  • Problemas de segmentación de reglas
  • Problemas en el alcance del proyecto
  • Comprobar las configuraciones de las reglas
  • Verificar la orientación de CWE
  • Confirmar la configuración del proyecto
  • Contactar con el soporte si es necesario