La mayoría de los CISO creen tener una comprensión razonable del uso de herramientas sin código en su organización. Saben que los empleados están creando pequeñas automatizaciones para optimizar tareas. Suponen que unas pocas docenas o cientos de flujos de trabajo se ejecutan discretamente en toda la empresa. Pero cuando los equipos de seguridad finalmente obtienen visibilidad real, emerge una realidad diferente.

Una empresa global esperaba encontrar un par de cientos de flujos de trabajo creados por usuarios de negocio. La cifra real superaba los 3.000. Otra descubrió que un solo empleado del departamento de finanzas, sin experiencia en ingeniería, había creado más de 150 automatizaciones. Otra más encontró un flujo de trabajo que reenviaba silenciosamente el correo electrónico corporativo de un empleado a una cuenta personal de Gmail. Ninguno de estos flujos estaba registrado, ni se había inspeccionado en busca de riesgos de seguridad, ni se estaba monitorizando.

Estas no son anécdotas; son síntomas de un cambio estructural. Las empresas están cada vez más expuestas a una infraestructura oculta que es invisible, no gestionada y desprotegida.

La superficie de ataque oculta de las herramientas sin código.

Los programas tradicionales de seguridad de aplicaciones están optimizados para código almacenado en repositorios, que pasa por pipelines y se implementa a través de CI/CD, no para aplicaciones, conectores y automatizaciones sin código creadas en plataformas como Power Platform, ServiceNow, Salesforce y UiPath.

Mientras tanto, la mayoría de las organizaciones asumen que las automatizaciones creadas por usuarios de negocio son simples, de bajo riesgo y de alcance limitado. La realidad es más compleja. Los desarrolladores ciudadanos superan en número a los desarrolladores de software tradicionales en un orden de magnitud. Además, están conectando fuentes de datos, activando flujos de trabajo multisistema y llamando a API, no solo creando macros básicas o utilidades departamentales.

Dado que estas automatizaciones se crean fuera de la gobernanza de ingeniería, las herramientas de monitorización tradicionales nunca las detectan. No pasan por revisiones de código de seguridad, no se someten a modelado de amenazas ni generan los tipos de registros que esperan los SIEM. Sin embargo, realizan acciones que impactan directamente en los datos de producción y los procesos de negocio.

Esta falta de visibilidad a menudo resulta en credenciales incrustadas directamente en los flujos de trabajo. También puede crear exposición a SQL y OData en herramientas como Microsoft Power BI, automatizaciones que conectan entornos que deberían permanecer aislados y datos confidenciales expuestos externamente. En el peor de los casos, los agentes de IA pueden obtener acceso a tablas de bases de datos completas porque nunca se modificó una opción de configuración predeterminada.

Ninguno de estos riesgos de seguridad representa una intención maliciosa. Son la consecuencia inevitable de un sistema optimizado para la comodidad en lugar de para la supervisión.

Los flujos de trabajo sin código se convierten en TI en la sombra.

Una vez que el departamento de seguridad comprende la magnitud del desarrollo sin código, surge un problema más profundo: la propiedad.

Muchos flujos de trabajo sin código están vinculados a cuentas de servicio genéricas, cada una con cientos de automatizaciones. Otros pertenecen a exempleados. Las lagunas en la propiedad persisten porque las unidades de negocio desarrollan de forma independiente, TI proporciona acceso sin una lógica de gobernanza ni flujos de datos, y seguridad solo tiene visibilidad de los activos que interactúan con sus herramientas.

Los agentes de IA amplifican este problema. Cuando los empleados pueden describir un objetivo en lenguaje natural, como «resumir transacciones», «gestionar excepciones» o «obtener registros de clientes», y la plataforma genera automáticamente el flujo de trabajo, la autoría se vuelve abstracta. Un flujo de trabajo generado por IA puede modificarse con el tiempo sin una propiedad clara. La pregunta «¿Quién es el propietario?» se vuelve mucho más difícil de responder.

Estas lagunas en la propiedad hacen que la respuesta a incidentes sea prácticamente imposible. Si un flujo de trabajo comienza a extraer datos o un conector aumenta repentinamente sus privilegios, los equipos de seguridad no saben quién comprende la lógica, quién tomó las decisiones de diseño ni si el comportamiento es el esperado. El único recurso es deshabilitar los flujos de trabajo por completo, interrumpiendo procesos críticos en el proceso.

Por qué las herramientas de seguridad de aplicaciones no detectan los riesgos del desarrollo sin código.

Una vez que reconocen este problema, la mayoría de las organizaciones recurren a las herramientas de seguridad de aplicaciones habituales: SAST, DAST, IAST, pruebas de penetración y revisiones de políticas. Estos enfoques suelen fallar porque las automatizaciones sin código rara vez producen código que los escáneres puedan analizar o ejecutar en entornos seguros:

• Los registros son inconsistentes o inexistentes.

• El origen de los datos no está claro.

• Las acciones pueden abarcar varios sistemas SaaS, cada uno con visibilidad parcial.

Incluso los sistemas de gestión de identidades tienen dificultades, ya que los flujos de trabajo a menudo se ejecutan con identidades de servicio de larga duración que no se pueden vincular a ninguna persona.

Lo que surge es una capa oculta de lógica empresarial que se encuentra completamente fuera de los límites de los programas tradicionales de seguridad de aplicaciones, DevSecOps e identidad. Mientras la propiedad permanezca fragmentada y la detección sea difícil, la deuda de seguridad seguirá creciendo sin control.

Cómo gestionar el riesgo de seguridad del desarrollo sin código.

El desarrollo sin código no va a desaparecer; de hecho, la generación de flujos de trabajo asistida por IA solo lo está acelerando. Restringir el desarrollo por parte de los usuarios solo sofocará la innovación y no es una opción viable. Un mejor enfoque es obtener visibilidad y establecer una gobernanza donde actualmente no existe. Aquí hay un proceso de cinco pasos a considerar:

• Implemente un descubrimiento continuo en todas las plataformas sin código para identificar los flujos de trabajo, sus fuentes de datos y sus niveles de privilegios.

• Asigne la propiedad explícita a cada automatización, incluidos los flujos de trabajo previamente vinculados a cuentas de servicio o exempleados.

• Establezca una gobernanza del ciclo de vida que abarque el seguimiento de cambios, el control de versiones y los criterios de eliminación.

• Supervise los flujos de trabajo en tiempo de ejecución para detectar escalada de privilegios, acceso excesivo a datos o comportamiento sospechoso de los conectores.

• Integre la gobernanza de la automatización en los marcos de seguridad existentes, de modo que la lógica creada por los usuarios reciba la misma supervisión que las aplicaciones tradicionales.

Estamos entrando en una era en la que las vulnerabilidades más peligrosas no se encuentran en el código que escriben los equipos de desarrollo de aplicaciones, sino en los miles de flujos de trabajo y automatizaciones que los usuarios empresariales crean por su cuenta. Cuanto antes las organizaciones reconozcan y aborden el panorama invisible del desarrollo sin código, más rápido podrán reducir la deuda de seguridad que se acumula en su infraestructura.