¿Qué son los secretos codificados y por qué son tan riesgosos?

Un desarrollador necesita probar rápidamente una conexión a la base de datos. Pega la contraseña directamente en el archivo de configuración, hace el commit y continúa. La funcionalidad se despliega. La contraseña permanece. Seis meses después, el repositorio se bifurca, los logs de CI/CD se indexan y esa credencial está en tres lugares que nadie monitorea.

Así es como la mayoría de los secretos codificados llegan al exterior — a través de la conveniencia que perdura más allá de su contexto. GitGuardian encontró 28,65 millones de nuevos secretos codificados añadidos a repositorios públicos de GitHub en 2025, un aumento del 34% interanual y un incremento del 152% desde 2021.

Puntos clave

• Los secretos codificados son credenciales incrustadas directamente en código fuente, configuraciones, scripts o paquetes de aplicaciones — valores estáticos escritos en tiempo de desarrollo en lugar de inyectados en tiempo de ejecución desde una fuente segura.
• Los repositorios privados no son un lugar seguro para secretos. Las cuentas de desarrollador comprometidas, las integraciones de CI/CD, las bifurcaciones y las copias de seguridad amplían la superficie de exposición más allá de lo que implica «privado».
• El desarrollo asistido por IA está empeorando el problema. Los commits de herramientas de codificación con IA tienen el doble de probabilidad de contener secretos. Las filtraciones de credenciales de servicios de IA crecieron un 81% interanual en 2025.
• Eliminar la línea no es suficiente. Un secreto confirmado persiste en el historial de Git, las bifurcaciones, los logs de CI/CD y los clones locales. La rotación o revocación es lo primero. La eliminación es el paso de limpieza.
• La detección debe ser continua y en capas. Los plugins de IDE detectan secretos antes del commit; el escaneo de CI/CD detecta lo que se escapa; los escaneos de todo el repositorio revelan la exposición histórica. Cada capa tiene puntos ciegos. Ninguna funciona sin un propietario definido y un proceso de triaje para cada hallazgo.
• La causa raíz es la fricción del flujo de trabajo, no el descuido. Los desarrolladores codifican secretos cuando no hay una alternativa aprobada más rápida. La prevención significa eliminar esa fricción — no solo añadir escáneres.
• Cada tipo de credencial necesita un hogar designado. Los secretos de máquinas pertenecen a una bóveda o gestor de secretos con inyección en tiempo de ejecución. Las credenciales humanas y compartidas pertenecen a un gestor de contraseñas corporativo con controles de acceso y registros de auditoría. Las credenciales que no tienen un hogar designado terminan en el código.

¿Qué son los secretos codificados?

Los secretos codificados son contraseñas, claves API, tokens, claves privadas u otras credenciales escritas directamente en código fuente, scripts, archivos de configuración o paquetes de aplicaciones. Son valores estáticos incrustados en tiempo de escritura en lugar de inyectados en tiempo de ejecución desde una fuente segura. MITRE clasifica esta vulnerabilidad como CWE-798: Use of Hard-coded Credentials y califica su probabilidad de explotación como alta.

La página de la comunidad OWASP sobre el uso de contraseñas codificadas cubre la variante específica de contraseñas, pero el alcance completo de los secretos codificados se extiende mucho más allá de las contraseñas.

¿Dónde suelen aparecer los secretos codificados?

Los secretos codificados aparecen dondequiera que se escriba, compile, almacene o despliegue código — una superficie mucho mayor de lo que la mayoría de los equipos se dan cuenta.

En el código base y control de versiones:

• Código fuente de aplicaciones y comentarios en línea
• Archivos de configuración (.properties, .yaml, .json, .xml)
• Archivos de desarrollo local (.env, .env.local) confirmados por error
• Plantillas de infraestructura como código (Terraform, Ansible, CloudFormation)

En sistemas de compilación y despliegue:

• Archivos de definición de pipelines CI/CD con credenciales escritas en línea
• Logs de compilación y artefactos que muestran valores de entorno
• Imágenes de contenedores con secretos incorporados en las capas

En sistemas distribuidos e integrados:

• Aplicaciones móviles y paquetes de JavaScript del lado del cliente
• Firmware, dispositivos IoT, routers y controladores integrados

En almacenamiento informal:

• Documentación, wikis internas y archivos README
• Tickets de soporte, issues de Jira y páginas de Confluence
• Exportaciones de Slack, hilos de correo electrónico y hojas de cálculo compartidas

Una nota sobre los archivos .env: son más seguros que escribir valores directamente en el código, pero solo si se excluyen del control de versiones, se protegen localmente y nunca se copian en logs o artefactos de compilación. Un archivo .env confirmado una vez es un secreto codificado.

¿Por qué los desarrolladores codifican secretos?

La causa raíz casi nunca es el descuido. Es la fricción del flujo de trabajo.

1. Pruebas locales rápidas. Codificar un valor lleva diez segundos. Configurar una referencia a una bóveda lleva más tiempo, especialmente sin una plantilla estándar.
2. Evitar la deriva de configuración. Cuando los entornos de desarrollo, staging y producción se gestionan de forma inconsistente, los desarrolladores a veces codifican valores para garantizar que la credencial correcta llegue al sistema correcto.
3. Copiar de documentación o ejemplos. Los documentos oficiales y las respuestas de Stack Overflow frecuentemente muestran credenciales como marcadores de posición. Esos marcadores se reemplazan con valores reales y se confirman.
4. Código generado por IA. Los asistentes de codificación pueden reproducir patrones inseguros de los datos de entrenamiento o insertar credenciales de marcador de posición que parecen funcionales. El riesgo es mayor cuando el código generado evita la revisión de seguridad normal o cuando un desarrollador reemplaza un marcador de posición con un valor real sin moverlo a una fuente segura.
5. Sin flujo de trabajo estándar de gestión de secretos. Cuando no hay una forma aprobada de manejar secretos localmente, los desarrolladores inventan la suya propia — y la conveniencia generalmente gana.
6. Falta de verificaciones pre-commit. Sin puertas automatizadas, un secreto codificado puede viajar desde el editor de un desarrollador a un repositorio compartido en un solo push.
7. Propiedad poco clara de cuentas de servicio y credenciales compartidas. Cuando nadie es propietario de una credencial, nadie la gestiona de forma segura.

¿Por qué son tan peligrosos los secretos codificados?

Los números hacen difícil ignorar la tendencia. GitGuardian rastreó ~11 millones de nuevos secretos codificados en GitHub público en 2021; para 2025 esa cifra había alcanzado 28.649.024 — un aumento del 152% en cuatro años.

La detección por sí sola no está cerrando la brecha: el 64% de los secretos confirmados como válidos en 2022 seguían activos y explotables en 2026. Los secretos codificados no son un problema heredado que se está resolviendo gradualmente — la superficie de exposición está creciendo más rápido de lo que la remediación puede mantener el ritmo.

Los repositorios privados no son un lugar seguro para secretos. El acceso al repositorio a menudo es más amplio de lo que los administradores se dan cuenta. Las herramientas de CI/CD, los sistemas de respaldo, los endpoints de desarrolladores, las integraciones de terceros y las bifurcaciones amplían la superficie de exposición. Una cuenta de desarrollador comprometida es suficiente para extraer cada secreto de cada repositorio privado que esa cuenta pueda leer.

El DBIR 2025 de Verizon también encontró que la infraestructura de aplicaciones web representaba el 39% de los secretos divulgados en repositorios públicos de Git, y el 66% de esos eran JWTs. Los secretos genéricos — la categoría más difícil de detectar con herramientas de coincidencia de patrones — representaron el 58% de todas las credenciales filtradas en 2024, según GitGuardian.

Passwork es un gestor corporativo de contraseñas y secretos: claves API, tokens, claves SSH y credenciales de administrador — todo en bóvedas cifradas con acceso basado en roles y registros de auditoría, no en código o hilos de chat. Explorar Passwork

¿Qué debe hacer si se encuentra un secreto codificado?

El instinto de eliminar la línea y hacer un commit de corrección es comprensible. También es insuficiente. Una vez que un secreto se confirma, asuma que ha sido copiado, almacenado en caché, registrado o indexado en algún lugar que no puede alcanzar.

Flujo de trabajo de respuesta a incidentes

1. Clasifique el secreto. Determine si es una contraseña, clave API, token, clave privada, certificado o cadena de conexión.
2. Identifique el propietario y el alcance. Encuentre qué sistema, entorno, nivel de privilegio y cuenta controla el secreto.
3. Revoque o rote inmediatamente. Trate el valor como comprometido desde el momento en que fue confirmado o expuesto.
4. Verifique los logs de acceso. Busque actividad sospechosa antes y después de la ventana de exposición.
5. Elimínelo del código base. Reemplace el valor codificado con una referencia a una fuente segura.
6. Limpie el historial del repositorio si es necesario. Use herramientas aprobadas como git filter-repo o BFG Repo-Cleaner, y coordine con los propietarios del repositorio — reescribir el historial afecta a todos los colaboradores.
7. Actualice los sistemas dependientes. Confirme que todas las aplicaciones, trabajos e integraciones estén usando el nuevo valor.
8. Documente el incidente. Registre la causa raíz, el propietario, el tiempo de remediación y qué control prevendrá la recurrencia.
9. Añada un control de prevención. Hooks pre-commit, escaneo de CI/CD, actualizaciones de políticas o revisión de acceso — al menos un cambio concreto antes de cerrar el incidente.

¿Cómo pueden las organizaciones detectar secretos codificados?

El escaneo puntual no es suficiente. Los secretos entran en los códigos base continuamente, y la detección necesita igualar ese ritmo.

El DBIR 2025 de Verizon encontró que el tiempo medio para remediar secretos filtrados descubiertos en GitHub fue de 94 días. Esa brecha existe porque la detección sin propiedad y SLAs de triaje produce fatiga de alertas, no acción. Cada secreto detectado necesita un propietario designado y una ruta de respuesta definida.

¿Cómo pueden los equipos prevenir los secretos codificados?

La prevención es un problema en capas. Ningún control individual es suficiente por sí solo.

La mayoría de las organizaciones terminan gestionando ambas categorías: secretos de máquinas para aplicaciones y pipelines, y credenciales humanas para cuentas de administrador compartidas, acceso de equipo y flujos de trabajo operativos. Mantenerlos en sistemas separados y no conectados crea sus propios problemas — políticas de acceso inconsistentes, registros de auditoría duplicados y credenciales que caen en la brecha entre herramientas. Passwork cubre ambas en una única plataforma, bajo un modelo de acceso y un registro de auditoría.

Dos categorías de credenciales, un lugar para gestionarlas

La tabla a continuación muestra dónde pertenece cada tipo de credencial.

El objetivo es asegurar que cada credencial viva en un sistema diseñado para cómo se usa realmente. Para la mayoría de los equipos, eso significa una plataforma que maneje ambas categorías — no dos herramientas separadas con modelos de acceso separados y registros de auditoría separados. Esa es la brecha que Passwork llena.

Cómo Passwork elimina los secretos codificados en toda la pila

Los secretos codificados aparecen cuando los equipos carecen de un lugar conveniente y fiable para almacenar credenciales y recuperarlas en tiempo de ejecución. Passwork elimina esa brecha. Maneja cada tipo de credencial que una organización gestiona — contraseñas de usuario, cuentas de administrador compartidas, claves API, cadenas de conexión de base de datos, claves SSH, certificados TLS y tokens de CI/CD — con el almacenamiento, control de acceso y registro de auditoría que cada categoría requiere.

La misma bóveda donde un equipo de operaciones almacena contraseñas de administrador es el mismo sistema que un pipeline de despliegue consulta para una cadena de conexión de base de datos. Un modelo de acceso, un registro de auditoría, un flujo de trabajo de rotación.

Almacenar secretos para que nunca tengan que codificarse

Passwork organiza las credenciales en una jerarquía de bóvedas estructurada. Los equipos organizan los secretos por entorno y categoría — infrastructure/production/databases, services/stripe, servers/ssh-keys — y cada nivel lleva controles de acceso independientes. Un secreto en la bóveda correcta tiene un propietario designado, una etiqueta de entorno y un conjunto definido de consumidores. Los secretos sin propietarios son los que terminan confirmados en repositorios.

Los campos personalizados soportan secretos con nombre directamente: AWS_SECRET_KEY, STRIPE_SECRET, REDIS_AUTH, OAUTH_CLIENT_SECRET. Ese nombrado alimenta la recuperación de CLI y SDK, haciendo que la bóveda se autodocumente y eliminando la confusión de configuración que lleva a los desarrolladores a codificar un valor «solo por ahora».

Inyección CLI: la alternativa directa a las variables de entorno codificadas

passwork-cli exec ejecuta cualquier comando con secretos inyectados como variables de entorno, solo durante la duración de ese comando. La credencial no aparece en el historial del shell, no escribe en disco y no persiste después de que el proceso hijo termine.

# Run deploy script — secrets exist only for the duration of this command
passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" ./deploy.sh

Esto reemplaza el archivo .env confirmado en un repositorio, el valor codificado pegado desde un mensaje de chat y la variable de entorno impresa en la salida de CI. La aplicación lee su configuración del entorno como está diseñada; la diferencia es de dónde vienen esos valores.

Para un solo valor en un script de shell:

DB_PASS=$(passwork-cli get --password-id "$ITEM_ID")
# DB_PASS is available in this shell, never written to disk

Para rotación — actualizar la credencial después de cambiarla en el sistema de destino:

passwork-cli update --password-id "$ITEM_ID" --password "$NEW_PASS"

El CLI maneja el descifrado y re-cifrado localmente. El servidor de Passwork almacena solo texto cifrado. Incluso un compromiso completo del servidor no produce nada legible.

Integración CI/CD sin codificar tokens de pipeline

Los pipelines de CI/CD son una fuente principal de secretos codificados — tokens y cadenas de conexión confirmados directamente en archivos de pipeline porque no había una mejor opción. Passwork proporciona esa opción.

La imagen Docker passwork/passwork-cli se ejecuta como imagen de trabajo en GitLab CI, GitHub Actions y Bitbucket Pipelines. El pipeline almacena solo tres credenciales de arranque en el almacenamiento de secretos de la plataforma CI: PASSWORK_HOST, PASSWORK_TOKEN y PASSWORK_MASTER_KEY. Todo lo demás vive en Passwork.

# GitLab CI — no credentials in the pipeline file
deploy_prod:
  image: passwork/passwork-cli:latest
  script:
    - passwork-cli exec --folder-id "$SECRETS_FOLDER_ID" ./deploy.sh

# GitHub Actions — credentials injected from platform secrets only
- name: Deploy with secrets
  run: |
    docker run --rm \
      -e PASSWORK_HOST="${{ secrets.PASSWORK_HOST }}" \
      -e PASSWORK_TOKEN="${{ secrets.PASSWORK_TOKEN }}" \
      -e PASSWORK_MASTER_KEY="${{ secrets.PASSWORK_MASTER_KEY }}" \
      passwork/passwork-cli:latest \
      exec --folder-id "${{ vars.SECRETS_FOLDER_ID }}" ./deploy.sh

Para Kubernetes, Passwork soporta un contenedor init que obtiene secretos antes de que la aplicación principal comience, y un sidecar que los actualiza después de la rotación — sin reiniciar el pod.

Cuentas de servicio: identidad de máquina sin dispersión de credenciales

Cada pipeline de CI/CD o script de automatización que accede a Passwork usa una cuenta de servicio dedicada con su propio rol, su propio par de tokens y acceso solo a las bóvedas que realmente necesita. Un pipeline de despliegue obtiene acceso de solo lectura a los secretos de producción. Un script de rotación obtiene acceso de lectura-escritura a la carpeta de bases de datos. Cuando un pipeline se retira, su cuenta de servicio se elimina.

Los tokens de API tienen tiempos de vida configurables. Para un trabajo de CI/CD que se ejecuta por minutos, el token de acceso vive de 15 a 60 minutos. Para un servicio de rotación siempre activo, el token de acceso se ejecuta de 1 a 4 horas y el token de actualización por 30 días. La rotación del par de tokens ocurre programáticamente vía POST /api/v1/sessions/refresh, por lo que la credencial de arranque nunca se convierte en permanentemente de larga duración.

Control de acceso que se adapta a cómo trabajan realmente los equipos

El modelo de permisos de Passwork funciona tanto a nivel de bóveda como de carpeta. Los permisos heredan hacia abajo en el árbol de carpetas pero pueden anularse en cualquier nivel. El equipo de plataforma tiene acceso completo a infrastructure/production. Los desarrolladores acceden a infrastructure/development. La cuenta de servicio de CI/CD obtiene acceso de solo lectura a la carpeta de producción que necesita.

El acceso basado en roles, los grupos y la sincronización AD/LDAP significan que cuando un ingeniero se une a un equipo, hereda el acceso a la bóveda del grupo. Cuando se va, el acceso se elimina de una vez. El panel de seguridad marca las credenciales como comprometidas cuando no han sido rotadas después de que se revocó el acceso de un usuario — detectando directamente el modo de fallo que produce secretos expuestos activos.

Las políticas de complejidad de contraseñas aplican requisitos mínimos en contraseñas maestras y contraseñas de autenticación. Las políticas de bloqueo de cuentas limitan los intentos fallidos de inicio de sesión. SAML SSO vincula el acceso a la bóveda con el proveedor de identidad existente, por lo que la autenticación de Passwork sigue el mismo ciclo de vida que cualquier otro sistema corporativo.

Registro de auditoría y arquitectura de conocimiento cero

Cada lectura, escritura y cambio de permisos se registra: qué cuenta, qué credencial, qué acción, en qué marca de tiempo. Las cuentas de servicio aparecen en el log bajo su propia identidad. El log se exporta en formato CEF para integración con SIEM, por lo que el historial de acceso de Passwork fluye a la misma plataforma de monitoreo de seguridad que los eventos de red y endpoint.

El cifrado y descifrado ocurren en el cliente — en el navegador, en passwork-cli o en el SDK. El servidor almacena solo texto cifrado. Los administradores de Passwork y los operadores de base de datos no tienen medios técnicos para leer los secretos almacenados, incluso con acceso directo a la base de datos. Para despliegues autoalojados, los datos de credenciales cifrados nunca transitan por un sistema de terceros. Passwork tiene certificación ISO 27001 y cumple con GDPR y NIS2.

Lista de verificación para prevención de secretos codificados

Conclusión

Los secretos codificados son una forma prevenible de exposición de credenciales. Los controles técnicos existen: gestores de secretos, hooks pre-commit, escaneo de CI/CD, credenciales de corta duración y acceso de mínimo privilegio. La parte más difícil es construir el flujo de trabajo que haga que las prácticas seguras sean el camino de menor resistencia para cada desarrollador en cada commit.

La defensa completa es en capas. Almacenamiento seguro para secretos de máquinas. Escaneo en cada etapa del pipeline. Políticas de rotación con propietarios definidos y SLAs. Plantillas de flujo de trabajo para desarrolladores que eliminen la fricción que causa los atajos. Y gobernanza de acceso para las credenciales humanas que viven fuera del código de aplicación — las contraseñas de administrador compartidas, credenciales de cuentas de servicio y tokens de acceso de equipo que tienden a dispersarse por canales informales cuando no existe una mejor opción.

Passwork brinda a los equipos un único sistema para almacenar, acceder, rotar y auditar cada tipo de credencial. Los desarrolladores recuperan secretos en tiempo de ejecución en lugar de pegarlos en el código. Los pipelines obtienen de una bóveda en lugar de leer de archivos confirmados. El personal de operaciones gestiona contraseñas de administrador compartidas en la misma plataforma donde DevOps maneja los secretos de infraestructura. Cuando se encuentra una credencial en un repositorio, la respuesta comienza en Passwork: revocar el valor antiguo, generar uno nuevo, actualizar los sistemas dependientes y confirmar a través del registro de auditoría que la credencial antigua ya no está en uso.

Si su equipo aún comparte contraseñas de servicio, administrador o proyecto a través de canales informales, comience centralizándolas en Passwork y definiendo quién tiene permitido acceder, rotar y revisar cada credencial. Ese único cambio elimina una categoría de riesgo que ninguna cantidad de escaneo de código detectará. Pruebe Passwork gratis

Preguntas frecuentes

¿Cuál es un ejemplo de un secreto codificado?

Una contraseña de base de datos escrita directamente en un archivo fuente, una clave de acceso de AWS en un archivo de configuración .yaml, una clave privada SSH en un script de despliegue o un secreto de firma JWT en el código de la aplicación. Cualquier credencial incrustada como un valor estático en código, un archivo de configuración, un script o un paquete de aplicación compilado califica como un secreto codificado.

¿Son los secretos codificados lo mismo que las contraseñas codificadas?

Las contraseñas codificadas son un tipo de secreto codificado. La categoría más amplia también incluye claves API, tokens OAuth, claves SSH, certificados privados, material de claves TLS, claves de cifrado y cadenas de conexión de base de datos. El CWE-798 de MITRE cubre toda la clase bajo «uso de credenciales codificadas».

¿Es seguro almacenar secretos en repositorios privados?

No. Los repositorios privados reducen la exposición pública pero no hacen que los secretos sean seguros. El acceso a menudo está disponible para muchos desarrolladores, herramientas automatizadas e integraciones. Las cuentas de desarrollador comprometidas, los permisos mal configurados, los pipelines de CI/CD, las copias de seguridad, las bifurcaciones y los clones locales amplían la superficie de exposición más allá de lo que implica «privado».

¿Es suficiente eliminar un secreto codificado del código?

No. Si el secreto fue confirmado, puede seguir existiendo en el historial de Git, las bifurcaciones, los logs de CI/CD, los artefactos de compilación, los clones locales y las copias de seguridad. Rote o revoque la credencial primero. Luego elimínela del código base y limpie el historial del repositorio si el alcance de la exposición lo justifica.

¿Son las variables de entorno suficientes para prevenir secretos codificados?

Las variables de entorno ayudan a separar la configuración del código, pero no son un control completo. Los equipos aún necesitan almacenamiento seguro para esos valores, controles de acceso, políticas de rotación y protección contra filtraciones en logs o artefactos de compilación. Las variables de entorno reducen el riesgo de secretos en archivos fuente; no reemplazan una estrategia de gestión de secretos.

¿Cuánto tiempo suelen permanecer activos los secretos filtrados?

Según el informe State of Secrets Sprawl 2026 de GitGuardian, el 64% de los secretos confirmados como válidos en 2022 seguían activos y explotables en 2026. El DBIR 2025 de Verizon encontró un tiempo medio de remediación de 94 días para secretos descubiertos en GitHub. Los tiempos de vida largos de las credenciales son la razón principal por la que un solo secreto filtrado puede causar daño sostenido.

Ciclo de vida de rotación de secretos: De la creación a la revocación

La rotación de secretos falla cuando se trata como una tarea programada en lugar de un ciclo de vida. Esta guía cubre las siete etapas — desde la creación y propiedad hasta la rotación segura, la revocación de emergencia y la evidencia de auditoría.

Passwork BlogAlex Muntyan

El estado de la dispersión de secretos en 2026: Hallazgos clave del informe de GitGuardian

28,65 millones de secretos filtrados en GitHub público en 2025. La IA está acelerando el problema. Los repositorios internos están 6 veces más expuestos que los públicos. Y el 64% de los secretos de 2022 siguen válidos hoy. Esto es lo que significan los datos para su postura de seguridad.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta se ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan