Por qué snyk test debería ser tan rutinario como git commit

Un defecto de seguridad detectado en diseño toma minutos corregirlo. El mismo defecto detectado en producción puede tomar semanas, disparar una violación de compliance, y exponer datos de usuarios antes de que alguien se entere. Según el NIST, arreglar un defecto en producción cuesta entre 30 y 100 veces más que arreglarlo durante la codificación. IBM llegó a una cifra similar: una vulnerabilidad que cuesta 500 dólares corregir mientras se escribe el código puede superar los 50.000 dólares una vez que llega a producción.

Con esos números, la pregunta no es si conviene correr un escáner de seguridad. Es en qué punto del proceso conviene correrlo — y la respuesta casi nunca es “solo en el pipeline, la noche antes del release”.

La seguridad como hábito, no como evento

Shift-left security significa exactamente eso: mover la detección de vulnerabilidades lo más temprano posible en el ciclo de desarrollo, hasta el punto en que un desarrollador puede actuar sobre el hallazgo en el momento — no una auditoría trimestral que llega cuando ya es tarde para actuar barato.

Las organizaciones que adoptan este enfoque reducen las vulnerabilidades en producción hasta un 60% y recortan el costo de remediación hasta un 90%. La diferencia no es la herramienta en sí — es cuándo se usa. Un SAST corriendo en el IDE mientras se escribe el código, un SCA marcando una dependencia vulnerable antes de mergear: eso es shift-left en la práctica, no una diapositiva de estrategia.

Snyk no es una sola herramienta

Uno de los errores más comunes es tratar a Snyk como “el escáner que corre en CI/CD” y asumir que un solo comando ya cubre todo. En el día a día de un desarrollador, las dos superficies que realmente importan son el código que escribe y el código que instala:

Son complementarios, no intercambiables. SCA responde “¿esta librería que importé tiene un CVE conocido?”. SAST responde “¿el código que yo mismo escribí tiene un patrón inseguro?”. Un pipeline que solo corre snyk test sobre dependencias, pero nunca snyk code test sobre el código propio, deja la mitad de la superficie sin cubrir — y nadie se entera hasta que el hallazgo aparece donde ya no era barato corregirlo.

Lo que cambia cuando lo corrés vos, no solo el pipeline

La diferencia entre “Snyk vive en el CI/CD” y “Snyk vive en mi rutina” es el momento en que aparece el hallazgo:

• Antes de hacer commit, no después de abrir el pull request — corregir en el editor es gratis; corregir después de una revisión de código ya cuesta una segunda ronda.
• snyk code test como un linter de seguridad, corriendo tan seguido como corre el linter de estilo — no algo que se reserva para antes de un release.
• --severity-threshold=high para no ahogarse en ruido de severidad baja — un umbral demasiado agresivo es la razón número uno por la que un equipo termina desactivando el gate por completo.
• snyk ignore con justificación y fecha de revisión, nunca en silencio — un hallazgo ignorado sin registro es indistinguible de un hallazgo que nadie vio.

# Rutina mínima antes de abrir un PR
snyk code test                              # SAST — vulnerabilidades en código propio
snyk test --severity-threshold=high         # SCA — dependencias con severidad alta o crítica

Nada de esto reemplaza el scan completo en CI/CD — lo complementa. El pipeline es la red de seguridad; el hábito diario es lo que evita que la red tenga que atrapar algo en primer lugar.

El nuevo frente: cuando el código lo escribe una IA

En 2026, buena parte del código que un desarrollador “escribe” en realidad lo generó un asistente de IA. Eso no elimina la superficie de ataque — la mueve. Un prompt vago produce código funcionalmente correcto y, con la misma facilidad, código que confía en un nombre de archivo provisto por el usuario o usa una librería obsoleta porque estaba en los datos de entrenamiento.

El marco RICCE — Rol, Instrucción, Contexto, Restricciones, Ejemplos — existe para cerrar esa brecha desde el prompt, no después del scan:

• Rol: definir una personalidad específica (“sos un ingeniero de seguridad senior”) predispone al modelo a patrones seguros.
• Instrucción: ser específico sobre la tarea, no genérico.
• Contexto: explicar si el código es para una API pública o una herramienta interna — el modelo de amenaza cambia el resultado esperado.
• Restricciones: decir explícitamente qué NO hacer (“no uses librerías obsoletas”, “no confíes en input del usuario sin validar”).
• Ejemplos: un micro-ejemplo de la estructura esperada vale más que una instrucción abstracta.

A un agente de IA autónomo no se le debería permitir más que a un binario descargado de una fuente desconocida: sandboxing obligatorio, registro de herramientas aprobadas, y aprobación humana explícita antes de cualquier acción de alto riesgo.

El scanner sigue siendo necesario — pero ya no alcanza con escanear el resultado. Hay que diseñar el proceso que genera el código con la misma disciplina con la que se audita el código ya escrito.

La conclusión práctica

Snyk en el pipeline atrapa lo que se escapó. Snyk en la rutina diaria evita que algo se escape en primer lugar. Ninguno de los dos sobra — pero si solo hay uno, el que realmente mueve el costo de remediación de miles de dólares a minutos es el segundo.