El DSPM existe porque los datos sensibles ya no permanecen estáticos.
Más allá de la base de datos, los datos sensibles se encuentran en logs, colas, herramientas SaaS, sistemas de soporte, pipelines de análisis, data warehouses, copias de seguridad, y ahora en prompts de IA y almacenes vectoriales. Se mueven porque la aplicación los mueve. Una dirección de correo electrónico de un cliente podría originarse en un formulario de registro, pasar por una API, ser escrita en Postgres, aparecer en un log de aplicación, ser copiada en Snowflake, fluir a una herramienta de soporte, ser enviada a Stripe, y luego quizás ser incorporada a un flujo de trabajo de IA. Y esto se considera un flujo de trabajo bastante normal.
Así, cuando se habla de DSPM, o Data Security Posture Management, la idea básica es bastante sencilla: ayudar a los equipos a comprender dónde se encuentran los datos sensibles, qué tipo de datos son, quién o qué puede acceder a ellos, cómo están protegidos y dónde pueden estar expuestos.
La mayoría de las empresas no tienen un mapa perfecto de dónde residen los datos sensibles. Saben que tienen datos de clientes, detalles de pago, tokens, datos de empleados y ahora todo tipo de contexto de IA. Lo que no siempre saben es dónde han terminado todos esos datos, quién puede acceder a ellos o si se están manejando de una manera que cumpla con sus expectativas de seguridad y cumplimiento.
La visibilidad es el problema que el DSPM tradicional intenta resolver.
El DSPM tradicional comienza donde los datos se almacenaron.
El DSPM tradicional suele comenzar con el patrimonio de datos. Esto generalmente implica escanear sistemas de almacenamiento y plataformas conectadas: buckets S3, bases de datos, data warehouses, aplicaciones SaaS y copias de seguridad.
La herramienta busca datos sensibles, los clasifica, verifica permisos y exposición, y ayuda al equipo de seguridad a priorizar lo que importa. Podría indicarle que un bucket S3 contiene PII. O que una tabla de data warehouse tiene datos relacionados con pagos. O que un recurso compartido de archivos es demasiado accesible. O que una copia de seguridad contiene registros de clientes de producción en un lugar que nadie ha revisado en un año.
Eso es obviamente útil. Hay una gran cantidad de datos sensibles circulando en entornos modernos, y gran parte de ellos son copiados, replicados, exportados, registrados, sincronizados, archivados y olvidados. El DSPM tradicional ayuda a los equipos a encontrar eso. Proporciona al equipo de seguridad una mejor visión del patrimonio de datos real, más allá de los recursos cloud que lo rodean.
Pero para los desarrolladores y los equipos de AppSec, eso suele ser la segunda parte de la historia.
La primera parte es cómo llegaron los datos allí.
La pregunta que falta es la ruta del código.
Una herramienta DSPM tradicional podría decir: “Se encontró PII en este almacén de logs.”
Pero el desarrollador aún tiene que averiguar por qué está la PII allí, qué parte de la aplicación la escribió, si fue intencional y qué cambio la solucionaría realmente. Y para esto, es necesario revisar el código.
La aplicación recopiló los datos, los procesó y decidió qué campos devolver desde una API. Luego registró el cuerpo de la solicitud, pasó un token a un worker, envió metadatos de clientes a un proveedor y construyó el prompt que incluía contexto sensible.
Así, la pregunta más orientada al desarrollador debería ir más allá de “¿Dónde se almacenan los datos sensibles?” y ser más bien “¿Qué ruta de código creó la exposición?” Esa es la versión shift-left del DSPM.
El DSPM basado en código comienza con la aplicación en lugar de la capa de almacenamiento. Examina APIs, modelos ORM, llamadas de logging, consumidores de colas, flujos de trabajo CI/CD, integraciones de IA y más. El objetivo es comprender cómo los datos sensibles entran en el sistema, cómo se mueven, dónde se almacenan, dónde salen y dónde pueden ser mal gestionados.
DSPM basado en código y Auditorías de Exposición de Datos
En Aikido, creo que la forma más clara de describir nuestro DSPM basado en código es viéndolo como una Auditoría de Exposición de Datos, que consiste en usar IA para encontrar flujos de datos sensibles y riesgos de seguridad en el código.
Una Auditoría de Exposición de Datos cubre PII, PHI, PCI, secretos, tokens, contenido del cliente y el manejo de datos relacionados con la IA. Cada resultado incluye evidencia y una remediación en el código sin necesidad de conectarse directamente a los almacenes de datos.
La lectura del código también puede identificar una protección de datos débil. Puede señalar un campo sensible almacenado sin cifrado, una clave hardcodeada en el código fuente, MD5 o SHA1 o base64 utilizados como si fueran cifrado, un secreto comprometido en el repositorio y datos sensibles enviados a través de un canal inseguro.
Hay otra forma de enfocar esto. El DSPM tradicional necesita acceso a sus datos reales, conectándose a buckets S3, bases de datos y data warehouses para escanear su contenido. El DSPM basado en código, en cambio, lee el código que crea y mueve esos datos, por lo que nunca solicita acceso ni descarga nada. La lectura desde el código reduce la barrera para su activación, ya que no hay que conceder nuevo acceso de producción.
Esto también lo hace más rápido, ya que no hay nada que rastrear. También es más preciso, puesto que lee cómo se utiliza un campo en lugar de asumir que cualquier número de nueve dígitos es un número de la Seguridad Social. El resultado es un mapa de dónde residen los datos sensibles en su arquitectura y cómo están protegidos, construido íntegramente a partir del código.
En Aikido, esto se ejecuta como parte del análisis de código con IA, por lo que la Auditoría de Exposición de Datos se integra con el resto de la revisión de código en lugar de ser una integración de acceso a datos independiente.
Cómo difiere la calidad de los hallazgos
Tomemos el registro como un ejemplo sencillo.
Un producto DSPM tradicional podría acabar indicando que existe PII en los registros de la aplicación. De nuevo, útil. Pero ahora alguien tiene que ir a buscar la fuente.
Una Auditoría de Exposición de Datos basada en código puede ofrecer una visión más completa al conectar los datos, la ruta del código, el destino, el riesgo de exposición y la solución. Esto la hace más útil para los desarrolladores.
Por ejemplo, el controlador de pago registra el objeto completo billingDetails cuando falla la autorización de pago. Ese objeto incluye correo electrónico, número de teléfono, dirección de facturación y los últimos cuatro dígitos de la tarjeta. Los registros se envían a Datadog. La solución es redactar esos campos antes de registrarlos y mantener solo el ID de cliente, el ID de intención de pago y el código de error.
Esa es una información muy diferente a la que se obtiene de un DSPM tradicional.
Lo mismo se aplica a los secretos y tokens. Tomemos un token SCM utilizado para leer código de GitHub, GitLab o Bitbucket. Una vista orientada al almacenamiento podría preguntar si el token está cifrado en la base de datos. Sin embargo, esta no es toda la historia.
¿Dónde entra el token en la plataforma? ¿Es un token OAuth, un token de GitHub App o un PAT enviado por el usuario? ¿Qué ámbitos tiene? ¿Cómo se valida? ¿Dónde está cifrado? ¿Dónde se almacena? ¿Cuándo se descifra? ¿Está en caché? ¿Está incrustado en una URL de clonación? ¿Se pasa a un worker? ¿Podría filtrarse a través de registros, trazas, errores, argumentos de proceso o telemetría? Es un problema de seguridad de datos, pero el código nos dice lo que necesitamos saber sobre su movimiento.
Del panel de control a la solución
Aquí es donde creo que el DSPM basado en código se vuelve interesante.
La mejor versión de esto no es otro panel de control que diga: «Tiene datos sensibles». Todo el mundo lo sabe. La mejor experiencia dice: aquí está el inventario de datos sensibles, aquí está el flujo, aquí está el riesgo de exposición, aquí están los controles relevantes y aquí está el cambio en el código que reduce el riesgo.
Si el código creó la exposición, la solución probablemente reside en el código.
El flujo de trabajo típico del desarrollador debería ser, por lo tanto:
- Redactar campos sensibles antes de registrarlos.
- Devolver un objeto de respuesta de la API más pequeño.
- Añadir una verificación de propiedad del inquilino.
- Dejar de pasar tokens en las URLs.
- Enmascarar datos de producción antes de restaurarlos en staging.
- Añadir cifrado antes del almacenamiento.
- Eliminar datos del cliente de un prompt de LLM.
- Corregir la lógica de eliminación para que los registros posteriores se eliminen realmente.
El ingeniero quiere saber qué ruta de código específica crea un riesgo específico de exposición de datos y cómo solucionarlo.
Esto también hace que la conexión con los marcos de seguridad y cumplimiento sea mucho más concreta. Si un token se maneja incorrectamente, esto puede ser relevante para la gestión de autenticadores, la protección de la transmisión, el mínimo privilegio y la protección de los registros de auditoría. Si se registra PII sin redactar, esto puede ser relevante para la privacidad, la retención, la minimización de datos y los controles de monitorización. Si los datos de clientes se copian a staging sin enmascarar, esto puede afectar al control de acceso, la separación de entornos y las obligaciones de cumplimiento. Si los registros sobreviven a una solicitud de eliminación, o los datos superan su ventana de retención, esto se vincula directamente con las obligaciones de GDPR y CCPA, y debe corregirse en la propia lógica de eliminación y retención.
El hallazgo que simplemente dice «Patrón de registro inseguro» tiene una utilidad bastante limitada. Pero algo como «La PII del cliente fluye a los registros a través de esta ruta de código, lo que crea un riesgo de exposición de datos, afecta a estos controles y se puede solucionar redactando estos campos antes de registrar», es accionable.
Esa es una forma mucho mejor de integrar la ingeniería, AppSec y el cumplimiento en la misma conversación.
La versión sencilla
El DSPM tradicional sigue siendo importante. Ayuda a los equipos a entender dónde residen los datos sensibles en el entorno real. Puede encontrar buckets olvidados, bases de datos expuestas, datos en la sombra y almacenes con permisos excesivos.
Pero el DSPM basado en código añade la capa de aplicación que falta. Ayuda a explicar cómo llegan allí los datos sensibles, cómo se mueven, dónde reside el mecanismo de exposición y qué pueden hacer los desarrolladores al respecto.
Así, la versión sencilla es:
El DSPM tradicional encuentra los datos sensibles donde residen.
El DSPM basado en código encuentra cómo se exponen los datos sensibles.
Una auditoría de exposición de datos conecta ese flujo de nuevo al código, la brecha de control y la solución.
Esa es la versión shift-left de DSPM. Y para los desarrolladores y equipos de AppSec, es probablemente la versión que más ayuda a los equipos.
Aikido ofrece el primero de su tipo en DSPM basado en código. Proteja y rastree sus datos, sin siquiera conectar sus bases de datos.
