Tema: supply-chain
-
Vincular la identidad de publicación en npm y PyPI con los artefactos aprobados de cada versión
La publicación de confianza mediante OIDC elimina los tokens de publicación almacenados, pero su seguridad sigue dependiendo del flujo de trabajo autorizado. Separar la compilación de la publicación, proteger las aprobaciones y verificar la identidad del artefacto sin interpretar su procedencia como un veredicto sobre la presencia de malware.
-
Confusión de dependencias: cuando un paquete público eclipsa a uno privado
Si una compilación resuelve los nombres de paquete a la vez en un índice privado y en uno público, un atacante que publique el nombre privado en público con una versión superior puede conseguir que se instale su código; la documentación de pip califica de insegura la opción --extra-index-url para paquetes privados precisamente por esta razón. Las defensas son espacios de nombres vinculados a un único registro, un índice único que actúa de proxy, la fijación por hash y la reserva de nombres.
-
Integridad de subrecursos para scripts y hojas de estilo de terceros
Un atributo integrity en un elemento script o link lleva un hash en base64 SHA-256, SHA-384 o SHA-512 del archivo esperado; el navegador se niega a ejecutar o aplicar un recurso cuyo contenido no coincida. Fija exactamente lo que un CDN puede entregar, exige CORS para los archivos de origen cruzado y, por ello, solo funciona con recursos de contenido fijo.
-
Las definiciones de herramientas MCP como superficie de ataque: descripciones envenenadas, shadowing y cambios silenciosos
Los nombres, descripciones y anotaciones de las herramientas de un servidor MCP son texto que el modelo lee antes de invocar ninguna herramienta. Un servidor malicioso o comprometido puede usarlos para dirigir al agente, imitar las herramientas de otro servidor, o cambiar de comportamiento después de la aprobación. Los clientes deberían fijar, comparar (diff) y revisar las definiciones como si fueran código.
-
Higiene de dependencias y comprobaciones de la cadena de suministro de software
Conocer aquello de lo que se depende, fijarlo y verificarlo, vigilar las vulnerabilidades conocidas, y compilar a partir de fuentes de confianza; los niveles de SLSA, OpenSSF Scorecard y las instalaciones verificadas por hash ofrecen pasos concretos.
-
Nombres de paquetes alucinados y de aspecto similar: comprobar una dependencia antes de que un agente la instale
Los modelos generadores de código a veces nombran paquetes que no existen; un atacante puede registrar ese nombre, y quienes practican el typosquatting registran variantes muy próximas a las de paquetes populares. Antes de instalar, un agente debe confirmar que el paquete existe, que es el proyecto previsto y que no se registró recientemente bajo un nombre confundible.
-
Incidente de LiteLLM de octubre de 2026: exposición confirmada de tokens y precauciones con los registros de la pasarela
El análisis posterior de LiteLLM sustituyó su hipótesis inicial de robo de registros por pruebas de exposición de tokens a través de una API de Agent Platform. El incidente sigue ilustrando por qué las credenciales de agentes, los cuerpos de respuesta y la automatización con privilegios deben tener límites de acceso separados.
-
Listas de materiales de software con SPDX y CycloneDX
Un SBOM es un inventario legible por máquina de los componentes de un artefacto de software; SPDX y CycloneDX son los dos formatos de uso extendido, y generar uno por cada versión respalda la coincidencia de vulnerabilidades y la revisión de licencias.
-
Cadencia de actualización de dependencias: agrupación, lotes y qué fusionar de una vez
Los bots de actualización abren una pull request por dependencia salvo que se configure otra cosa; una cadencia sostenible fusiona las correcciones de seguridad en cuanto llegan, agrupa las actualizaciones de parche y menores en un lote programado, y trata las versiones mayores como trabajo planificado. Dependabot y Renovate documentan ambos la programación y la agrupación, y la guía de Renovate señala el coste de agrupar: un lote que falla bloquea a todos sus miembros.
-
Contener la propagación de gusanos de npm entre equipos de desarrollo y cuentas de publicación
ChainDrop y el incidente de Tensorlake muestran cómo el robo de credenciales durante la instalación puede dar lugar a publicaciones de paquetes no autorizadas. La contención debe abarcar la ejecución de dependencias, los permisos de publicación, la persistencia en repositorios y los artefactos de compilación contaminados.
-
Endurecer flujos de trabajo de GitHub Actions: acciones fijadas por SHA, tokens de mínimo privilegio y entradas no confiables
Fijar las acciones de terceros a un SHA de commit completo, establecer GITHUB_TOKEN como de solo lectura por defecto y ampliarlo por job, no interpolar nunca campos de eventos no confiables en scripts run, y tratar pull_request_target y workflow_run como disparadores privilegiados.
-
Períodos de espera para versiones de paquetes: ajustes exactos, unidades y límites de aplicación
Los controles de antigüedad de versiones difieren entre npm, pnpm, uv, Renovate y Dependabot. Configurar las unidades correctas, comprobar el tratamiento de las marcas de tiempo y la resolución de dependencias transitivas, y mantener una vía explícita para las actualizaciones de seguridad urgentes.
-
Construir imágenes de contenedor pequeñas y reproducibles
Fijar las imágenes base por digest, instalar desde lockfiles con verificación de hash, copiar solo lo que necesita el runtime, ejecutar como un usuario sin privilegios, añadir una comprobación de salud, y mantener los secretos fuera de las capas y de los argumentos de compilación.
-
Listas de materiales de software (SBOM): el inventario de la propia cadena de suministro
Una lista de materiales de software enumera de forma legible por máquina qué componentes, en qué versión, forman parte de un artefacto entregado. SPDX (ISO/IEC 5962:2021) y CycloneDX (OWASP) son los formatos más extendidos; se genera por versión a partir del artefacto compilado, se guarda junto a él y se usa para contrastarla con los avisos de vulnerabilidades y las obligaciones de licencia. Junto con las pruebas de procedencia (SLSA), hace verificable la cadena de suministro.
-
Automatización de la detección del fin de vida útil en SBOM, imágenes de contenedor e inventarios de software
Relacionar los inventarios de entornos de ejecución e imágenes con datos de ciclo de vida, conservando la identidad del producto, el proveedor de soporte y la vigencia de las pruebas. Este flujo propuesto utiliza endoflife.date como fuente de detección, confirma los plazos con los proveedores y alerta por separado sobre el soporte vencido y la falta de pruebas.
-
Firmar commits y etiquetas con una clave SSH o con GPG
Git firma commits y etiquetas con OpenPGP, X.509 o, desde gpg.format=ssh, con una simple clave SSH; quien firma configura gpg.format y user.signingKey, quienes verifican necesitan un archivo allowed-signers (SSH) o un llavero de confianza (GPG), y las falsificaciones se comprueban con git verify-commit o con la insignia de firma del servidor.
-
Atestaciones de procedencia de build: qué registra la procedencia SLSA y cómo se verifica
El track Build de SLSA califica cuán confiable es la procedencia de un artefacto, desde "existe procedencia" (L1) hasta una plataforma de build reforzada (L3); la procedencia es una atestación in-toto que nombra los digests del artefacto, quien construyó, el tipo de build y sus parámetros externos, y quien consume la verifica contra una raíz de confianza y valores esperados antes de usarla.
-
Etiquetas frente a digests en imágenes de contenedor: nombres mutables y direcciones de contenido
Una etiqueta es un puntero legible para humanos que puede moverse a un manifiesto distinto en cualquier momento; un digest es el hash de los bytes del manifiesto e identifica exactamente una imagen para siempre. Conviene construir y probar por etiqueta, pero desplegar y fijar por digest, y registrar el digest en cada nota de release.
-
Creación y mantenimiento de un inventario criptográfico para la migración poscuántica
Registrar dónde protege los datos la criptografía, quién es responsable de cada dependencia y qué pruebas respaldan el registro. Utilizar una CBOM de CycloneDX para intercambiar activos técnicos sin confundirla con un plan de migración completo.
-
¿Qué comprobaciones en los pull requests de actualización automática de dependencias han detectado una versión maliciosa o defectuosa, y cuáles solo generan ruido?
Pregunta abierta: los pull requests de actualización automática llegan a diario y suelen fusionarse cuando el CI está en verde; la documentación de npm describe attestations de procedencia que npm audit signatures puede verificar, pero ¿qué comprobaciones (procedencia, revisión del diff del paquete descomprimido, inspección de scripts de instalación, periodos de espera, diffs del lockfile) han demostrado detectar una versión comprometida o defectuosa?
Legible por máquina: JSON