Tensorlake comprometido: cómo blindar tu cadena de suministro en npm y no morir entre dependencias

Cuando explotó el caso de Tensorlake en npm, muchos equipos se hicieron la misma pregunta incómoda:

“Si mañana un paquete crítico de nuestro stack está comprometido, ¿nos enteramos a tiempo o nos enteramos por Twitter?”

Si la respuesta te incomoda, este post es para ti.

En lugar de repasar la noticia, vamos a usar el incidente de Tensorlake como excusa para construir un plan práctico: cómo blindar (de verdad) tu cadena de suministro en npm y qué hacer en las primeras 24 horas cuando algo huele a quemado.

Referencia del incidente: Tensorlake npm package compromised to steal credentials.

1. ¿Qué nos enseña el caso Tensorlake (sin hacer de periodista)?

El ataque a Tensorlake no es “una rareza más”: encaja en un patrón cada vez más común en el ecosistema JavaScript/TypeScript:

Paquete popular → alta superficie de ataque.
Un actor malicioso consigue publicar una versión troyanizada.
El malware apunta a credenciales: tokens de nube, API keys, variables de entorno sensibles.
El daño se amplifica porque el paquete vive en el corazón del stack (frameworks, SDKs de cloud, librerías de ML, etc.).

Más que memorizar los detalles concretos, vale la pena extraer 3 ideas operativas:

La pregunta no es si te afectará un incidente, sino cuándo.
Tu mayor problema no es que exista malware, sino no detectarlo rápido.
La superficie real de riesgo no es tu código, son tus dependencias (y sus dependencias).

A partir de aquí, hablemos de cosas accionables.

2. Cómo detectar paquetes comprometidos antes de que te arrastren

No vas a leer cada línea de cada dependencia. Pero sí puedes diseñar un “radar” para detectar comportamientos raros.

2.1 Señales de alerta en tu día a día

Empieza por normalizar estas preguntas en las PR que tocan package.json:

¿Por qué necesitamos este paquete? ¿Aporta algo claro o es “por costumbre”?
¿Quién lo mantiene? ¿Es un proyecto activo, con comunidad, con releases razonables?
¿Qué incluye realmente? ¿Has mirado el repo o el contenido del paquete publicado?
¿Tiene binarios, scripts de instalación o postinstall raros? Es un vector clásico para colar malware.

Antes de instalar algo nuevo: inspecciona mínimamente.

# Ver qué trae el paquete publicado (sin instalarlo en tu proyecto)
npm view tensorlake dist.tarball
curl -L "$(npm view tensorlake dist.tarball)" | tar -tz

Busca cosas sospechosas, como:

Ficheros ejecutables inesperados (.exe, binarios, scripts extraños en bin/).
Código que toca process.env, fs, net, http sin que la librería lo justifique.

2.2 Monitoriza tus propias instalaciones

No confíes solo en la fase de CI. Puedes detectar cosas raras ya en desarrollo:

# Instala mostrando logs verbosos
npm install --verbose

Evita (o revisa con lupa) paquetes que:

Ejecutan scripts en preinstall, install, postinstall sin documentación clara.
Descargan binarios externos en la instalación.

Ejemplo de revisión rápida en un package.json instalado:

cat node_modules/tensorlake/package.json | jq '.scripts'

Si ves scripts que no encajan con el propósito del paquete, bandera roja.

3. Diseñar políticas de dependencias que no te ahoguen

La mejor defensa es que tu árbol de dependencias sea razonable y entendible. No es solo seguridad; también es mantenibilidad.

3.1 Versionado: menos magia, más control

Evita el clásico "^1.2.3" en producción para paquetes críticos.

Recomendación práctica:

Dependencias core de negocio / infra: fija versión exacta ("1.2.3") y actualiza por PR explícita.
Dependencias menores (dev, tooling): puedes permitir ^ pero con bots de actualización controlados.

Ejemplo de package.json más estricto:

{
  "dependencies": {
    "tensorlake": "1.4.2",     // fijado
    "zod": "^3.23.5"           // menos crítico, semver ok
  },
  "devDependencies": {
    "eslint": "^9.0.0"
  }
}

Y complementa con un lockfile (package-lock.json o pnpm-lock.yaml) commiteado siempre.

3.2 Reglas de oro para aceptar dependencias

Define (y documenta) criterios explícitos. Por ejemplo:

No se añaden dependencias con menos de 100k descargas semanales o menos de 200 estrellas sin una revisión manual extra y justificación en la PR.
No se permiten dependencias que:
- No tengan repositorio público enlazado.
- No tengan licencia clara.
- No hayan tenido ningún cambio en > 2 años si son críticas.
No se aceptan paquetes duplicados para el mismo problema (dos libs de fechas, etc.).

Escribe estas reglas en un SECURITY.md o ARCHITECTURE.md en tu repo. Sin documento, la política no existe.

3.3 Menos es más: dieta de dependencias

Cada dependencia es una puerta más que vigilar. Algunas prácticas útiles:

Cada vez que añadas una lib, plantéate: “¿podría hacer esto con estándar de Node/TS?”
Programa limpiezas periódicas de dependencias: quita lo que ya no uses.
Evita los meta-packages gigantes si solo usas una pieza pequeña.

Una tarea recurrente útil:

npx depcheck

Revisa qué dependencias no se usan realmente y elimínalas.

4. Automatizar escaneos: malware, vulnerabilidades y credenciales

No basta con “pasar el ojo”. Necesitas herramientas automáticas que salten cuando algo va mal.

Piensa en tres capas:

Vulnerabilidades conocidas (CVEs, advisories).
Comportamiento sospechoso / malware.
Fugas de secretos y credenciales.

4.1 Vulnerabilidades en dependencias

Opciones típicas en ecosistema npm:

npm audit integrado.
Servicios externos (Snyk, GitHub Dependabot, etc.). Define al menos una herramienta estándar y hazla obligatoria en todos los repos.

Ejemplo mínimo con npm audit en CI (GitHub Actions):

name: security-audit

on:
  schedule:
    - cron: '0 3 * * *' # diario
  workflow_dispatch:

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm audit --audit-level=high

4.2 Escaneo de comportamiento sospechoso / malware

Aquí el objetivo no es solo CVEs, sino qué hace realmente el paquete:

Ideas prácticas:

Analizar los ficheros de los paquetes en node_modules buscando patrones peligrosos.
Inspeccionar scripts de instalación.

Ejemplo muy simplificado en Node.js para detectar accesos a process.env + envío HTTP (patrón típico de exfiltración):

import fg from "fast-glob";
import fs from "node:fs/promises";

async function findSuspiciousPatterns(root = "node_modules") {
  const files = await fg(["**/*.js"], { cwd: root, absolute: true });

  for (const file of files) {
    const content = await fs.readFile(file, "utf8");

    const touchesEnv = content.includes("process.env");
    const doesNetworkCall = /(axios|fetch|http\.request|https\.request)/.test(content);

    if (touchesEnv && doesNetworkCall) {
      console.log(`Posible patrón de exfiltración en: ${file}`);
    }
  }
}

findSuspiciousPatterns().catch(console.error);

No es un antivirus, pero puede destapar cosas raras si lo ejecutas:

Como job manual cuando salta una alerta.
Periódicamente en entornos sensibles.

4.3 Escaneo de secretos y credenciales en tu código

El caso Tensorlake nos recuerda que las credenciales son el premio gordo. Protege ambos lados:

Que las dependencias no puedan leer más de lo necesario.
Que tus repos no filtren secretos sin querer.

Para lo segundo, añade un escáner de secretos, por ejemplo en un hook de pre-commit:

# Ejemplo con gitleaks (se puede adaptar a otra herramienta)
cat << 'EOF' > .git/hooks/pre-commit
#!/bin/sh

if command -v gitleaks >/dev/null 2>&1; then
  echo "[pre-commit] Ejecutando gitleaks..."
  gitleaks protect --staged
  if [ $? -ne 0 ]; then
    echo "[pre-commit] Posible secreto detectado. Commit abortado."
    exit 1
  fi
fi
EOF

chmod +x .git/hooks/pre-commit

Además:

Usa variables de entorno con gestores de secretos (Vault, AWS Secrets Manager, etc.).
Segmenta permisos: la app no debería tener una key “root” de tu cloud.

5. Qué hacer en las primeras 24 horas si un paquete crítico está comprometido

Aquí es donde el caso Tensorlake duele de verdad: ¿qué haces cuando te enteras de que un paquete que usas ha sido infectado?

Vamos a plantear un playbook de 24 horas. Adáptalo a tu contexto y documenta la versión oficial para tu equipo.

5.1 Hora 0–2: Contención inmediata

Objetivo: parar el sangrado.

Congela despliegues de servicios afectados.
Bloquea instalaciones nuevas del paquete comprometido:
- Si usas un registry privado / proxy (Artifactory, Verdaccio, etc.), banea la versión maliciosa.
- Si tiras directamente de npm, añade una overrides temporal en package.json para forzar una versión segura o un fork.
```
{
  "overrides": {
    "tensorlake": "1.4.1" // última versión conocida como segura
  }
}
```
Identifica el alcance:
- ¿En qué repos aparece el paquete? (usa grep, rg, o búsqueda global en tu monorepo).
- ¿En qué servicios está desplegado?
```
rg "tensorlake" .
```
Levanta un canal de incidente (Slack, Teams) y nombra un incident commander. Sin una persona coordinando, pierdes tiempo.

5.2 Hora 2–8: Análisis rápido y decisiones duras

Objetivo: entender si hay exfiltración y qué credenciales peligran.

Identifica las versiones afectadas según el advisory del paquete / noticia oficial.

Revisa el diff entre la versión buena y la mala:

Descarga ambas versiones desde npm.
Compara su contenido:

mkdir /tmp/tensorlake-safe /tmp/tensorlake-bad

curl -L "$(npm view [email protected] dist.tarball)" | tar -xz -C /tmp/tensorlake-safe --strip-components=1
curl -L "$(npm view [email protected] dist.tarball)" | tar -xz -C /tmp/tensorlake-bad --strip-components=1

diff -ru /tmp/tensorlake-safe /tmp/tensorlake-bad | less

Busca exfiltración de datos en el código malicioso:
- ¿Lee process.env?
- ¿Accede a ficheros con claves (.env, config, credentials)?
- ¿Hace peticiones HTTP salientes a dominios raros?
Clasifica el riesgo:
- Alta: hay código que claramente envía secretos fuera.
- Media: hay telemetría sospechosa pero no obvia.
- Baja: parece solo un “experimento roto”, pero viene de un compromiso real del paquete.
Decide scope de rotación de credenciales:
- Si el riesgo es alto, asume que todas las credenciales accesibles por el proceso están comprometidas.

5.3 Hora 8–16: Rotación de credenciales y limpieza

Objetivo: reducir el impacto futuro.

Prioriza la rotación de credenciales:
- Tokens de producción y entornos con datos sensibles primero.
- Luego staging, desarrollo compartido, etc.
Automatiza lo posible:
- Usa scripts/CLI del proveedor para rotar claves.
- Evita hacerlo manual clave por clave si tienes muchas.
Re-deploy servicios con:
- Versión segura del paquete (o fork interno temporal).
- Nuevas credenciales.
Recoge evidencias de logs:
- Busca tráfico saliente hacia los dominios/IP identificados en el análisis del paquete.
- Si tienes un proxy de salida, analízalo.

5.4 Hora 16–24: Comunicación y hardening

Objetivo: cerrar el incidente sin dejar cabos sueltos.

Escribe un informe interno breve:
- Qué pasó.
- Qué impacto real se ha identificado.
- Qué acciones se han tomado.
- Qué mejorar en el proceso.
Ajusta tus políticas de dependencias a la luz de lo ocurrido:
- ¿Necesitas fijar más versiones?
- ¿Añadir un registry privado / caché con validaciones?
- ¿Introducir revisiones adicionales para paquetes “core”?
Actualiza runbooks y playbooks con lo que has aprendido para el siguiente incidente.

6. Checklist rápido para tu equipo Node/TypeScript

Si quieres pasar de “deberíamos hacer algo” a “hacemos esto desde hoy”, aquí tienes un checklist accionable:

package-lock.json o equivalente siempre commiteado.
Versiones fijas para dependencias críticas.
Política escrita de aceptación de dependencias.
npm audit (o equivalente) corriendo en CI con alertas.
Escáner de secretos integrado (pre-commit y/o CI).
Proceso documentado de rotación de credenciales.
Playbook de “paquete comprometido” accesible para todo el equipo.

7. Conclusión: usar Tensorlake como simulacro, no como excusa

El incidente de Tensorlake es otro recordatorio de que tu seguridad no termina en tu código. Cada npm install arrastra decisiones de confianza que rara vez hacemos explícitas.

No puedes evitar que existan paquetes comprometidos, pero sí puedes:

Reducir tu superficie de dependencia.
Detectar comportamientos anómalos antes de que escalen.
Reaccionar con un plan claro cuando algo explota.

Toma el caso Tensorlake como un simulacro: revisa hoy tu política de dependencias y define cómo se ve para tu equipo el “primer día” de un incidente. Cuando llegue el siguiente, te alegrarás de haberlo hecho en frío.