La vida de un pull request, con Musha en el medio.
Sigue un cambio desde que alguien lo abre hasta que se hace merge, y mira dónde entra Musha, qué ve y qué no.
- Tu equipo
Alguien abre un pull request
Nada cambia en cómo trabaja tu equipo.
- Tu CI
El job sube el código a Musha
Se identifica con un token de corta vida o una clave de solo-scan. Musha nunca entra al repositorio.
- Musha
Cuatro motores revisan lo que el PR agrega
Código, dependencias, infraestructura y secretos. Lo preexistente se marca como deuda, no como culpa del PR.
- Tu pull request
Un comentario con los hallazgos
Severidad, ubicación y qué corregir. Si algo supera tu umbral, el job falla y el merge se frena.
- Tu rama principal
Se corrige, o se hace merge
Lo que ya estaba en el backlog no frena. Lo nuevo y crítico, sí. Tú eliges el umbral.
Tu CI sube el código. Musha nunca entra a tu repositorio.
Agregas un job a tu pipeline, que Musha genera para tu plataforma. En cada pull request ese job envía el código, Musha lo analiza y responde en el mismo PR.
- Solo lo que cambia
- Se evalúa lo que el PR agrega. Lo que ya existía aparece como deuda técnica y no frena el cambio.
- Sin credenciales guardadas
- En GitHub y GitLab el job se identifica con un token de corta vida ligado a esa ejecución (OIDC). En Azure DevOps y Bitbucket, con una clave de solo-scan limitada al proyecto.
- El merge se frena solo
- Si hay hallazgos por encima del umbral que definiste, el job falla. Tu regla de rama hace el resto.
- Nunca en pushes sueltos
- El job corre solo en pull requests, a propósito. Un push sin PR no gasta cuota ni alimenta nada.
Lo que ya estaba en el repositorio también cuenta.
Una vulnerabilidad puede publicarse meses después de que una dependencia entró con un PR limpio. El scan completo la encuentra y la pone en tu backlog, sin que nadie toque el código.
- Conexión por OAuth
- Conectas tu proveedor de Git desde Musha y lo desconectas cuando quieras.
- Cadencia tuya
- Diaria o semanal. Sin cambios en tu CI. Opcionalmente, también en cada push con un webhook que tú configuras.
- Clona, escanea, borra
- El repositorio vive en un espacio temporal solo mientras dura el scan. Lo único que queda es la metadata de cada hallazgo.
- Un backlog con estado
- Cada hallazgo tiene severidad y estado. Lo que ya está en el backlog no vuelve a frenar tus pull requests.
Tú decides qué frena un merge.
La política vive en Musha y se aplica en el servidor. No hay nada que configurar en tu pipeline.
-
Eliges desde qué severidad se bloquea
Por defecto, solo lo crítico.
-
Lo que ya está en tu backlog no frena
Aparece como contexto en el comentario, no como bloqueo.
-
Puedes aceptar un riesgo en un PR
Queda registrado y deja de bloquear.
-
Bloquea también lo preexistente, si quieres
Para lo que aún no está en el backlog. Viene apagado.
Cuatro motores, en los dos caminos.
Misma escala de severidad y mismo formato de hallazgo para los cuatro.
-
Código fuente
Patrones inseguros en tu propio código.
-
Dependencias
Vulnerabilidades conocidas, con la versión que las corrige.
-
Infraestructura
Terraform, CloudFormation, Kubernetes, Helm y Dockerfiles.
-
Secretos
Claves y tokens en el código, con el valor redactado.
Preferimos decirlo antes.
-
No instala nada.
Ni agentes en tu infraestructura ni apps en tu organización de Git.
-
No guarda tu código.
En el PR scan nunca lo ve en tu repositorio; en el scan completo, el clon se borra al terminar.
-
No usa las credenciales que encuentra.
Las reporta, redactadas. Nunca llama a un servicio externo con ellas.
-
No reemplaza un pentest.
Es análisis automatizado; complementa el trabajo de una consultora.
Pon a Musha en el medio de tu próximo pull request.
14 días de prueba. Un job en tu CI y listo.