Cadena de suministro

Los agentes de programación instalan muchos paquetes, y una dependencia recién comprometida es una de las formas más directas de envenenar un sandbox. El panel Cadena de suministro configura la política por espacio de trabajo que Bromure Agentic Coding aplica a cada descarga de paquetes. Como indica la propia descripción del panel: Bromure examina cada descarga de paquetes (npm, PyPI, Cargo, RubyGems, Maven, NuGet, módulos de Go, Packagist) a través del MITM del anfitrión y aplica estas políticas antes de que el agente vea la respuesta; los .npmrc / pip.conf dentro de la VM solo pueden restringir aún más estos ajustes, nunca relajarlos. Utilice las listas de permitidos por paquete para excepciones quirúrgicas.

El panel agrupa cinco capas que se activan de forma independiente: Control por antigüedad, Comprobación de vulnerabilidades OSV, Filtrado de paquetes, Scripts de instalación e Instalaciones ancladas por lockfile (desplácese para ver las tres últimas). Esta página documenta los ajustes; el flujo completo — cobertura de ecosistemas, el Registro de seguridad, las cabeceras de respuesta y la detección de compromisos — se trata en el capítulo de protección de la cadena de suministro.

Cómo funciona la aplicación

Todas las comprobaciones se ejecutan en el proxy del lado del anfitrión, nunca dentro de la VM. Las claves de API de los servicios de reputación (socket.dev, Delpi) se mantienen únicamente en el anfitrión y nunca se exportan a la VM. Cuando una comprobación se activa, el proxy bloquea la descarga con una respuesta HTTP 451 que lleva un motivo en texto plano (por ejemplo, "npm package [email protected] published 4 hours ago — policy requires 2 days minimum"); npm, pip y cargo imprimen ese texto literalmente, de modo que tanto el agente como usted ven exactamente por qué falló una instalación. Las respuestas bloqueadas llevan la cabecera X-Bromure-Block: supply-chain; las respuestas reescritas llevan X-Bromure-Rewritten: supply-chain.

Las modificaciones de política se aplican en vivo: al guardar el espacio de trabajo se envía la nueva política a las sesiones en curso de inmediato — sin reiniciar la VM — y cada cambio se confirma con una línea [supply-chain] policy engaged en el Registro de seguridad (menú Ventana → Registro de seguridad…).

Nota: Los paquetes que ya están presentes en la caché local de npm o de pip nunca tocan la red, por lo que no se comprueba ni registra nada respecto a ellos. Un Registro de seguridad silencioso durante una instalación puede significar simplemente que todo estaba en caché.

Control por antigüedad

El control por antigüedad rechaza las versiones de paquetes más recientes que un umbral configurable, partiendo de la premisa de que las publicaciones recién lanzadas son las que tienen más probabilidades de ser un paquete recién comprometido. Es la única capa activada de forma predeterminada.

• Rechazar paquetes más recientes que el umbral — el interruptor principal. Activado de forma predeterminada.
• Antigüedad mínima — el umbral en días (control incremental, 0–90). Valor predeterminado: 2 días.
• Paquetes exentos — una lista de permitidos en el formato npm:axios (un ecosistema) o simplemente axios (todos los ecosistemas), sin distinción de mayúsculas y minúsculas. Haga clic en Añadir entrada para agregar una fila.

Las referencias flotantes (pkg@latest, rangos semver) nunca se bloquean de forma dura: el proxy reescribe los metadatos del registro de modo que las versiones demasiado recientes simplemente no existen desde el punto de vista del agente, y el gestor de paquetes resuelve a la versión permitida más nueva. Solo las referencias ancladas a versiones demasiado recientes reciben el 451, indicando la antigüedad del paquete y el mínimo requerido.

Nota: Maven, NuGet y los módulos de Go no incluyen marcas de tiempo por versión en sus respuestas de metadatos estándar, por lo que el control por antigüedad no bloquea actualmente esos tres ecosistemas. npm, PyPI, Cargo, RubyGems y Packagist están totalmente cubiertos (para PyPI, Bromure consulta las fechas de publicación bajo demanda desde la API JSON de PyPI).

Comprobación de vulnerabilidades OSV

Cuando Consultar paquetes en api.osv.dev (gratuito, sin clave) está activado, se comprueban el ecosistema, el paquete y la versión de cada artefacto descargado contra la base de datos OSV — una agregación gratuita de la GitHub Advisory Database, los avisos de PyPI, la base de datos de vulnerabilidades de Go, RubySec y otras. Cualquier aviso igual o superior al umbral de Bloquear a partir de la gravedad bloquea la descarga con un 451.

• Desactivado de forma predeterminada — como señala el panel, una CVE de baja gravedad en un subpaquete transitivo no debería interrumpir un flujo de trabajo.
• Bloquear a partir de la gravedad ofrece Baja o superior, Media o superior, Alta o superior (el valor predeterminado) o Solo crítica.
• Cubre los ocho ecosistemas; las comprobaciones se ejecutan en el momento de la descarga del artefacto, no en las descargas de metadatos.

Filtrado de paquetes

El selector de opción Filtrado de paquetes elige un proveedor de reputación: Ninguno, socket.dev o Delpi. Los dos proveedores funcionan de forma diferente — socket.dev es una consulta previa que el proxy realiza antes de dejar pasar una descarga, mientras que Delpi reemplaza por completo el registro de npm — por lo que son mutuamente excluyentes. Las claves de API almacenadas se conservan al cambiar, de modo que alternar entre proveedores no es destructivo.

socket.dev

Con socket.dev seleccionado, pegue un token de API en Clave de API (el enlace Obtener una clave de API abre la página de tokens de socket.dev). Ambos interruptores de abajo permanecen deshabilitados hasta que se introduce una clave, y una clave vacía deshabilita socket.dev por completo independientemente de los interruptores. La clave se almacena únicamente en el lado del anfitrión y nunca entra en la VM.

• Bloquear paquetes comprometidos (scripts de instalación maliciosos, marcados como malware, typosquats, telemetría sospechosa) — bloquea ante señales de riesgo de cadena de suministro con forma de ataque: indicadores definitivos de malware con cualquier gravedad; señales más ruidosas como código ofuscado, scripts de instalación, typosquatting o acceso a shell solo cuando socket.dev las califica como altas o críticas (de modo que un paquete con un postinstall benigno no se bloquea). Desactivado de forma predeterminada.
• Bloquear paquetes con CVE conocidas — bloquea según el grupo de vulnerabilidades de socket.dev igual o superior al umbral de bloqueo de CVE (predeterminado Alta o superior; el selector está deshabilitado hasta que este interruptor esté activado). Desactivado de forma predeterminada.

Nota: socket.dev no admite Cargo. Con el filtrado de socket.dev activado, cada artefacto de crates.io no produce ningún veredicto y activa la retención de paquete no verificado descrita más abajo — en la práctica, un prompt por cada versión de crate. Desactive socket.dev para espacios de trabajo con mucho Rust, o prepárese para responder prompts.

Delpi

Con Delpi seleccionado y una clave de API introducida (el enlace Obtener una clave de API abre landh.tech), el proxy redirige cada solicitud al registro de npm — metadatos, tarballs, auditoría, todo lo dirigido a registry.npmjs.org — al registro seguro compatible con npm de Delpi en depi-npm-proxy.landh.tech, adjuntando su clave como un token Bearer inyectado por el anfitrión. Delpi sirve paquetes previamente verificados, de modo que en lugar de una consulta por paquete, se reemplaza todo el registro. Las demás capas (control por antigüedad, OSV, eliminación de scripts) siguen aplicándose por encima: Delpi reemplaza a socket.dev, no a la política local.

Mientras el campo de la clave está vacío, una advertencia naranja indica Introduzca una clave de API — Delpi permanece desactivado sin ella. Si Delpi rechaza la clave, la instalación de npm falla con un error claro de Bromure, el rechazo se registra en el Registro de seguridad y se genera una alerta única. Delpi afecta únicamente a npm; los demás ecosistemas quedan intactos.

Scripts de instalación

Eliminar preinstall / install / postinstall / prepare de los tarballs de npm sobre la marcha elimina los hooks que los paquetes de npm maliciosos utilizan para ejecutar código en el momento de la instalación. Bromure reescribe el tarball en vuelo — elimina las claves de script del package.json del paquete, recalcula la suma de comprobación del tar, vuelve a comprimir con gzip — y depura los hashes de integridad de los metadatos del registro para que la propia verificación de npm siga pasando en instalaciones sin anclar. Las eliminaciones se registran en naranja en el Registro de seguridad; ante cualquier fallo de análisis, el tarball original pasa sin modificar (esta capa falla de forma abierta en lugar de romper una instalación bien formada).

Los compiladores de bindings que realmente necesitan scripts de instalación (better-sqlite3, node-canvas, …) van en Permitir scripts de instalación para, con el formato npm:better-sqlite3.

Desactivado de forma predeterminada; solo npm (los sdists de PyPI nunca se reescriben — setup.py es código arbitrario).

Instalaciones ancladas por lockfile

Las instalaciones ancladas por lockfile (npm ci, pip --require-hashes) fijan los hashes de integridad de los tarballs en el lockfile, por lo que Bromure no puede reescribir esos tarballs sin romper la verificación. De forma predeterminada, pasan sin modificar y de forma silenciosa.

Active Preguntar antes de dejar pasar sin modificar los tarballs anclados por lockfile (npm ci, pip --require-hashes) para que se le pregunte en su lugar: la primera descarga anclada por lockfile de un lote muestra un diálogo del anfitrión titulado Pass through npm ci (lockfile-pinned install) from workspace "<name>"? con las opciones Permitir durante 15 minutos, Permitir una vez, Permitir durante el resto de la sesión y No permitir. Todo el lote sigue la decisión (las descargas concurrentes se fusionan en un único prompt); denegar bloquea con un 451 y se recuerda durante 60 segundos.

Nota: Aunque la etiqueta menciona pip --require-hashes, la detección solo está implementada actualmente para npm ci de npm — las instalaciones de pip con hashes anclados no activan el prompt.

Cuando una fuente de reputación es inalcanzable

Si una fuente de reputación activada (OSV o socket.dev) no puede producir un veredicto — red caída, límite de tasa alcanzado, fallo de autenticación, ecosistema no admitido — Bromure falla de forma cerrada en lugar de permitir en silencio. La descarga se retiene y un diálogo pregunta, por cada paquete y versión, si se acepta el paquete no verificado; denegar bloquea con un 451. Las aprobaciones se indexan por package@version, de modo que una sola respuesta no puede abarcar todo un grafo de dependencias.

Esta es una protección deliberada contra un atacante que induce límites de tasa para colar paquetes. También significa que el trabajo totalmente sin conexión con OSV o socket.dev activado pedirá confirmación para cada paquete no almacenado en caché — desactive esas capas para el uso sin conexión. En sesiones SSH/CLI sin interfaz, la misma pregunta se plantea dentro del tmux del espacio de trabajo; la falta de respuesta equivale a denegar.

Referencia de ajustes

Las claves de API introducidas aquí residen en el profile.json del espacio de trabajo en el anfitrión (nunca en la VM); todas las llamadas de reputación se originan desde el proxy del anfitrión. Para el Registro de seguridad, los detalles de interceptación por ecosistema y la alarma de detección de compromisos que acompaña a estas políticas, consulte el capítulo de protección de la cadena de suministro.