¿Qué son los webhooks?
Los webhooks permiten que Corgea envíe notificaciones HTTP en tiempo real a sistemas externos cuando se producen determinados eventos. En lugar de consultar continuamente la API para comprobar si hay novedades, el webhook envía los datos del evento al endpoint configurado en cuanto se produce.Beneficios clave
- Notificaciones en tiempo real: Recibe actualizaciones inmediatas cuando se detectan hallazgos de seguridad, cambia un estado o finaliza un escaneo
- Automatización: Inicia flujos de trabajo en herramientas externas como Slack, Zapier o aplicaciones personalizadas
- Eficiencia: No necesitas consultar la API; Corgea envía los datos cuando se producen los eventos
- Flexibilidad: Suscríbete solo a los eventos que te interesen y filtra por proyecto, estado o escaneo programado
- Fiabilidad: Los reintentos y el seguimiento de entregas integrados ayudan a que las notificaciones lleguen a su destino
Tipos de eventos compatibles
Corgea admite webhooks para los siguientes eventos: Eventos de hallazgos:issue.status_changed- Se activa cuando se actualiza el estado de un hallazgo (por ejemplo, abierto → corregido)issue.assigned- Se activa cuando se asigna un hallazgo a un miembro del equipo
sla.violation- Se activa cuando la tarea diaria de SLA encuentra uno o varios hallazgos de SAST o SCA que han superado su plazo de remediación o escalado (configurado por SLA en Gestión de SLA)
scan.started- Se activa cuando comienza un escaneo de seguridadscan.completed- Se activa cuando un escaneo termina con éxitoscan.failed- Se activa cuando un escaneo detecta un errorscheduled_scan.daily_report- Se activa cada día cuando finalizan los escaneos programados y resume los hallazgos nuevos de todas las ejecuciones de las últimas 24 horas. Consulta Notificaciones para ver el esquema del correo y del payload.
scan.started, scan.completed, scan.failed) incluyen data.message, un breve resumen en texto sin formato que puedes utilizar en Slack, Zapier u otras herramientas de mensajería. También incluyen los campos de triaje pull_request_id, scan_url, true_positive_count, project_name y status.En Slack Workflow Builder (Type = Slack y hooks.slack.com/triggers/...), Corgea aplana solo scan.started, scan.completed, scan.failed y webhook.test como claves de nivel superior. No asignes campos data.* anidados en Slack, ya que provocan un error HTTP 400. Los demás tipos de eventos del mismo webhook conservan el sobre anidado. Consulta Slack.user.login- Se activa cuando un usuario inicia sesión con éxitouser.login_failed- Se activa cuando falla un intento de inicio de sesión de usuario
Cómo funcionan los webhooks
Ciclo de vida de un webhook
Ocurre un evento
Se activa el webhook
Filtrado aplicado
Se construye el payload
Type = Slack y una URL con triggers/), Corgea aplana el cuerpo HTTP solo para scan.* y webhook.test; los demás eventos permanecen anidados.Solicitud HTTP POST
Lógica de reintentos
Entrega registrada
Estructura del payload
De forma predeterminada, los payloads de webhook siguen un sobre anidado estándar (Zapier y Other). Los eventos del ciclo de vida del escaneo incluyendata.message, además de los campos de triaje:
summary.total_issues cuenta todos los hallazgos no eliminados, incluidos los falsos positivos y los de calidad del código. true_positive_count es el recuento de triaje utilizado en message y en los filtros de eventos de escaneo.
true_positive_count cuenta los hallazgos de seguridad no eliminados que no son falsos positivos. Utiliza la misma lógica que la interfaz de escaneo: excluye status=false_positive, hold_reason=false_positive y detected_by=code-quality. El sufijo opcional (N with fixes) de los mensajes scan.completed solo cuenta las correcciones de esos hallazgos verdaderos positivos, no las de todos los hallazgos del escaneo.
Ejemplo de payload sla.violation (generado por la tarea diaria de Gestión de SLA):
sla.violation en Integraciones → Webhooks o adjunta un webhook desde el formulario de Gestión de SLA; los webhooks existentes se suscriben automáticamente.
Ejemplo de payload de scheduled_scan.daily_report:
scheduled_scan.daily_report utiliza el mismo sobre, pero tiene su propio esquema de data. Consulta Ejemplos de payloads para ver la referencia completa.Características de seguridad
Verificación de firma HMAC
Verificación de firma HMAC
- Corgea genera automáticamente una clave secreta cuando creas un webhook
- Cada solicitud incluye una cabecera
X-Corgea-Signaturecon un hash HMAC-SHA256 del payload - Verifica la firma con tu clave secreta para asegurarte de que el webhook procede de Corgea
Cabeceras personalizadas
Cabeceras personalizadas
- Incluir cabeceras requeridas por tu endpoint (por ejemplo, tokens de autenticación)
- Configura cabeceras personalizadas al crear el webhook
HTTPS Obligatorio
HTTPS Obligatorio
- Todas las URLs de webhooks deben usar HTTPS (solo en los puertos 443 u 80)
- Las URLs no deben incrustar credenciales en la URL
- Se rechazan los destinos que resuelven a direcciones privadas, loopback, link-local, reservadas o multicast (protección SSRF)
- Los operadores pueden restringir los hosts mediante la opción
WEBHOOK_ALLOWED_HOSTS
Lógica de reintento automático
- Intento inicial + 2 intentos = 3 intentos en total
- Retroceso exponencial: 2 segundos, 4 segundos entre intentos
- Tiempo fuera: 10 segundos por petición
- Pausa automática: Tras 10 fallos consecutivos, el webhook se pausa automáticamente
Cabeceras enviadas con cada webhook
Configurar un webhook

Requisitos previos
Configuración paso a paso
Ve a Integraciones
- Abre Integraciones en Corgea
- En Integraciones de automatización, abre Webhooks

Configurar ajustes básicos

- Nombre: Una etiqueta clara (por ejemplo, “Notificaciones de Slack” o “Alertas de escaneo de producción”)
- URL de Webhook: Tu endpoint HTTPS
- Tipo:
Slack— Slack Workflow Builder o Incoming WebhooksZapier— Zapier Catch HooksOther— endpoints personalizados
Suscríbete a los eventos

- Estado del hallazgo modificado
- Hallazgo asignado
- Violación del SLA (
sla.violation) - Escaneo iniciado / completado / fallido
- Inicio de sesión de usuario / Inicio de sesión fallido
- Informe diario de escaneos programados (
scheduled_scan.daily_report)
Configurar filtros (opcional)

scan.*)- Solo escaneos de pull request / merge request — omite los escaneos sin
pull_request_id - Solo escaneos completados con hallazgos verdaderos positivos — omite
scan.completedcuandotrue_positive_countes 0 (scan.failedyscan.startedno se ven afectados)
- Déjalo deshabilitado para recibir eventos de todos los proyectos
- Habilita el filtro para limitar el webhook a los proyectos seleccionados
- En
sla.violation, el webhook se activa si coincide algún proyecto del payload
issue.status_changed)- Dejar vacío para todos los cambios de estado
- O limitar a estados como
fixedofalse_positive
scan.* eventos)- Déjalo deshabilitado para recibir todos los escaneos, tanto manuales como programados
- Habilítalo para que solo se active con los escaneos programados seleccionados
Añadir cabeceras y cuerpo personalizados (opcional)
Jira Automation
Jira Automation
- En Jira, crea una regla de automatización con un disparador de “Webhook entrante”
- Copia el token secreto proporcionado por Jira
- Añádelo como valor de la cabecera en Corgea
Slack
Slack
https://hooks.slack.com/triggers/...). Con Type = Slack, Corgea aplana scan.* y webhook.test: asigna message, pull_request_id, scan_url, true_positive_count y company. No asignes campos data.* anidados (Slack devuelve HTTP 400). Los demás tipos de eventos no se aplanan. Consulta Slack.Los Incoming Webhooks (https://hooks.slack.com/services/...) necesitan un Custom Body cuyo JSON renderizado tenga una cadena text no vacía en el nivel superior. Utiliza {"text": "{{message}}"} solo con eventos del ciclo de vida del escaneo y scheduled_scan.daily_report.Microsoft Teams
Microsoft Teams
https://xxx.webhook.office.com/webhookb2/xxx/IncomingWebhook/xxxAPI personalizada con Bearer Token
API personalizada con Bearer Token
Splunk HEC
Splunk HEC
API personalizada con clave de API
API personalizada con clave de API
PagerDuty
PagerDuty
routing_key en el payload JSON para la autenticación.Utiliza el endpoint de la API de PagerDuty Events: https://events.pagerduty.com/v2/enqueueZapier
Zapier
- Puedes proporcionar una plantilla de objeto JSON para el cuerpo de la solicitud del webhook
- Déjala en blanco para utilizar la estructura de payload predeterminada de Corgea
- Variables compatibles:
{{payload}}(objeto completo del payload predeterminado){{time}}(segundos Unix){{timestamp}}(marca de tiempo ISO 8601){{event_type}}{{event_id}}{{message}}(dedata.messagecuando esté presente — ciclo de vida del escaneo e informe diario)
- Si la plantilla renderizada es JSON inválida, la entrega falla y el error aparece en el historial del webhook
Guardar y activar
- Haz clic en Crear Webhook
- Copia la clave secreta desde la ventana emergente — Corgea solo la muestra una vez

- Haz clic en He guardado la clave secreta
- El webhook está activo y empezará a recibir eventos
Prueba tu Webhook
- Abre el webhook y haz clic en Probar Webhook
- Confirma que tu endpoint devuelve una respuesta 2xx
- En Slack Workflow Builder, recibirás un cuerpo plano con un campo
messageno vacío en el nivel superior y claves de triaje de ejemplo (pull_request_id,scan_url,true_positive_count, etc.), que podrás asignar durante la prueba. No se admiten configuraciones exclusivas de Workflow Builder.
Verificar firmas de webhooks
X-Corgea-Signature de cada solicitud.- Python
- Node.js
Casos de uso
1. Notificaciones de Slack en tiempo real
Escenario: Notificar al equipo de seguridad en Slack cuando se detecten hallazgos de gravedad alta Preparación:- Crea una URL de webhook entrante de Slack en tu espacio de trabajo de Slack
- En Corgea, crea un webhook con:
- Tipo:
Slack - URL: Tu URL de webhook de Slack
- Eventos:
scan.completed - Filtro de Proyectos: Proyectos críticos de producción
- Tipo:
2. Creación automática de tickets para hallazgos críticos
Escenario: Crear automáticamente tickets en Jira o Linear cuando se detectan hallazgos críticos Preparación:- Crea un Zapier zap o un endpoint personalizado que genere tickets
- En Corgea, crea un webhook con:
- Eventos:
scan.completed,issue.status_changed - Filtro de estado: solo el estado
open(para evitar tickets duplicados) - Filtro de Proyectos: Proyectos de producción
- Eventos:
3. Integración del flujo de trabajo de aceptación de riesgos
Escenario: Documentar automáticamente en Jira o Linear los riesgos aceptados cuando los hallazgos de seguridad se marcan como “Riesgo Aceptado” Preparación:- Crea un endpoint o una integración con Zapier que genere tickets de documentación
- En Corgea, crea un webhook con:
- Eventos:
issue.status_changed - Filtro de estado: solo el estado
accepted_risk - Filtro de Proyectos: Todos los proyectos o proyectos específicos de alta conformidad
- Eventos:
- Configura la integración para:
- Crea un ticket que documente la aceptación del riesgo
- Incluye los detalles del hallazgo (clasificación, ruta del archivo y urgencia)
- Añade la etiqueta “aceptación de riesgos”
- Asigna el ticket al responsable de seguridad para que lo revise
4. Integración personalizada de paneles
Escenario: Muestra métricas de seguridad en tiempo real en tu panel interno Preparación:- Crea un endpoint que reciba datos de webhooks y actualice tu panel de control
- En Corgea, crea un webhook con:
- Eventos: Todos los eventos de escaneos y hallazgos
- Sin filtros (recibe todo)
5. Enrutamiento multiequipo
Escenario: Redirigir diferentes notificaciones de proyectos a distintos equipos Preparación:- Crea webhooks separados para cada equipo:
- Backend Team Webhook: Filtro de proyectos = proyectos de backend, canal de Slack #backend-seguridad
- Frontend Team Webhook: Filtro de proyectos = proyectos frontend, canal de Slack #frontend-seguridad
- DevOps Team Webhook: Filtro de proyectos = proyectos de infraestructura, canal de Slack #devops-seguridad
6. Informes de cumplimiento
Escenario: Registrar automáticamente todos los hallazgos de seguridad en un sistema de cumplimiento Preparación:- Crea un endpoint que escriba en tu base de datos de cumplimiento
- En Corgea, crea un webhook con:
- Eventos:
scan.completed - Todos los proyectos
- Almacena el historial de entregas de webhooks para las auditorías
- Eventos:
Resolución de problemas
Consultar el historial de entregas de webhooks
Ve al historial de webhooks

Abre el registro de entregas
Revisa los detalles de la entrega

- Tipo de evento y marca temporal
- Código de estado HTTP
- Detalles de solicitudes/respuestas
- Mensajes de error (si los hay)
- Intentos de reintento
Problemas habituales y soluciones
Webhook no recibe eventos
Webhook no recibe eventos
- El webhook está pausado o inactivo
- No se han configurado suscripciones a eventos
- Los filtros de proyecto, estado o escaneo programado excluyen los eventos
- El endpoint no devuelve códigos de estado 2xx
- Comprueba que el webhook esté activo y no se encuentre en pausa
- Comprueba que se hayan seleccionado las suscripciones a los eventos
- Revisa los filtros; para probar, elimina temporalmente los de proyecto, estado o escaneo programado
- Revisa los logs del endpoint para comprobar si recibe solicitudes
- Prueba el webhook usando el botón “Probar Webhook”
Webhook se pausó automáticamente
Webhook se pausó automáticamente
- Revisa los detalles de los errores en el historial de entregas
- Verifica que la URL de tu endpoint sea correcta y accesible
- Asegúrate de que tu endpoint devuelva códigos de estado 2xx
- Comprueba si alguna regla del firewall o de seguridad bloquea las solicitudes de Corgea
- Soluciona el problema subyacente y luego reactiva manualmente el webhook
- Utiliza “Test Webhook” para verificar que funciona antes de volver a activar
El webhook recibe demasiadas llamadas
El webhook recibe demasiadas llamadas
- Usar filtros de estado: Para
issue.status_changed, filtra a solo estados que te interesan (por ejemplo, solofixedyfalse_positive) - Utilizar filtros de proyectos: Solo suscríbete a proyectos críticos específicos
- Utilizar filtros de escaneos programados: En los eventos de escaneo, selecciona los escaneos programados que deben activar el webhook
- Reducir las suscripciones a eventos: Cancela la suscripción a los eventos que no necesites
- Limitar la tasa: Implementa rate limiting o una cola en el endpoint
Fallo en la verificación de firma
Fallo en la verificación de firma
- Clave secreta incorrecta
- Lógica incorrecta de verificación de firma
- Problemas de codificación de caracteres
- Verifica que estás usando la clave secreta exacta de Corgea
- Asegúrate de usar el algoritmo HMAC-SHA256
- Utiliza el cuerpo sin procesar de la solicitud, no el JSON parseado, para la verificación
- Comprueba la codificación UTF-8 en ambos lados
- Utiliza
hmac.compare_digest()(Python) ocrypto.timingSafeEqual()(Node.js) para realizar una comparación resistente a ataques de temporización
Timeout del endpoint
Timeout del endpoint
- Confirma la recepción de inmediato: Devuelve 200 OK inmediatamente y después procesa la solicitud de forma asíncrona
- Usa una cola: Añade los payloads de webhook a una cola para procesarlos en segundo plano
- Optimizar el procesamiento: Acelera la lógica de tu manejador de webhook
- Aumenta los recursos: Escala la infraestructura del endpoint
Eventos duplicados
Eventos duplicados
- Múltiples webhooks suscritos al mismo evento
- Lógica de reintento activándose tras un éxito retardado
- Comprueba si hay configuraciones de webhook duplicadas
- Utiliza el campo
event_idcomo clave de idempotencia: almacena los ID de los eventos procesados y omite los duplicados - Implementa claves de idempotencia en tu endpoint
Faltan datos en el payload
Faltan datos en el payload
- Consulta el payload completo en el historial de entregas del webhook
- Algunos campos pueden ser
nullsi no hay datos, por ejemplo en hallazgos sin asignar - Implementa comprobaciones de valores nulos en el código del handler
- Consulta en el historial de entregas la estructura del payload de cada evento
Consultar estadísticas de webhooks
Consulta métricas de rendimiento para tus webhooks:- Navega a Integraciones → Webhooks
- Consulta las estadísticas de cada webhook:
- Total de entregas: Número total de llamadas del webhook
- Entregas exitosas: Llamadas que devolvieron 2xx
- Entregas fallidas: Llamadas que fallaron o se agotaron
- Tasa de éxito: Porcentaje de entregas exitosas
- Fallos consecutivos: Racha actual de fallos
- Última activación: Momento en que el webhook se activó por última vez
Reintento manual
Si una entrega por webhook falló, puedes intentarlo manualmente:- Ve a Integraciones → Webhooks → Historial
- Encuentra la entrega fallida
- Haz clic Reintentar
- Se creará y enviará un nuevo intento de entrega inmediatamente
Exportar el historial de entregas
Para cumplimiento o depuración, exporta el historial de entrega de webhooks:- Ve a Integraciones → Webhooks → Historial
- Aplica los filtros necesarios (intervalo de fechas, tipo de evento, estado y webhook)
- Haz clic en Exportar para descargar CSV
- Utiliza la exportación para:
- Auditorías de cumplimiento
- Análisis de rendimiento
- Patrones de depuración
- Seguimiento de la resolución de problemas
Consejos para pruebas
Antes de salir en directo
Antes de salir en directo
- Utiliza webhook.site o RequestBin para inspeccionar los payloads
- Prueba primero con proyectos de bajo volumen
- Supervisa la tasa de éxito de las entregas durante los primeros días
- Configura alertas en tu sistema para los fallos del webhook
Lista de verificación de depuración
Lista de verificación de depuración
- La URL del webhook es correcta y accesible
- El endpoint devuelve el código de estado 2xx en 10 segundos
- El cortafuegos permite las solicitudes de Corgea
- Se seleccionan las suscripciones a los eventos
- Los filtros se configuran correctamente (o se eliminan para pruebas)
- La verificación de firma funciona (si se usa secreto)
- El webhook está activo y no está en pausa
Ejemplos de cargas útiles
- Cambio de estado del hallazgo
- Escaneo iniciado
- Escaneo completado
- Escaneo fallido
- Hallazgo asignado
- Violación del SLA
- Inicio de sesión de usuario
- Inicio de sesión de usuario fallido
- Informe Diario de Escaneo Programado
Preguntas frecuentes
¿Puedo usar la misma URL de webhook para varios tipos de eventos?
¿Puedo usar la misma URL de webhook para varios tipos de eventos?
X-Corgea-Event y el campo event_type para identificar el evento.¿Cuántos webhooks puedo crear?
¿Cuántos webhooks puedo crear?
¿Qué pasa si mi endpoint está caído?
¿Qué pasa si mi endpoint está caído?
¿Puedo probar los webhooks sin activar eventos reales?
¿Puedo probar los webhooks sin activar eventos reales?
message no vacío, además de las claves de triaje (pull_request_id, scan_url, true_positive_count, company). También incluye company_id, con el mismo valor, para los consumidores de Test antiguos.¿Puedo notificar solo en casos de fallos en el escaneo de PR o en escaneos completados con resultados?
¿Puedo notificar solo en casos de fallos en el escaneo de PR o en escaneos completados con resultados?
scan.failed y scan.completed. El filtro de hallazgos no se aplica a scan.failed.¿Los webhooks admiten autenticación?
¿Los webhooks admiten autenticación?
X-Corgea-Signature). También puedes añadir cabeceras personalizadas para los tokens de autenticación del destino.¿Puedo filtrar los webhooks para ramas específicas?
¿Puedo filtrar los webhooks para ramas específicas?
¿Están cifradas las cargas útiles de webhook?
¿Están cifradas las cargas útiles de webhook?
¿Cuánto tiempo se conservan los registros de entrega de webhook?
¿Cuánto tiempo se conservan los registros de entrega de webhook?
¿Puedo volver a intentar un webhook manualmente?
¿Puedo volver a intentar un webhook manualmente?
¿Desde qué direcciones IP envía Corgea los webhooks?
¿Desde qué direcciones IP envía Corgea los webhooks?
¿Tienes alguna pregunta o problema? Contacta con el soporte de Corgea.
