Política de seguridad, como código.
Escribe tu nivel de seguridad una vez y cada escaneo, equipo y pipeline lo cumple.
policy.yamlOrganizaciónAplicada
- BloquearHallazgos SAST críticos
- BloquearInyección SQL en una rama protegida
- AvisarCVSS 7.0 o más
- ExcluidoInformes legacy, riesgo aceptado
Escrita una vez. Aplicada en cada merge.
policy.yamlevaluado en cada análisis
name: Block Critical Vulnerabilitiesscope: ORGANIZATIONpriority: 50enabled: truerules: - name: Block Critical SAST Findings action: block criteria: - scanner_type eq SAST - severity eq CRITICALDefine las reglas una vez, heredadas en todas partes.
La línea base de tu organización llega a cada equipo y a cada proyecto. Un proyecto puede endurecerla, nunca relajarla.
AcmeOrganización
Block Critical Vulnerabilitiesseverity eq CRITICAL → block- PaymentsEquipoheredada
payments-apiheredadacheckout-webheredada+ severity eq HIGH → blockmás estricta, nunca más laxa
- PlatformEquipoheredada
infraheredadadocs-siteheredada
Empieza por un repositorio.
Conecta GitHub, GitLab, Bitbucket o Azure DevOps, elige un repositorio y el primer escaneo arranca.
En detalle
Lo que una regla puede decir
Escribe la regla. Bloquea el merge. Registra la excepción.
10 tipos de regla, 8 operadores, lógica AND / OR. Desde un simple umbral de CVSS hasta un CWE concreto en una rama protegida.
policy.yamlOrganizaciónAplicada
- BloquearHallazgos SAST críticosscanner_type eq SASTAND severity eq CRITICAL
- BloquearInyección SQL en una rama protegidaCWE-89AND main
- AvisarCVSS 7.0 o másCVSS 4.0
- ExcluidoInformes legacy, riesgo aceptadolegacy/reports/**2026-12-31
10 tipos de regla, 8 operadores, lógica AND / OR. Desde un simple umbral de CVSS hasta un CWE concreto en una rama protegida.
Gestión de políticas, en resumen
¿Qué es la política de seguridad como código?
Tus requisitos de seguridad viven como YAML bajo control de versiones, junto a tu código. CybeDefend evalúa la política vigente en cada análisis de SAST, SCA, secretos, contenedores, IaC y CI/CD, de modo que las reglas viajan con el repositorio.
¿Cuál es la diferencia entre bloquear y avisar?
Bloquear detiene el pipeline y registra la infracción. Avisar la registra y deja que el pipeline continúe, que es la forma segura de introducir una regla nueva antes de hacerla obligatoria.
¿Cómo funciona la jerarquía de organización, equipo y proyecto?
Las políticas bajan en cascada. La organización fija una línea base que equipos y proyectos heredan y solo pueden endurecer, así que ninguna directriz de la empresa se anula en silencio.
¿La evaluación de políticas ralentiza mi pipeline?
No. Las políticas se evalúan de forma asíncrona, con un tiempo de espera configurable, así que la barrera nunca frena los análisis ni los despliegues.
¿Puedo hacer una excepción para un archivo o un riesgo aceptado?
Sí. Cada política admite exclusiones acotadas por patrones glob con fechas de caducidad opcionales, y puedes marcar un hallazgo como riesgo aceptado con una justificación. Ambas dejan rastro de auditoría.