Aplicaciones, agentes de IA y automatizaciones necesitan credenciales para consultar un ERP, enviar mensajes, cobrar o acceder a una base de datos. El riesgo aparece cuando una clave API acaba en el código, en un fichero subido al repositorio, en el historial de Git, en un registro o dentro de la aplicación que recibe el usuario.
El problema es especialmente actual porque el volumen de software e integraciones crece más deprisa que la revisión manual. En octubre de 2026, GitHub presentó un modelo específico para detectar secretos y anunció la disponibilidad general de su análisis de seguridad con IA en pull requests. La prevención y la detección ya deben formar parte del ciclo de entrega, no de una revisión ocasional.
Qué es un secreto y por qué no debe estar en el código
Un secreto es cualquier valor que permite acceder o acreditar una identidad: clave API, contraseña de base de datos, token OAuth, clave privada, certificado, secreto de webhook, credencial cloud o token de un bot. Una URL pública puede ser configuración; una credencial no.
Las variables de entorno separan configuración y aplicación, pero no son un almacén seguro por sí mismas. Si el fichero .env llega a Git, se copia a una imagen de contenedor o aparece en un log, la exposición continúa. El objetivo es que el secreto no esté en el artefacto y que llegue a la carga de trabajo únicamente en el entorno y durante el tiempo imprescindibles.
Dónde se filtran las claves
Repositorio e historial
Eliminar una línea en el siguiente commit no borra las copias del historial, forks o cachés. Si la credencial entra en el repositorio, hay que considerarla comprometida: primero se revoca o rota; después se limpia el historial si sigue siendo conveniente.
CI/CD, registros y artefactos
Un pipeline puede imprimir variables durante un diagnóstico, ejecutar código no confiable o incluir un fichero sensible en el paquete final. Como CI/CD suele tener permiso para desplegar y tocar varios entornos, un fallo aquí puede tener más alcance que una contraseña de usuario.
Web y móvil
No existe un secreto permanente dentro de una app distribuida. JavaScript, un APK o un binario iOS pueden inspeccionarse. La clave privilegiada debe quedarse en el servidor: la app llama a una API propia y recibe un token breve para la operación autorizada.
Colaboración y asistentes de IA
Incidencias, chats, capturas y prompts también conservan información. El enmascaramiento, los datos ficticios en ejemplos y reglas para asistentes de código reducen el riesgo de sacar credenciales del entorno controlado.
Una arquitectura segura de principio a fin
Un gestor de secretos aporta almacenamiento cifrado, control de acceso, versiones, auditoría y rotación. El pipeline o servicio se autentica con una identidad de carga de trabajo y solicita únicamente el valor necesario. Siempre que sea posible, un token temporal es preferible a una clave estática.
- Crear: generar el secreto en un servicio fiable, con alcance mínimo y propietario.
- Guardar: registrarlo en un almacén de secretos, nunca en una hoja o un mensaje.
- Entregar: inyectarlo en memoria o como fichero efímero durante la ejecución.
- Usar: impedir que logs, errores y telemetría muestren el valor.
- Rotar: sustituirlo periódicamente sin interrumpir el servicio.
- Revocar: cancelar de inmediato credenciales sospechosas o huérfanas.
- Auditar: saber quién accedió, cuándo y con qué finalidad.
Producción, preproducción y desarrollo necesitan fronteras claras. Una automatización de pruebas no debe leer secretos reales; un servicio de avisos no debe modificar clientes en el CRM. El mínimo privilegio contiene el daño incluso si una credencial queda expuesta.
Controles antes, durante y después del commit
La defensa combina capas. En el equipo del desarrollador, un hook de pre-commit reconoce patrones. En la plataforma Git, la protección de push bloquea el secreto. En pull request y CI, el escáner revisa ficheros, historial, infraestructura y artefactos. En producción, alertas detectan un uso anómalo.
- mantener reglas para proveedores y formatos internos;
- escanear infraestructura como código e imágenes de contenedor;
- autorizar excepciones con motivo, responsable y caducidad;
- no mostrar el valor completo ni siquiera por defecto a administradores;
- probar la rotación antes de necesitarla;
- retirar credenciales inactivas o sin propietario.
OWASP recomienda no codificar secretos en repositorios ni pipelines y utilizar un sistema de gestión específico. La detección posterior sigue siendo necesaria, pero bloquear el push reduce la ventana en la que alguien puede copiar el valor.
Ejemplo: cobros y WhatsApp en una app
Una aplicación de pedidos cobra y envía la confirmación por WhatsApp. El móvil no recibe las claves de los proveedores. Autentica al usuario en la API corporativa; el backend valida pedido y permisos, recupera cada credencial del almacén y llama al servicio externo. Los webhooks usan un secreto distinto y se procesan con idempotencia.
En el pipeline, producción emplea una identidad propia y acceso limitado al despliegue. Los logs guardan el identificador de operación, nunca el token. Para rotar la clave de mensajería, el almacén admite dos versiones durante una ventana breve, las instancias cargan la nueva y la anterior se revoca sin detener los pedidos.
Qué hacer ante una filtración
- Revocar o rotar ya. Borrar el fichero no invalida copias.
- Acotar el alcance. Revisar permisos, entornos y periodo de validez.
- Analizar evidencias. Buscar accesos, consumo, costes y cambios anómalos.
- Contener. Bloquear tokens derivados y reducir permisos temporalmente.
- Corregir el origen. Ajustar pipeline, logs o arquitectura.
- Evitar la repetición. Convertir la lección en un control automático.
Reescribir el historial puede limitar exposición futura, pero no sustituye a la rotación. Antes de modificar datos, conviene preservar las evidencias necesarias para investigar.
Métricas útiles
- secretos bloqueados antes del push;
- tiempo desde la alerta hasta la revocación;
- credenciales con propietario, alcance y caducidad;
- porcentaje de tokens temporales frente a claves permanentes;
- pruebas de rotación completadas sin parada;
- credenciales compartidas entre servicios o inactivas.
Plan de acción inmediato
- inventariar repositorios, pipelines, apps e integraciones;
- buscar secretos actuales e históricos sin exponer sus valores;
- rotar primero los de mayor privilegio;
- adoptar un almacén e identidades por servicio y entorno;
- activar pre-commit, protección de push y análisis continuo;
- eliminar credenciales permanentes de frontales y móviles;
- ensayar el procedimiento de respuesta.
Seguridad integrada en la entrega
La gestión de secretos no es una herramienta aislada: depende de la arquitectura, las integraciones, el pipeline y la operación. Si se diseñan juntos, la empresa puede entregar con rapidez sin convertir cada nueva API en un punto de riesgo.
ProativaIA desarrolla software a medida, aplicaciones conectadas y automatizaciones con inteligencia artificial. Podemos evaluar la exposición actual, desplegar gestión de secretos y construir integraciones con rotación, auditoría y mínimo privilegio.