Secretos y cadena de suministro

Puedes escribir un código impecable y aun así ser vulnerable por dos vías que no están en tu código: un secreto (una contraseña de base de datos, una clave de firma, un token de API) que acaba donde no debe, y una dependencia comprometida o vulnerable. Las dos categorías están en el OWASP Top 10:2025 (A02 configuración y A03 cadena de suministro).

Analogía

Un restaurante

Nadie deja la llave bajo el felpudo pensando “nadie mirará ahí”. Y si un proveedor vende harina contaminada, el restaurante necesita saber en minutos qué platos la llevan. Las dos cosas dependen de saber dónde está cada cosa.

En el mundo realEn tu sistema

La llave del local bajo el felpudoUn secreto en el repositorio

Una caja fuerte con registro de quién la abreUn gestor de secretos con auditoría

Cambiar la cerradura si pierdes una llaveRotar el secreto filtrado

Saber qué proveedor te vendió cada ingredienteSBOM: inventario de dependencias

Una alerta sanitaria sobre un lote de harinaUn CVE en una librería que usas

Secretos: dónde NO deben estar

• En el código o en application.yml versionado. Borrarlo en el siguiente commit no sirve: sigue en el historial de git, en los forks y en las copias locales.
• En el bundle del frontend. Cualquier variable que llegue al navegador es pública, aunque se llame API_SECRET.
• En imágenes de contenedor (ENV DB_PASSWORD=… en el Dockerfile): quedan en las capas de la imagen.
• En logs, mensajes de error o URLs (?token=… acaba en logs de proxies e historiales).

Dónde SÍ

Entorno	Opción	Comentario
Desarrollo local	Fichero .env fuera de git, perfiles locales	Valores de prueba, nunca los de producción
Contenedores / Kubernetes	Secretos montados como ficheros	Spring Boot los lee con configtree
Nube	Gestor de secretos (AWS Secrets Manager, OCI Vault, Azure Key Vault, HashiCorp Vault)	Auditoría, rotación, permisos finos
CI/CD y nube	Identidad federada (OIDC) en lugar de claves de larga duración	El pipeline obtiene credenciales temporales; no hay nada que filtrar

En Spring Boot, el código solo conoce nombres, nunca valores:

application.yml

spring:
  datasource:
    url: jdbc:postgresql://db:5432/notes
    username: ${DB_USER}
    password: ${DB_PASSWORD}          # de una variable de entorno
  config:
    import: optional:configtree:/run/secrets/   # ficheros montados por Kubernetes/Docker

Idea clave

El mejor secreto es el que no existe: credenciales temporales emitidas por identidad (OIDC en CI, roles de instancia en la nube, workload identity en Kubernetes) eliminan las claves de larga duración que se pueden filtrar.

Cuando un secreto se filtra

1. Rota primero: revoca el secreto y emite uno nuevo. Asume que ya se usó; los bots escanean GitHub en segundos.
2. Revisa el uso: logs de acceso del proveedor, de la base de datos, de la nube.
3. Limpia después: reescribir el historial de git es útil, pero no sustituye a la rotación.
4. Previene: escaneo de secretos en el repositorio (GitHub push protection, gitleaks) y en CI.

La cadena de suministro

Tu aplicación Spring tiene decenas de dependencias directas y cientos de transitivas. Cada una es código que se ejecuta con tus permisos.

1. Tu código
3. Dependenciasdirectas y transitivasCVEtyposquattingdependency confusion
5. Build / CIacciones, plugins, runnersacciones sin fijartokens con demasiados permisos
7. Artefactojar, imagenimagen basefirma y procedencia

Cada eslabón es un punto de ataque: una dependencia maliciosa, una acción de CI comprometida, una imagen base vulnerable.

Lo que funciona:

• Inventario (SBOM): genera un Software Bill of Materials en cada build, por ejemplo con el plugin de CycloneDX para Maven o Gradle. Cuando salga el próximo Log4Shell sabrás en minutos si te afecta.
• Escaneo continuo: Dependabot o Renovate para actualizar; OWASP Dependency-Check, Snyk o Grype para detectar CVE. Mejor aún: usa el BOM de Spring Boot y actualiza la versión de parche con regularidad.
• Versiones fijadas: evita rangos ([1.0,), latest). Un build reproducible es un build auditable.
• Desconfía de los nombres: paquetes con nombres casi idénticos a los populares (typosquatting) y paquetes públicos con el mismo nombre que tus paquetes internos (dependency confusion).
• CI con mínimo privilegio: permisos mínimos del token del pipeline, acciones de terceros fijadas por SHA de commit (no por etiqueta), secretos solo en los jobs que los necesitan.
• Imágenes mínimas: imágenes base pequeñas (distroless, Alpine, imágenes de Paketo/Buildpacks), escaneadas, ejecutando como usuario no root.

Evita

.github/workflows/build.yml

permissions: write-all
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: some-org/setup-tool@main
      - run: ./mvnw deploy
        env:
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_KEY }}

Prefiere

.github/workflows/build.yml

permissions:
  contents: read
  id-token: write          # para OIDC con la nube
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: some-org/setup-tool@3f1c2a9b8e7d6c5b4a39281706f5e4d3c2b1a098 # v4.2.0
      - run: ./mvnw verify

Trampa común

Actualizar 'cuando haya tiempo'

Cuanto más tiempo pasa sin actualizar, más grande y arriesgado es el salto, y más tiempo pasas con vulnerabilidades conocidas y públicas. Actualizaciones de parche frecuentes y automáticas (con tests que las validen) son más seguras que una gran migración al año.

Mini lab · 15 min

Auditoría de un repositorio

Marcar como completado

Objetivo: Encontrar los problemas de secretos y de cadena de suministro en tres ficheros de un proyecto.

application-prod.yml

spring:
  datasource:
    password: Pr0d-2026!
app:
  jwt-secret: c3VwZXItc2VjcmV0LWtleQ==

Dockerfile

FROM eclipse-temurin:latest
ENV STRIPE_KEY=sk_live_51H...
COPY target/app.jar /app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

pom.xml (extracto)

<dependency>
  <groupId>com.example</groupId>
  <artifactId>internal-utils</artifactId>
  <version>[1.0,)</version>
</dependency>

Encuentra al menos cinco problemas y di cómo corregirías cada uno. Bonus: el secreto de producción lleva tres meses en el repositorio, ¿qué haces primero?

Pista

Revisa cada fichero con dos preguntas: ¿hay algún valor secreto escrito? ¿Hay algo que no esté fijado a una versión concreta?

Mostrar respuestaOcultar respuesta

1. Contraseña de base de datos en el YAML versionado → variable de entorno o gestor de secretos.
2. Secreto JWT en el YAML (y Base64 no es cifrado) → gestor de secretos; mejor aún, firmar con clave asimétrica guardada en un KMS.
3. Clave de Stripe en el Dockerfile (ENV) → queda en las capas de la imagen; inyectarla en tiempo de ejecución.
4. Imagen base latest → versión fija (y a ser posible por digest), una imagen mínima, escaneada, y ejecutar como usuario no root.
5. Rango de versiones [1.0,) → build no reproducible y riesgo de dependency confusion si un paquete público usa ese nombre. Versión fija y repositorio interno configurado para esos groupId.

Bonus: rotar ya la contraseña de la base de datos, el secreto JWT (invalidará los tokens emitidos) y la clave de Stripe; después revisar los registros de uso de esos tres meses, y solo entonces limpiar el historial y activar el escaneo de secretos.

En resumen

• Los secretos no van en el código, en el frontend, en imágenes ni en logs; van en un gestor de secretos o, mejor, se sustituyen por credenciales temporales.
• Si un secreto se filtra: rotar primero, investigar después, limpiar al final.
• SBOM, escaneo continuo, versiones fijadas y actualizaciones frecuentes para las dependencias.
• CI con permisos mínimos, acciones fijadas por SHA e imágenes mínimas.