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.
En las reglas de Dependency Vulnerability que se aplican a CI, limita el bloqueo a las dependencias cuyo código vulnerable es realmente alcanzable desde tu aplicación, de modo que los paquetes sin usar o no alcanzables no hagan fallar tu pipeline.
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
  • Opcionalmente, limita por alcanzabilidad (solo reglas de CI)
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.Las reglas de pull request solo publican comentarios sobre hallazgos que requieren una acción. Corgea omite los comentarios de hallazgos confirmados como no alcanzables, hallazgos retenidos por ser falsos positivos o resultados de lenguajes no compatibles, y hallazgos en rutas ignoradas por el proyecto. Estos hallazgos siguen disponibles en Corgea para revisarlos, pero no bloquean la pull request.
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. Si la regla se aplica a CI, también puedes seleccionar uno o más estados de Alcanzabilidad para limitarla aún más; consulta Filtrado por alcanzabilidad.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.

​
Filtrado por alcanzabilidad

En la mayoría de los proyectos, casi ninguna dependencia vulnerable se ejecuta realmente desde tu código. El filtrado por alcanzabilidad permite que una regla de Dependency Vulnerability bloquee solo los hallazgos que importan, de modo que una CVE crítica en un paquete que nunca invocas no haga fallar tu pipeline.
Solo disponible para reglas de CI La alcanzabilidad se analiza en los escaneos que inicias tú mismo con corgea scan, no en los que se activan automáticamente al abrir una pull request. Configura Applies To como CI para usar este filtro; la opción está oculta en las reglas de Pull Request. Después, referencia la regla desde tu pipeline con corgea scan --block-on <slug>.
Requisito previo La alcanzabilidad requiere que AI-Native SCA esté habilitado en tu organización. Sin esa opción no se analiza ninguna dependencia, por lo que una regla que use este filtro nunca bloqueará nada. El editor de reglas te avisa cuando la opción está desactivada.
Add Blocking Rule modal with CI and Dependency Vulnerability selected and Reachable checked under Reachability
Selecciona uno o más de los siguientes estados: El filtro de alcanzabilidad se combina con el filtro de gravedad, CVSS o Malicious en lugar de sustituirlo, por lo que un hallazgo debe coincidir con ambos. Una regla configurada con gravedad Critical y Reachable bloquea únicamente las vulnerabilidades críticas que además son alcanzables. Dejar la alcanzabilidad vacía mantiene el comportamiento actual de la regla, que bloquea con independencia de la alcanzabilidad.

​
Espera del análisis

El análisis de alcanzabilidad se ejecuta después de que finalice el escaneo en sí, por lo que corgea scan sigue consultando hasta que termina en lugar de devolver un resultado de inmediato. El análisis finaliza una vez analizadas todas las dependencias directas, lo que normalmente tarda unos minutos y como máximo 30. Este filtro falla de forma permisiva. Si el análisis no puede completarse —se agota la ventana de 30 minutos, el análisis falla o AI-Native SCA está desactivado—, la regla no informa de ninguna violación en lugar de hacer fallar tu build. Un pipeline solo se bloquea por una alcanzabilidad que Corgea determinó realmente, nunca por un análisis ausente.
corgea scan falla de forma restrictiva al agotarse su propio plazo. Corgea CLI 1.13.0 y versiones posteriores permiten 35 minutos, holgadamente por encima de la ventana de análisis de 30 minutos. En una CLI anterior el plazo es de 15 minutos, que puede agotarse mientras Corgea sigue analizando y hacer fallar el pipeline. Actualiza la CLI o amplía el plazo con CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS:

​
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: Dependency Vulnerability — Se aplica a: CISelecciona los niveles de urgencia «Critical» y «High» y, a continuación, selecciona Reachable en Alcanzabilidad. La regla hace fallar un pipeline solo cuando una vulnerabilidad crítica o alta es alcanzable desde el código de tu aplicación, de modo que los paquetes sin usar o no alcanzables no interrumpan a los desarrolladores. Es una buena primera regla de alcanzabilidad, porque limita una regla de gravedad existente en lugar de ampliar lo que bloquea.
Tipo de regla: Dependency Vulnerability — Se aplica a: CISelecciona Unused Dependency en Alcanzabilidad por sí sola, sin filtro de gravedad ni de CVSS. La regla hace fallar un pipeline que introduce paquetes vulnerables que nada usa en el código, animando a los desarrolladores a eliminar la dependencia en lugar de actualizarla.
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
  • En las reglas de CI, añade un filtro de alcanzabilidad Reachable a una regla de gravedad existente para reducir el ruido sin debilitar la cobertura de las vulnerabilidades realmente explotables
  • 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