Puertas de políticas: detenga las vulnerabilidades antes de producción

Por qué las alertas no bastan

La mayoría de las herramientas de seguridad informan a posteriori. Un hallazgo aparece en un panel, alguien hace el triaje, un ticket llega al equipo responsable y, mientras tanto, la versión sigue avanzando. Si el hallazgo pasó desapercibido o el escaneo nunca vio el paquete, la vulnerabilidad está en producción antes de que nadie decida nada.

Las puertas de políticas también pueden detener un build en tiempo real, antes de que la versión siga adelante.

Qué puede detener una puerta

Regla	Qué ocurre
Hallazgos en el build	Se bloquea un build con hallazgos que su política descarta.
Una CVE concreta	Una vez que su equipo decide que una CVE no debe distribuirse, se bloquean los builds que la contienen.
Una versión maliciosa conocida	Una versión maliciosa con una CVE publicada, como xz, se señala y puede bloquearse del mismo modo.
Una licencia	Las reglas de política de licencias pueden bloquear un build que incorpore una licencia que usted ha descartado.

Una puerta vale tanto como lo que ve

Una puerta basada en el escaneo de un lockfile solo puede bloquear lo que el lockfile enumera. CRACI ve el tráfico que entra en cada build, de modo que sus puertas trabajan a partir de lo que el job descargó realmente:

• Dependencias transitivas a cualquier profundidad. Consulte dependencias transitivas.
• Dependencias ocultas, como el código que descargan los scripts de instalación, los scripts de build de Rust que descargan durante el build y la imagen base de un build de contenedor.
• Paquetes restaurados desde una caché de CI, que se registran y se marcan como procedentes de caché.

Todos los componentes de una SBOM de CRACI estaban en el build, así que una puerta nunca trabaja a partir de un paquete solo deducido. Para conocer el razonamiento, consulte SBOM generadas durante el build.

Las puertas y la política de salida cumplen funciones distintas

Riesgo	Qué lo detiene
Una dependencia con una CVE conocida que usted ha descartado	Puerta de políticas
Una licencia que usted ha descartado	Puerta de políticas
Una conexión a un host que el build no necesita	Política de salida, configurada en denegación por defecto
Un paquete malicioso nuevo sin aviso todavía	No se señala hasta que exista un aviso. Aun así, una política de salida configurada con denegación por defecto le impide enviar sus secretos a un host que el build no necesita.

Cuando aparece una nueva CVE

1. CRACI reevalúa las SBOM monitorizadas y señala lo que está afectado.
2. Su equipo de seguridad hace el triaje y la envía al equipo responsable de la corrección.
3. El historial de builds muestra qué builds la contenían y, por tanto, cuánto tiempo estuvo afectado.
4. El equipo responsable distribuye la corrección, y una puerta de políticas mantiene la CVE fuera de los builds posteriores.

La corrección sigue siendo cosa suya. La puerta se asegura de que el problema no vuelva. Consulte seguimiento de vulnerabilidades.

Lo que las puertas no hacen

• Sin análisis de alcanzabilidad. Una puerta trabaja a partir de si un paquete está en el build, no de si su código invoca la función vulnerable.
• Sin detección de malware. La puerta se basa en los avisos, así que no detecta un paquete malicioso completamente nuevo.
• Sin escaneo de código. El SAST y el escaneo de secretos quedan fuera del alcance por diseño, y hay muchas herramientas excelentes que funcionan junto a CRACI.

Puertas de políticas: preguntas frecuentes

¿Qué es una puerta de políticas?

Una regla que detiene un build cuando incumple su política. En lugar de notificar un problema para que alguien lo retome más tarde, la puerta impide que el build siga adelante.

¿En qué se diferencia una puerta de políticas de una alerta de un escáner?

Una alerta depende de que alguien actúe a tiempo. Una puerta actúa por sí sola. Además, las puertas de CRACI trabajan a partir de un registro de lo que descargó el build, de modo que pueden detectar paquetes que el escaneo de un lockfile nunca vería.

¿Puedo bloquear una CVE concreta?

Sí. Una puerta de políticas puede bloquear los builds que contienen una CVE concreta, para que una vulnerabilidad sobre la que su equipo ya ha decidido no vuelva en un build posterior.

¿Puede una puerta bloquear una licencia?

Sí. Cada paquete registrado lleva su licencia declarada, y las reglas de política de licencias pueden bloquear un build por una licencia.

¿Detiene una puerta el malware nuevo?

Por sí sola, no. Una versión maliciosa conocida con una CVE publicada se señala como cualquier otra vulnerabilidad, y una puerta puede bloquear los builds que la contienen. Un paquete malicioso nuevo no se señala hasta que exista un aviso. Lo que limita el daño en ese intervalo es una política de salida configurada con denegación por defecto.

¿Qué sistemas de CI funcionan con las puertas de políticas?

GitHub Actions, en runners de CRACI. Otros sistemas de CI están en la hoja de ruta.