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 son gratuitas y de autoservicio: solicita una en cert-ix.com/tools/depcheck-mcp, confirma tu dirección de correo electrónico y la clave te llegará por correo. Una clave dura 90 días y se puede renovar desde el correo de recordatorio que se envía antes de que caduque. 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:

Ámbito	Límite
Por clave de API	20 peticiones/segundo (ráfaga breve hasta 40), 20 conexiones concurrentes
Por IP de origen	40 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ías	Qué 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 DepCheck no lo almacena ni lo registra.
Un ID de advisory / CVE	Busca su detalle o su inteligencia de explotación.

El propio manifiesto sí llega al servidor de Cert-IX — la herramienta scan_dependencies alojada recibe su texto en la petición —, pero no pasa de ahí: DepCheck extrae coordenadas (qué paquetes, qué versiones) y las busca. 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

DepCheck da prioridad al mirror, pero no se limita a él. Responde desde la infraestructura de Cert-IX cuando puede, y sigue dando respuestas correctas cuando no puede:

• Primero, el mirror. Las búsquedas de advisories se sirven primero desde la propia copia de Cert-IX de los datos de advisories de OSV, enriquecida con inteligencia de explotación de CISA KEV y EPSS procedente de los propios índices de Cert-IX. Cuando el mirror puede responder, la búsqueda se resuelve en la infraestructura de Cert-IX.
• Recurso a osv.dev. Cuando el mirror no puede responder con certeza — el ecosistema del paquete no está cubierto, los datos del mirror superan su límite de antigüedad, un registro de advisory no se puede asociar con certeza o el mirror devuelve un error —, DepCheck consulta en su lugar la API pública de osv.dev, en vez de informar de "limpio" a partir de datos en los que no puede confiar. get_advisory hace lo mismo con un ID de advisory que el mirror no tiene.
• Listas de versiones desde deps.dev. suggest_safe_version lee la lista de versiones publicadas de un paquete desde la API pública de deps.dev en cada llamada (las respuestas se guardan en caché en memoria durante una hora) y después comprueba las versiones candidatas como se ha descrito arriba.
• Qué reciben esos servicios. osv.dev y deps.dev los opera Google, en Estados Unidos. Reciben una coordenada de paquete — ecosystem, name y, en el caso de osv.dev, version — o, para get_advisory, el ID de advisory. No se envían tu archivo de manifiesto, tu código fuente, tu clave de API ni tu identidad.
• Nombres de paquetes privados. Si un manifiesto o una llamada a check_package nombra paquetes privados o internos, esos nombres pueden llegar a osv.dev por la vía de recurso. Mantén los nombres de paquetes confidenciales fuera de las llamadas a DepCheck.

Tu cliente MCP, y el modelo de IA que hay detrás, también ven todo lo que tu agente envía y recibe. Esa parte se rige por tu cliente y tu proveedor del modelo, no por Cert-IX.

Hoy no hay un modo sin tráfico saliente

DepCheck no tiene ninguna configuración que garantice cero llamadas externas. Una instancia local stdio consulta osv.dev directamente salvo que tenga acceso a un mirror de Cert-IX, y suggest_safe_version siempre lee las listas de versiones de deps.dev. 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, de modo que no se puede alcanzar desde internet salvo a través de ese nginx.
• 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 mantiene las búsquedas en la infraestructura de Cert-IX siempre que el mirror puede responder. No garantiza que todas las búsquedas se queden ahí: las búsquedas de recurso y las listas de versiones de suggest_safe_version van a osv.dev y a deps.dev, solo con coordenadas de paquete.

Si necesitas un anexo de tratamiento de datos para una carga de trabajo regulada, o compromisos de residencia que vayan más allá de lo que describe esta página, habla con tu equipo de cuenta de Cert-IX.

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.