Saltar al contenido principal
Version: 1.0.0

Seguridad y tratamiento de datos

📄 ¿Prefiere sin conexión? Descargue esta guía en PDF.

DepCheck es una herramienta de seguridad, por lo que se le exigen los estándares propios de una herramienta de seguridad. Esta página explica con claridad cómo te autentica, qué hace con los datos que le envías y qué sale — y qué no sale — del perímetro de Cert-IX.

Autenticación

  • Cada petición a https://mcp.cert-ix.com/depcheck debe llevar una clave de API válida en Authorization: Bearer <key>. Las peticiones sin ella reciben 401; el backend nunca ve tráfico no autenticado.
  • Las claves se emiten por cliente a través de tu equipo de cuenta de Cert-IX. Trata una clave como una contraseña: guárdala en la configuración de tu cliente MCP o en un almacén de secretos, nunca en el control de versiones, y rótala si es posible que se haya filtrado.
  • Todo el tráfico viaja sobre TLS. No envíes claves ni manifiestos por HTTP plano.

Límites de tasa y protección frente a abusos

El endpoint alojado aplica límites en el borde (host nginx), antes de realizar ningún trabajo:

ÁmbitoLímite
Por clave de API20 peticiones/segundo (ráfaga breve hasta 40), 20 conexiones concurrentes
Por IP de origen40 peticiones/segundo (ráfaga 80), 40 conexiones concurrentes

Superar un límite devuelve 429 Too Many Requests — reduce el ritmo y reintenta. Estos techos están holgadamente por encima del uso normal de un agente (unas pocas comprobaciones por edición); existen para frenar avalanchas, no para estrangular el trabajo real.

Los fallos de autenticación repetidos se tratan como abuso: una IP que produce muchos 401 en una ventana breve queda bloqueada temporalmente (fail2ban). El titular de una clave válida nunca llega a esto, porque una clave correcta nunca devuelve 401.

Qué envías y qué ocurre con ello

Las herramientas de DepCheck son búsquedas de solo lectura. Esto es exactamente para qué se usa cada tipo de entrada:

EnvíasQué hace DepCheck con ello
Una coordenada de paquete (ecosystem, name, version)La busca contra los datos de advisories y devuelve las advisories coincidentes.
Un cuerpo de manifiesto (manifest_content)Lo analiza en memoria para extraer los pares nombre/versión de paquete y después los busca. Se usa para producir tu resultado y no se persiste como documento almacenado.
Un ID de advisory / CVEBusca su detalle o su inteligencia de explotación.

DepCheck extrae coordenadas (qué paquetes, qué versiones) de un manifiesto — no necesita, no quiere ni analiza tu código fuente, y el servidor alojado no tiene acceso a tu sistema de archivos en absoluto (por eso recibe texto de manifiesto, no una ruta).

Qué datos operativos se conservan

Para ejecutar el servicio, DepCheck conserva únicamente contadores agregados: total de peticiones, errores, número en curso y recuentos de llamadas por herramienta / por cliente para capacidad y monitorización. Estos contadores registran que un cliente llamó a una herramienta, no los nombres de paquete, las versiones ni el contenido del manifiesto de la llamada. Se exponen en un endpoint interno /metrics, protegido por token, que nunca es accesible desde la internet pública.

Residencia de datos — dónde residen los datos de las advisories

Esta es la parte que importa para una postura soberana:

  • Los datos de advisories se sirven primero desde el mirror soberano de advisories de Cert-IX (osv-advisories), alojado dentro del clúster de Cert-IX, enriquecido con inteligencia de explotación de CISA KEV y EPSS procedente de los propios índices del clúster. En un acierto del mirror — el caso habitual — tu búsqueda nunca sale de la infraestructura de Cert-IX.
  • Recurso en vivo: si el mirror no tiene una respuesta (una advisory muy reciente, o un paquete que el mirror aún no ha indexado), DepCheck recurre a la API pública de osv.dev por corrección. suggest_safe_version usa además deps.dev para enumerar las versiones publicadas de un paquete. En esos casos de recurso, la coordenada de paquete (ecosystem, name y version) se envía a ese servicio público para resolver la respuesta.
  • Lo que nunca se envía a ningún tercero: tu manifiesto como documento, tu código fuente, tu clave de API o tu identidad. Solo se reenvía la coordenada mínima necesaria para responder a una búsqueda, y únicamente cuando el mirror no la tiene.
¿Quieres cero llamadas externas?

Ejecuta DepCheck localmente sobre stdio contra el mirror soberano (o una instantánea sin conexión). En esa configuración las búsquedas se resuelven contra el mirror sin tráfico de recurso público — adecuado para entornos aislados (air-gapped) o de alta garantía. Consulta Primeros pasos → Opción 2.

Postura de red (alojado)

  • El endpoint está fronteado por host nginx, que es el único punto de entrada y realiza la autenticación, la limitación de tasa y la terminación TLS.
  • El contenedor de DepCheck se publica solo en el loopback del host y reside en una red Docker dedicada de un único servicio — los demás servicios de la plataforma no pueden alcanzarlo directamente, y él no puede alcanzarlos a ellos.
  • El endpoint MCP (/depcheck) es la única ruta expuesta públicamente. Las rutas operativas (/metrics, health) son exclusivamente internas.

Notas de cumplimiento

  • DepCheck procesa coordenadas de paquete e identificadores de advisories — metadatos técnicos, no datos personales. Un manifiesto que envías se analiza de forma transitoria para extraer esas coordenadas y no se retiene como documento almacenado.
  • Las claves de API identifican a un cliente/organización, se usan para el control de acceso y la contabilidad agregada de tasa — no para la elaboración de perfiles.
  • El diseño con prioridad al mirror soberano mantiene la actividad de comprobación de dependencias dentro de la infraestructura de la UE/Cert-IX de forma predeterminada, con recurso público limitado a la coordenada mínima necesaria para la corrección.

Si necesitas un anexo de tratamiento de datos o una garantía de residencia para una carga de trabajo regulada, habla con tu equipo de cuenta de Cert-IX sobre un despliegue dedicado o totalmente sin conexión.

Lista de verificación de buenas prácticas

  • ✅ Guarda la clave de API en la configuración de secretos de tu cliente MCP, no en el repositorio.
  • ✅ Rota la clave ante cambios de personal o sospecha de exposición.
  • ✅ Escanea los lockfiles para conocer la verdad instalada, no solo los manifiestos con rangos.
  • ✅ Vuelve a escanear periódicamente — "limpio hoy" no es "limpio para siempre".
  • ✅ Corrige primero los hallazgos marcados como exploited (consulta Referencia de herramientas → get_cve_intel).
  • ✅ Mantén DepCheck como una capa más — combínalo con revisión, SAST y mínimo privilegio.

¿Te resultó útil esta página?