Tus ingenieros ahora pueden aprovisionar infraestructura en la nube más rápido de lo que tu proceso de revisión puede detectar, y el código no se diferencia en nada de lo que produciría un despliegue legítimo.
La TI en la sombra solía ser un problema de SaaS. Alguien del equipo de marketing se registraba en una herramienta, la conectaba a Google Workspace y tu primera señal era una concesión OAuth que no habías autorizado. Molesto. Detectable. Controlable.
La nueva TI en la sombra no aparece en tus registros de OAuth. Aparece como infraestructura, ejecutándose en tu cuenta de la nube, creada por un ingeniero con buenas intenciones que le pidió a un agente de IA que la montara en una tarde. Sin ticket, sin revisión, sin intervención del equipo de seguridad. Solo alguien con una buena idea y una herramienta que eliminó toda la fricción que solía ralentizarlos.
Esa fricción no era solo ineficiencia. Parte de ella cumplía una función de seguridad real.
El problema de las buenas intenciones
La TI en la sombra clásica tenía un aire de alguien que evitaba a TI a propósito. Un equipo que no quería esperar a las compras. La historia de la seguridad trataba, al menos en parte, de hacer cumplir las políticas.
Esto no es lo que ocurre aquí.
El ingeniero que crea una herramienta interna por intuición no intenta eludir nada, intenta ayudar. Tiene acceso a un agente de IA que puede escribir código, generar Pulumi y montar infraestructura más rápido de lo que cualquier proceso de revisión fue diseñado para gestionar. Y a menos que haya dedicado tiempo a pensar en la seguridad en la nube, no tiene motivos para saber que lo que acaba de desplegar es un problema.
Eso es lo que hace que esto sea más difícil: no puedes solucionarlo a base de imposiciones, tienes que adelantarte rápidamente.
Así es como se ve un mal día: un ingeniero crea una aplicación interna ligera para automatizar algo que su equipo hace manualmente. Le pide al agente de IA que se encargue de la infraestructura. El agente aprovisiona recursos en la cuenta de AWS del equipo, abre los puertos necesarios y despliega la aplicación. Funciona y al equipo le encanta. Nadie abre un ticket porque no hay nada que reportar. Seis semanas después, tu CSPM marca un endpoint público con un rol IAM con demasiados permisos. Para entonces, la aplicación ha estado funcionando en producción el tiempo suficiente como para que el movimiento lateral sea un escenario realista, no teórico.
La intención era buena. El resultado tiene un radio de impacto.
Por qué esto es diferente de la proliferación de SaaS
Cuando la TI en la sombra significaba SaaS no autorizado, tu superficie de detección estaba definida. Concesiones OAuth, tráfico de red, informes de gastos, anomalías en SSO. La herramienta existía fuera de tu infraestructura. Era externa. Podías encontrarla, podías cortarla y el daño solía estar limitado.
Las herramientas internas creadas por agentes viven dentro de tu infraestructura. Tienen roles IAM. Pueden tener acceso directo a datos de producción, APIs internas o sistemas sensibles. Parece legítimo porque fue construido por un empleado legítimo usando herramientas legítimas. No hay una costura obvia donde detectar. El código no se anuncia como algo sin gobierno. Simplemente se ejecuta.
Este es el cambio que vale la pena definir claramente: hemos pasado de la proliferación de SaaS a la proliferación de código. El manual de detección de uno no sirve para el otro.
Una base que realmente vale la pena usar
El objetivo aquí no es ralentizar a los ingenieros. Es hacer que el camino seguro sea el camino fácil. La base sobre la que estamos trabajando en Webflow tiene dos capas, y esa distinción es importante.
Los controles de plataforma son cosas que configuras una vez a nivel de organización o cuenta y que hacen que sea estructuralmente más difícil hacer las cosas mal por accidente.
Barreras de seguridad de privilegios mínimos en IAM. Los permisos disponibles para las cuentas de AWS a nivel de equipo deben estar limitados por defecto. Un ingeniero no debería poder aprovisionar un recurso público con un rol de permisos amplios sin encontrarse con una barrera. La barrera no detiene el trabajo. Impide que la peor versión del trabajo se despliegue silenciosamente.
Cumplimiento del gestor de secretos. Las credenciales codificadas en aplicaciones creadas por intuición no son una hipótesis. Son casi una certeza si no haces que el camino correcto sea el más evidente. Obligar a usar un gestor de secretos a nivel de infraestructura elimina por completo la toma de decisiones del ingeniero individual.
Destinos de despliegue protegidos por VPN. Las herramientas internas deberían estar detrás de tu VPN corporativa por defecto. Si algo realmente necesita estar expuesto al público, eso debería requerir una decisión explícita, no ser un descuido por defecto.
Los controles de proceso son lo que debe suceder a nivel de herramienta antes de que se publique nada.
Verificación automatizada de la línea base. Antes de que una persona con conocimientos de seguridad revise nada, ejecuta el código y la configuración de la infraestructura contra tu línea base de forma automática. Marca las infracciones, clasifícalas por gravedad y proporciona al ingeniero una guía de corrección específica. Esta es la capa que puede gestionar una habilidad de Claude o herramientas similares. La revisión humana se centra entonces en lo que detectó la verificación automatizada, en lugar de empezar desde cero.
Revisión de código con enfoque de seguridad y escalado de seguridad. Toda herramienta creada internamente que toque la infraestructura de producción necesita que una persona con contexto de seguridad la revise antes de su lanzamiento. Para herramientas de menor riesgo, basta con un ingeniero compañero que entienda el alcance del impacto de lo que está revisando. Para cualquier cosa que involucre infraestructura en la nube, acceso directo a datos o roles IAM novedosos, se escala a una revisión de seguridad formal. El mismo control, escalonado según el riesgo. El punto clave: el revisor debe entender realmente el código. Con herramientas creadas por intuición, es posible que el autor no entienda del todo lo que construyó. Eso hace que la revisión sea más importante, no un mero trámite. No es solo un filtro de calidad. Es un filtro de comprensión.
La red de seguridad
La línea base es preventiva. La detección es lo que atrapa lo que se escapa.
Tu CSPM es la herramienta adecuada para encontrar errores de configuración en lo que ya existe. Wiz y herramientas similares detectarán el punto de acceso público, el rol con permisos excesivos o el bucket de almacenamiento sin los controles de acceso adecuados.
Pero el CSPM solo encuentra lo que ya está desplegado. La línea base y el proceso de revisión son con lo que cuentas para evitarlo. La detección es la capa de captura, no la primera línea de defensa.
El problema más difícil de la detección es saber que algo existe en primer lugar. Una herramienta creada por intuición que se ejecuta localmente o en una cuenta de equipo puede no dejar rastro en tu capa de visibilidad habitual. Sin pipeline de despliegue. Sin ticket de cambio. Sin entrada en el inventario de activos.
Aquí es donde las señales de comportamiento en la telemetría de tu nube empiezan a importar. Creación de roles IAM fuera de la actividad normal de tu pipeline. Nuevos recursos públicos que aparecen sin un registro de cambios correspondiente. Llamadas a la API que se originan desde máquinas de desarrolladores directamente hacia cuentas de producción en lugar de pasar por tus herramientas estándar. Ninguna de estas señales es definitiva por sí sola. Combinadas, empiezan a parecer algo que merece una mirada más atenta.
La mayoría de los equipos no buscan estas señales específicamente en el contexto de herramientas creadas por agentes. Esa es la brecha que vale la pena cerrar.
La línea base codificada
La documentación que vive en una wiki es una línea base que nadie usa en el momento en que la necesita. El mejor camino es hacer que la línea base esté disponible dentro de las herramientas que los ingenieros ya usan, en el momento de la creación.
Una habilidad de Claude o una herramienta nativa de IA similar que revise las descripciones de arquitectura o la infraestructura generada frente a tu línea base de seguridad específica es más útil que una lista de verificación en Confluence. El ingeniero recibe comentarios específicos y procesables antes de que un revisor humano los vea. El equipo de seguridad recibe una primera pasada que ya ha sido filtrada de fallos obvios. La revisión es mejor porque parte de una imagen más completa.
Nada de esto funciona si los ingenieros no saben que la habilidad o el proceso de revisión existen. La concienciación es su propia capa de prevención. Introducir ambos durante la incorporación es lo que hace visible el camino seguro, y dejar que los comentarios de la habilidad sirvan también como educación sobre por qué importa cada verificación es lo que hace que se asimile. Una barrera de seguridad que no se anuncia a sí misma no es preventiva.
Hacia ahí nos dirigimos internamente. La entrada del blog es el argumento de por qué esto importa. La habilidad es lo que lo pone en funcionamiento.
La conclusión
Las herramientas internas creadas por intuición no van a desaparecer. La fricción que solía ralentizar la infraestructura sin gobierno ha desaparecido, y no va a volver. La pregunta es si tu línea base de seguridad se pondrá al día antes de que lo haga tu CSPM.
Los controles de plataforma hacen que el camino seguro sea el predeterminado. Los controles de proceso aseguran que una persona con contexto de seguridad vea todo antes de que se publique. La detección te da una capa de captura para lo que, de todos modos, se escapa.
Nada de esto requiere un equipo de AppSec dedicado ni un SOC. Solo hace falta una base clara, las herramientas para aplicarla y que los ingenieros entiendan lo que están revisando. Es un problema que un equipo de seguridad pequeño y bien organizado puede resolver. Los controles de plataforma dependen de la organización o de la ingeniería de seguridad; se configuran una vez y se aplican en todas partes. Los controles de proceso están distribuidos: un compañero con conocimientos de seguridad se encarga de las herramientas de menor riesgo, mientras que todo lo relacionado con la infraestructura en la nube, el acceso directo a datos o nuevas configuraciones de IAM se deriva a una revisión de seguridad formal. Es responsabilidad distribuida con una ruta de escalada clara, no un único equipo revisándolo todo.
Establece la base antes de que el CSPM la encuentre por ti.
