Ir al contenido

El medio de los artesanos de la web miércoles, 7 de octubre de 2026

MailStudio
Seguridad

GitHub amplía su secret scanning a las claves de Lovable y Supabase

GitHub añadió el 5 de octubre de 2026 nuevos detectores de secretos para Lovable, Supabase y Pydantic. Las claves de Supabase expuestas públicamente activan ahora una revocación automática, un tema sensible para los proyectos que dependen de este backend-as-a-service.

GitHub anunció el 5 de octubre de 2026 la incorporación de nuevos detectores a su programa de secret scanning: los tokens de Lovable, las claves de Supabase y las credenciales de Pydantic AI Gateway se suman ahora a la lista de secretos detectados automáticamente en los repositorios. Para los proyectos web que dependen en gran medida de Supabase como backend-as-a-service, la novedad reduce la ventana de exposición cuando una clave se sube por error.

Cuatro nuevos detectores, dos mecanismos distintos

El secret scanning de GitHub funciona según dos lógicas distintas. Los secretos llamados «de socio» se transmiten directamente al emisor cuando se detectan en un repositorio público, lo que permite una revocación casi inmediata sin intervención del desarrollador. Los secretos «de usuario» generan en cambio una alerta clásica, visible en la pestaña de seguridad del repositorio, sea público o privado. Con esta actualización, Supabase se une al programa de socios para dos tipos de tokens: supabase_oauth_access_token y supabase_scoped_personal_access_token. Lovable Labs hace lo mismo con lovable_api_key, mientras que Pydantic Services añade logfire_token y pydantic_ai_gateway_api_key.

Por qué Supabase en particular

Supabase se ha consolidado en los últimos años como una alternativa open source a Firebase para numerosos proyectos front-end, a menudo combinada con generadores de aplicaciones asistidos por IA como Lovable, donde una clave puede acabar copiada y pegada en un archivo de configuración sin que el desarrollador mida siempre el alcance de un token de amplio perímetro. Un token de acceso personal de Supabase filtrado puede dar acceso potencialmente a todos los proyectos de una organización, bases de datos incluidas. Unirse al programa de socios significa que cualquier clave de Supabase detectada en un repositorio público activa ahora una notificación directa a Supabase, que puede invalidar el token antes incluso de que el mantenedor del repositorio lo note.

ProveedorTipo de secreto detectadoEstado en el programa
SupabaseToken OAuth, token de acceso personal con alcanceSocio (revocación automática en repos públicos)
Lovable LabsClave API de LovableSocio (revocación automática en repos públicos)
Pydantic ServicesToken Logfire, clave de Pydantic AI GatewaySocio (revocación automática en repos públicos)

Punto de atención. La revocación automática solo se aplica a los repositorios públicos. En un repositorio privado, una clave de Supabase filtrada genera una alerta de seguridad pero sigue activa hasta que alguien la revoca manualmente desde Supabase: el secret scanning reduce el riesgo, no lo elimina para las organizaciones que trabajan exclusivamente en repositorios privados.

La buena práctica sigue siendo la misma tras este anuncio: no subir nunca una clave, ni siquiera temporalmente, y apoyarse en variables de entorno cargadas en el momento del despliegue. Una recomendación que ya figura en Mail Studio a propósito de cómo blindar la pantalla de acceso de WordPress, donde la gestión de credenciales de aplicación ocupa un lugar central.

# Comprobar si queda alguna clave de Supabase en el historial local de Git
git log -p --all | grep -E "supabase_(oauth_access_token|scoped_personal_access_token)"

# En .gitignore, excluir siempre los archivos de entorno
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore

Una clave de Supabase olvidada en un repositorio público ya no es solo un riesgo teórico: ahora activa una notificación automática al proveedor, capaz de revocarla antes incluso de que el mantenedor del repositorio se percate.

Para los equipos que ya gestionan varios proyectos con gestores de secretos externos, esta ampliación del secret scanning no sustituye a una bóveda dedicada, pero sí reduce parte del plazo entre la fuga y su detección. Se inscribe en una tendencia más amplia de GitHub, que ha ampliado su programa de socios a un ritmo sostenido a lo largo de 2026 a medida que nuevos servicios en la nube y herramientas de IA generativa ganan adopción entre los desarrolladores web, un terreno ya cubierto por la selección de gestores de paquetes JavaScript publicada en Mail Studio.

Lo que hay que recordar

GitHub añade Lovable, Supabase y Pydantic a su programa de secret scanning de socios: cualquier clave de estos proveedores detectada en un repositorio público se transmite ahora automáticamente al emisor para su revocación. La protección sigue limitada a los repositorios públicos y a las claves explícitamente cubiertas por un detector, lo que no exime a los equipos de buenas prácticas de gestión de secretos previas.

Me parece una ampliación bienvenida, pero mantengo cierta prudencia sobre su interpretación: trata el síntoma, no la causa. La pregunta de fondo sigue siendo la misma desde hace años, a saber por qué siguen apareciendo claves de amplio perímetro en los commits. Mientras las herramientas de scaffolding asistidas por IA sigan generando archivos de configuración con claves en claro por defecto, el secret scanning seguirá siendo una red de seguridad útil pero insuficiente. — Simon Janvier

Para saber más: anuncio oficial en el changelog de GitHub.

Compartir LinkedIn Bluesky Hacker News E-mail

Leer también