Secret scanning

¿Qué es el escaneo de secretos?

El secret scanning, o escaneo de secretos, es la práctica automatizada de revisar código, configuración, infraestructura, pipelines y otros lugares donde los equipos almacenan y comparten información sobre software, con el fin de detectar credenciales expuestas. Un programa creíble va más allá de ejecutar un regex sobre un repositorio: te dice qué se encontró, si el valor sigue activo, dónde aparece, quién necesita actuar y con qué rapidez.

Los secretos no son lo mismo que los datos sensibles

Vale la pena dejar clara esta distinción desde el principio, porque determina cómo los equipos piensan tanto en la detección como en la respuesta. Los datos sensibles (p. ej., el número de tarjeta de crédito de un cliente, un identificador nacional, un historial médico) describen información sobre personas que debe protegerse. Los secretos, por otro lado, son credenciales o claves que otorgan acceso a distintos sistemas. Una clave API para un proveedor de pagos es un secreto; el número de tarjeta que esa clave permite procesar es un dato sensible. Ambos merecen protección, pero tienen modelos de amenaza y enfoques de gestión de seguridad diferentes.

Los valores que busca el escaneo de secretos suelen caer en un conjunto familiar: contraseñas, claves API, claves de acceso a la nube, claves privadas SSH, tokens OAuth, cadenas de conexión a bases de datos, claves de cifrado, certificados de seguridad y URL de webhooks que, a menudo, otorgan suficiente acceso como para merecer el mismo tratamiento. Muchos tienen formas reconocibles; por ejemplo, una clave de Stripe empieza con un prefijo conocido, una clave de acceso de AWS sigue un formato fijo y una clave privada se sitúa entre líneas de encabezado y de pie de página predecibles.

Por ejemplo, una clave privada SSH podría verse así:

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

-----BEGIN OPENSSH PRIVATE KEY-----
[long encoded key content]
-----END OPENSSH PRIVATE KEY

Esos patrones ayudan, pero no bastan por sí solos; la detección moderna tiene que manejar una variedad mucho mayor.

¿Por qué ocurren las exposiciones de secretos?

La historia habitual es mundana: un desarrollador incrustó un token a mano para probar una integración localmente y pensó en quitarlo antes de enviar el código (hacer push). Un equipo con poco tiempo decidió: "Lo moveremos al vault (bóveda) en el próximo sprint." Un nuevo ingeniero del equipo no sabía que existía la bóveda. Un asistente de programación con IA produjo un ejemplo funcional de integración de una API con una credencial de marcador de posición; el desarrollador insertó una clave real para que funcionara y el archivo fue "committeado".

Luego el valor se propaga. Una vez que una credencial entra en el historial de un repositorio, eliminarla de la versión más reciente de un archivo no deshace la exposición. La cadena sigue viva en commits anteriores, en ramas que aún no se han fusionado, en copias en los portátiles de otras personas, en forks espejados. Si el repositorio es público, es probable que los raspadores (scrapers) automáticos lo encuentren en cuestión de minutos — las plataformas de búsqueda, los actores maliciosos y los investigadores de seguridad ejecutan sus propios escáneres sobre hosts públicos de Git en busca precisamente de esto. Si el repositorio es privado, cualquiera con acceso de lectura, incluidos los colaboradores anteriores, aún puede recuperarla.

El código está lejos de ser la única fuente. Los archivos de configuración, los pipelines de CI/CD, las imágenes de contenedores, los manifiestos de Kubernetes, el estado de Terraform, los charts de Helm, los scripts de despliegue, los registros de ejecución, las plataformas de observabilidad como Datadog, los canales de Slack, los tickets de Jira, las páginas de Confluence y la documentación de onboarding pueden contener credenciales que nunca debieron estar allí.

Aquí tienes un ejemplo pequeño, bastante común: un trabajo de copia de seguridad escrito como un script de shell rápido:

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

#!/bin/bash
# Nightly backup of the orders DB to S3
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

pg_dump -h db.internal -U backup_user -d orders \
    | gzip \
    | aws s3 cp - "s3://acme-backups/orders/$(date +%F).sql.gz"

A primera vista, nada en este script parece inusual — cumple su función. Pero cualquiera con acceso al archivo (o al artefacto de compilación en el que termina, o al registro de ejecución) obtiene dos credenciales de AWS y una vía de acceso al bucket de copias de seguridad de producción. Un escáner que analiza el archivo marca ambas claves: la clave de acceso por su prefijo AKIA y la clave de acceso secreta por su valor de alta entropía tras una asignación AWS_SECRET_ACCESS_KEY.

¿Por qué importa esto a nivel empresarial?

Los atacantes buscan credenciales expuestas porque funcionan. Una clave de nube filtrada puede permitir crear recursos, extraer datos o ejecutar "criptomineros" a costa de otra persona. Una contraseña de base de datos filtrada puede llevar a una notificación de brecha. Un token filtrado de una plataforma Git puede permitir a un atacante insertar código en un repositorio o manipular un pipeline de CI (un incidente de cadena de suministro en potencia). Una URL de webhook filtrada puede bastar para desencadenar flujos de trabajo internos o leer mensajes que no estaban destinados a ojos externos.

Las consecuencias posteriores son familiares para cualquiera que haya estado cerca de un incidente: toma de cuentas, uso no autorizado de la nube, brechas de datos, movimiento lateral, compromiso de la cadena de suministro, interrupción del servicio y los costos financieros asociados a todo lo anterior. Los marcos regulatorios añaden otra capa: PCI DSS, GDPR, HIPAA, SOX, FISMA y CCPA imponen requisitos sobre controles de acceso y sobre el manejo de credenciales y datos de clientes. Un patrón recurrente de secretos expuestos es difícil de defender durante una auditoría y, aun más, después de una brecha.

Para los ejecutivos, la cuenta es sencilla. El escaneo de secretos es relativamente barato de ejecutar; el costo de un incidente impulsado por credenciales (es decir, forense, notificación, remediación, pérdida de confianza, posibles multas) normalmente no lo es.

¿Cómo funciona el escaneo de secretos?

A menudo se emplean varias técnicas en conjunto. Cada una tiene fortalezas y modos de falla conocidos, por lo que ningún producto serio se apoya en una sola de ellas.

Las expresiones regulares (también conocidas como regex) son el enfoque más antiguo. Una regla describe la forma de un tipo concreto de credencial (p. ej., una clave de Stripe, una clave de acceso de AWS, un bloque de clave privada, un JWT) y el escáner busca coincidencias. Esto funciona bien cuando los proveedores publican formatos estables y mal cuando no lo hacen, y genera falsos positivos siempre que una cadena se parece a una credencial sin serlo.

El análisis de entropía plantea la pregunta opuesta: no "¿coincide con un formato conocido?" sino "¿esto parece aleatorio?" Los secretos generados por un CSPRNG tienen una entropía de Shannon mediblemente alta; también la tienen los hashes, los identificadores y los blobs codificados en base64 — y ahí está el problema.

Los diccionarios y las bibliotecas de patrones reducen parte de esa ambigüedad al comparar valores y texto circundante con catálogos de tipos de credenciales conocidos y convenciones de nomenclatura. Una cadena de alta entropía asignada a una variable llamada password en un archivo de despliegue de producción se trata de forma muy distinta de la misma cadena en un fixture de pruebas.

El análisis contextual va aún más lejos, examinando rutas de archivo, comentarios, mensajes de commit y código circundante para determinar cuánto peso asignar a un hallazgo. El machine learning, entrenado con ejemplos etiquetados, puede captar señales más sutiles que las reglas fijas pasan por alto (p. ej., formas extrañas de tokens, ubicaciones inusuales y patrones en la forma en que un equipo particular tiende a filtrar secretos).

Considera lo que un escaneo por capas podría encontrar en un fragmento de código Python:

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

import openai
from twilio.rest import Client

# TODO: move these to env vars before merging
openai.api_key = "sk-proj-aB3xQ9pD7eL5kN2mR8tVfWxYzC1H4jK6oP3sU0vZ"
account_sid = "AC1234567890abcdef1234567890abcdef"
auth_token  = "your_auth_token_3a8f5e2d1c9b7a6e4d2f0b8a"

client = Client(account_sid, auth_token)

def notify(user_phone, msg):
    return client.messages.create(
        body=msg,
        from_="+15555550123",
        to=user_phone,
    )

Tres credenciales en unas pocas líneas: una clave API de OpenAI con el prefijo sk-proj- (coincidencia por regex), un SID de Twilio con su forma conocida (regex más diccionario) y un token de autenticación (entropía más un nombre de variable en el diccionario). El comentario TODO es el tipo de señal contextual que aumenta aún más la confianza: los humanos dejan huellas cuando planean arreglar algo después y lo olvidan.

Las herramientas potentes combinan estos métodos. El escaneo híbrido ejecuta regex, entropía, diccionarios, contexto y ML en conjunto, aprovechando las fortalezas de cada método para compensar las debilidades de los demás. Aquí también es más probable detectar un secreto ofuscado o dividido (un token reconstruido a partir de dos variables, por ejemplo, o una clave codificada en base64).

Algunas herramientas dan un paso adicional: la validación en vivo. Después de marcar un candidato, el escáner realiza una llamada segura al proveedor correspondiente para verificar si la credencial sigue activa. La idea no es confirmar cada coincidencia; es clasificar y priorizar. Una clave de AWS de producción activa con permisos de administrador debe ir a la cabeza de la cola; un token de prueba caducado de hace dos años no.

¿Dónde buscar secretos?

El código fuente es el punto de partida obvio, pero un programa que se detiene ahí se perderá la mayor parte de la superficie de exposición. El escaneo debe abarcar todas las ramas, no solo la predeterminada, y también debe examinar el historial de commits porque un secreto eliminado del archivo actual puede seguir existiendo en commits anteriores, clones y forks.

Los activos de configuración y despliegue son la siguiente prioridad. Los archivos .env, las configuraciones YAML, los manifiestos de Kubernetes, los charts de Helm, Terraform, los Dockerfiles y las definiciones de pipelines de CI/CD acumulan credenciales con frecuencia. Las imágenes de contenedores las almacenan en capas que sobreviven mucho después de que el código fuente haya sido limpiado. Un manifiesto simple de Kubernetes es ilustrativo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-service
spec:
  template:
    spec:
      containers:
      - name: orders
        image: acme/orders:1.4.2
        env:
        - name: DATABASE_URL
          value: "postgres://orders_app:[email protected]:5432/orders"
        - name: STRIPE_API_KEY
          value: "sk_live_4eC39HqLyjWDarjtT1zdp7dcEXAMPLE"

Dos filtraciones en ocho líneas (una cadena de conexión a base de datos y una clave live de Stripe), ambas "committeadas" en un manifiesto que probablemente termine en control de versiones y en un registro de contenedores. Un escáner detecta la clave de Stripe por su prefijo sk_live_ y la URL de la base de datos por su estructura.

Más allá de la infraestructura, los secretos aparecen en herramientas de colaboración (p. ej., mensajes de Slack y Teams, tickets de Jira, páginas de Confluence, plataformas de soporte) y en sistemas de observabilidad, donde las trazas de pila (stack traces) y los registros de depuración a veces incluyen encabezados de autorización o volcados de variables del entorno. Los repositorios de artefactos, copias de seguridad y almacenes de datos pueden contener compilaciones y capturas antiguas con credenciales que nadie recordó rotar.

Dos modos de escaneo cubren este terreno. Los escaneos en reposo se centran en el riesgo acumulado en ubicaciones estáticas e históricas; los escaneos en tiempo real examinan nuevos commits, pull requests, ejecuciones de CI, tickets y mensajes de chat a medida que ocurren. Ambos importan: la línea base histórica te dice dónde estás, y los controles en tiempo real evitan que las cosas empeoren.

Integrar el escaneo en el flujo de desarrollo

El escaneo de secretos funciona mejor como un control continuo, no como una auditoría trimestral; cuanto antes se detecta una credencial, menos cuesta remediarla.

Los hooks de pre-commit se ejecutan en la máquina del desarrollador y advierten antes de que un secreto salga del entorno de trabajo. La protección de push se sitúa del lado de la plataforma y bloquea los pushes que contienen hallazgos de alta confianza. Los checks de pull request marcan o bloquean credenciales antes de que se fusionen, a menudo con comentarios en línea. La integración en CI/CD escanea compilaciones, scripts de despliegue y artefactos como parte del pipeline. Los plugins del IDE pueden ofrecer retroalimentación mientras se escribe el código.

Los hallazgos que pasan por esos controles o que surgen de escaneos en reposo de material histórico requieren un proceso de triaje. Categorizar por tipo de credencial, validez, ubicación, antigüedad, permisos, entorno e impacto en el negocio permite a los equipos de seguridad asignar el trabajo de manera eficiente. La automatización se encarga del enrutamiento; las personas gestionan los casos ambiguos y los patrones recurrentes que sugieren algo más profundo que un error aislado.

Cómo responder cuando se encuentra un secreto

La primera pregunta es qué otorga realmente la credencial. Un token de analítica de solo lectura, una contraseña de un servicio interno, una clave de administrador en la nube y un valor de prueba expirado desde hace mucho tiempo se sitúan en puntos muy distintos de la curva de riesgo. Identifica el servicio, el entorno, los permisos y el tiempo de exposición, así como si el valor era visible públicamente o estaba restringido a sistemas específicos.

Después, revoca o rota. En la mayoría de los casos, la rotación es el camino más limpio: invalida el valor antiguo, genera uno nuevo y actualiza a los consumidores para que lo usen. Si el secreto alguna vez fue público, asume que fue copiado. Quitar el texto de un archivo no es suficiente; la exposición ya ha ocurrido.

La investigación corre en paralelo. Los registros, las pistas de auditoría y los recuentos de actividad del proveedor pueden mostrar si la credencial se usó de formas inesperadas, desde ubicaciones inusuales o contra recursos inusuales. Si los permisos eran amplios, la revisión debe extenderse a los sistemas posteriores. El principio de menor privilegio limita el radio de impacto, pero solo cuando la credencial expuesta tenía privilegios limitados desde el inicio.

Luego viene la limpieza. Elimina el valor del código, la configuración, la documentación, los registros y cualquier otro lugar donde aparezca. Si aterrizó en el historial de Git, puede ser necesario reescribir el historial, invalidar los cachés y comunicarlo a cualquiera que haya podido clonar el repositorio. Después, documenta el incidente (qué ocurrió, cuándo se detectó, qué se hizo y qué debería cambiar) con fines de auditoría y para el aprendizaje del propio equipo.

El escaneo es una capa; la gestión de secretos es la base

Conviene repetirlo porque a menudo se confunde: el escaneo de secretos es una capa de detección, no un sustituto de la gestión de secretos. Las credenciales deben almacenarse en gestores de secretos dedicados (p. ej., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager) y recuperarse en tiempo de ejecución mediante APIs, en lugar de ser "committeadas" junto con el código que las utiliza.

Las variables de entorno suelen ser más seguras que los valores incrustados, pero no constituyen la meta final. Aun así, pueden filtrarse a través de registros, mensajes de error, endpoints de depuración, volcados de artefactos y archivos .env que acaban en commits. Los archivos de secretos locales deben ir en .gitignore, y los desarrolladores se benefician de una guía escrita clara sobre una configuración local segura.

El principio de menor privilegio es la otra mitad del panorama. Una credencial debería conceder solo lo que necesita, expirar cuando sea posible, rotarse según un calendario y registrarse al usarla. Una política que codifique estas expectativas (qué cuenta como secreto, dónde se ejecuta el escaneo, cómo se clasifican los hallazgos, quién asume la remediación y qué plazos aplican según la severidad) convierte una práctica ad hoc en algo que una organización puede auditar y mejorar.

La educación cierra el ciclo. Los desarrolladores y los ingenieros de plataforma se benefician de entender por qué el hardcoding es riesgoso, cómo funciona realmente el historial de Git y qué hacer cuando cometen un error. Las auditorías manuales y las pruebas de penetración cubren las brechas que las herramientas automatizadas pasan por alto.

Limitaciones sobre las que conviene ser honestos

El escaneo de secretos produce falsos positivos. Identificadores con aspecto aleatorio, hashes, datos de ejemplo y valores de marcador de posición son señalados. Demasiadas alarmas falsas conducen a fatiga de alertas, que a su vez lleva a ignorarlas. También produce falsos negativos: un escáner puede pasar por alto una credencial dividida entre archivos, codificada, en un formato desconocido o enterrada en una estructura de datos que el analizador no entiende bien.

La exposición histórica es aún más difícil. Un secreto enviado una vez y "eliminado" después sigue viviendo en el historial de commits, clones, forks, backups y artefactos de compilación. Por eso, bloquear una filtración en el momento del commit vale más que detectarla después.

La precisión es un equilibrio entre "precision" (la mayoría de los valores marcados son secretos reales) y "recall" (se pasan por alto pocos secretos reales). La mayoría de las organizaciones preferiría investigar algunos falsos positivos antes que perder una credencial que otorga acceso a producción. Ajustar las reglas al stack de la organización (sus proveedores de nube reales, formatos internos de tokens, convenciones de datos de prueba) es lo que permite mejorar ambas métricas a la vez.

Cómo elegir una herramienta y dónde encaja en AppSec

Cuatro dimensiones importan al elegir un escáner: cobertura, integración, calidad de detección e informes.

Cobertura significa escanear los lugares donde realmente aparecen los secretos: repositorios, IaC, CI/CD, contenedores, artefactos, herramientas de colaboración y registros. Integración significa trabajar con las plataformas de origen, los sistemas de compilación, los IDE y las herramientas de seguridad ya en uso, junto con rutas de feedback amigables para desarrolladores (avisos en el IDE, escaneos por CLI, comentarios en PR, hooks de pre-commit) y flujos de trabajo del equipo de seguridad (paneles, asignación, estado, evidencia, trazas de auditoría).

La calidad de detección proviene de métodos por capas, personalización para patrones internos y, cuando corresponde, ML y validación en vivo. Los informes deben producir los artefactos que requerirá una auditoría de cumplimiento y las métricas que necesita un líder de seguridad para monitorear la salud del programa.

El escaneo de secretos se sitúa junto a otras prácticas de AppSec en lugar de reemplazarlas. SAST busca patrones de codificación inseguros; SCA encuentra vulnerabilidades conocidas y problemas de licencia en dependencias; DAST y las pruebas de penetración evalúan sistemas en ejecución. El escaneo de secretos aborda una clase de riesgo distinta — las credenciales que conectan el software con todo lo que lo rodea — y las categorías se complementan entre sí. Por ejemplo, una herramienta SAST puede señalar un código de autenticación inseguro en un servicio, mientras que el escaneo de secretos detecta el token en vivo incrustado en el mismo archivo.

Conclusión

El software moderno depende de credenciales, y las credenciales pueden acabar en lugares donde no deberían estar. El escaneo de secretos las detecta — temprano cuando es posible, históricamente cuando es necesario — y alimenta los hallazgos en un proceso que revoca, rota, investiga y limpia. Funciona mejor con una cobertura amplia, controles en tiempo real que bloquean filtraciones antes de que se propaguen, una detección precisa mediante múltiples métodos, validación segura para priorizar credenciales activas y una base sólida de gestión de secretos subyacente. Para un líder de seguridad o de desarrollo, la pregunta es si la configuración actual detecta credenciales antes de que se propaguen, si cubre los lugares donde las filtraciones realmente ocurren y si la organización tiene un lugar más seguro para que esas credenciales se conserven.