Como parte de la serie Security Masterclass de Aikido, Mackenzie Jackson se reunió con Bill Harmer (CISO, Supabase) y Etienne Stalmans (Security Engineer, Supabase) para explorar cómo Supabase aborda la seguridad como parte del diseño, y no como algo a añadir más tarde.
Desde la seguridad a nivel de fila (RLS) hasta los riesgos de la codificación asistida por IA, la discusión se centró en lo que se necesita para construir rápido y mantenerse seguro.
La seguridad comienza con los datos
La filosofía de Supabase comienza con los propios datos.
“Hemos construido Supabase desde el punto de vista de un desarrollador. Todo comienza con los datos. ¿Por qué construir capas secundarias cuando puedes controlar todo en un solo lugar?” - Bill Harmer, CISO Supabase
En lugar de dispersar la lógica de seguridad entre servicios, Supabase la acerca a donde residen los datos. Cuanto más cerca esté el control, menos posibilidades hay de que las cosas salgan mal.
Construyendo con primeros principios
Para Etienne, este enfoque cambia la forma en que los desarrolladores conciben la creación de software.
«Cuando acercas la seguridad a tus datos, empiezas a pensar en ella desde los principios fundamentales. Una vez que lo entiendes, aceleras el desarrollo y mantienes la confianza en que es seguro.» - Etienne Stalmans, Ingeniero de Seguridad en Supabase
Al integrar la propiedad y el acceso a los datos en el diseño de la aplicación, los equipos eliminan las conjeturas asociadas a los sistemas de permisos por capas.
Anónimo o autenticado
Supabase simplifica el control de acceso. Los usuarios son anónimos o autenticados, sin términos medios.
«Todas las actualizaciones de datos deben registrarse: quién hizo qué, cuándo y por qué. Los usuarios anónimos tienen acceso limitado. Los usuarios autenticados obtienen exactamente lo que necesitan y nada más.» - Bill Harmer, CISO de Supabase
Etienne lo demostró durante la sesión utilizando una aplicación de recetas compartidas en vivo.
Las recetas públicas eran visibles para todos. Las recetas privadas solo eran visibles para sus propietarios o usuarios específicos con los que se habían compartido.
Unas pocas líneas de SQL, respaldadas por la Seguridad a Nivel de Fila (Row Level Security), gestionaron todo el modelo.
La Seguridad a Nivel de Fila (Row Level Security) es innegociable.
RLS define quién puede ver o cambiar qué filas de datos. Es una de las características más potentes de Postgres y una de las más fáciles de pasar por alto.
«Eso es todo lo que se necesita, una comprobación que falta y todo queda expuesto.» - Etienne Stalmans, Ingeniero de Seguridad en Supabase
Etienne compartió un ejemplo en el que una política generada por IA devolvió accidentalmente todos los registros de una tabla porque omitió una condición.
La solución fue una única corrección en la consulta, una línea que cerró una importante brecha de seguridad.
Bill lo resumió de forma sencilla:
«Queremos que la seguridad esté lo más cerca posible de los datos. Cuanto más cerca esté, menos margen de error habrá.» - Bill Harmer, CISO de Supabase
Probando tus políticas con pgTAP
La seguridad no se detiene una vez que la aplicación se lanza. Etienne mostró cómo Supabase utiliza pgTAP para probar continuamente las políticas de la base de datos.
«Puedes demostrar que lo que crees que es seguro, realmente lo es. Estas pruebas te mantienen honesto.» - Etienne Stalmans, Ingeniero de Seguridad en Supabase
Cada prueba verifica lo que más importa:
- Los usuarios públicos solo ven datos públicos
- Los usuarios autenticados solo ven lo que les pertenece
- Las políticas aplican los límites esperados en todo momento
Esta garantía continua asegura que los pequeños errores no se conviertan en fugas de datos.
Seguridad escalable
Supabase ejecuta RLS en millones de usuarios y grandes cargas de trabajo sin problemas.
«Lo ejecutamos en todas partes, incluso a escala. Sin problemas, sin excusas.» - Etienne Stalmans, Ingeniero de Seguridad en Supabase
Al aplicar la seguridad a nivel de base de datos, Supabase mantiene la lógica consistente, sin importar lo compleja que se vuelva la aplicación.
«Simplemente haz que funcione», la instrucción peligrosa
Bill cerró la sesión con una advertencia para cualquiera que utilice IA para generar código.
«Que funcione no significa que esté listo para producción.» - Bill Harmer, CISO de Supabase
«Si le dices a una IA que haga que algo funcione, podría eliminar las mismas comprobaciones de seguridad que te protegen.» - Bill Harmer, CISO de Supabase
Los modelos de IA no entienden la intención. Harán lo que sea necesario para lograr el objetivo que les marques, incluso si eso significa deshabilitar RLS o eliminar la lógica de autenticación.
El peligro no es usar la IA, es usarla sin orientación.
«El modelo no es malicioso. Está haciendo su trabajo. Pero no conoce tu intención. Ese es tu trabajo.» - Bill Harmer, CISO de Supabase
Construyendo de forma segura por defecto
La seguridad no es un obstáculo. Es la forma de avanzar más rápido sin dudar de lo que entregas.
Supabase demuestra que, cuando la seguridad reside en la capa de datos, se convierte en parte de la forma en que construyes, no en una ocurrencia tardía.
