Los ataques a la cadena de suministro de software han aumentado tanto en frecuencia como en sofisticaci\u00f3n en los \u00faltimos a\u00f1os. En lugar de atacar las aplicaciones directamente, los adversarios apuntan cada vez m\u00e1s a las capas de resoluci\u00f3n de dependencias y distribuci\u00f3n de artefactos que sustentan el desarrollo de software moderno. Dos de las t\u00e9cnicas m\u00e1s efectivas en esta categor\u00eda son la confusi\u00f3n de dependencias<\/strong> (dependency confusion) y el envenenamiento de artefactos<\/strong> (artifact poisoning).<\/p>\n Estos ataques explotan una verdad fundamental: el software moderno se ensambla, no se escribe desde cero. Una aplicaci\u00f3n t\u00edpica puede incorporar cientos o miles de paquetes de terceros, im\u00e1genes de contenedores, templates de CI y plugins de compilaci\u00f3n \u2014 cada uno representando un eslab\u00f3n en una cadena de confianza. Cuando cualquier eslab\u00f3n se compromete, toda la cadena falla.<\/p>\n Lo que hace estos ataques particularmente peligrosos es que muchas organizaciones permanecen vulnerables a pesar de tener programas de seguridad maduros. Las pruebas tradicionales de seguridad de aplicaciones no detectan una dependencia maliciosa instalada en tiempo de compilaci\u00f3n. Los firewalls y WAFs son irrelevantes cuando el c\u00f3digo del atacante se ejecuta dentro de su pipeline CI\/CD con acceso completo a la red y credenciales de producci\u00f3n.<\/p>\n Esta gu\u00eda proporciona un examen en profundidad de c\u00f3mo funcionan la confusi\u00f3n de dependencias y el envenenamiento de artefactos, por qu\u00e9 los pipelines CI\/CD son objetivos principales y \u2014 lo m\u00e1s importante \u2014 qu\u00e9 defensas pr\u00e1cticas puede implementar hoy.<\/p>\n La mayor\u00eda de los package managers modernos \u2014 npm, pip, RubyGems, NuGet, Maven \u2014 siguen un proceso de resoluci\u00f3n que consulta uno o m\u00e1s registros cuando se solicita un paquete. Cuando una organizaci\u00f3n utiliza tanto un registro privado\/interno<\/strong> (para paquetes propietarios) como el registro p\u00fablico<\/strong> (para paquetes open-source), el package manager debe decidir qu\u00e9 registro tiene prioridad cuando ambos contienen un paquete con el mismo nombre.<\/p>\n El comportamiento predeterminado var\u00eda seg\u00fan el ecosistema, pero un patr\u00f3n com\u00fan es preocupante: muchos package managers preferir\u00e1n el n\u00famero de versi\u00f3n m\u00e1s alto<\/strong> independientemente de qu\u00e9 registro provenga. Esta decisi\u00f3n de dise\u00f1o aparentemente inocente es la base del ataque de confusi\u00f3n de dependencias.<\/p>\n En febrero de 2021, el investigador de seguridad Alex Birsan public\u00f3 una investigaci\u00f3n pionera que demostraba c\u00f3mo este comportamiento de resoluci\u00f3n pod\u00eda ser utilizado como arma. Al examinar nombres de paquetes internos filtrados p\u00fablicamente de empresas como Apple, Microsoft y Tesla \u2014 encontrados en archivos JavaScript, manifiestos de paquetes y mensajes de error \u2014 registr\u00f3 paquetes con nombres id\u00e9nticos en los registros p\u00fablicos de npm, PyPI y RubyGems con n\u00fameros de versi\u00f3n inflados.<\/p>\n El resultado fue devastador. Cuando los sistemas de compilaci\u00f3n de estas empresas resolv\u00edan las dependencias, los package managers obten\u00edan los paquetes p\u00fablicos de Birsan en lugar de los internos leg\u00edtimos. Sus paquetes de prueba de concepto inclu\u00edan callbacks benignos que reportaban a un servidor, confirmando la ejecuci\u00f3n de c\u00f3digo dentro de las redes corporativas. Birsan gan\u00f3 m\u00e1s de $130,000 en bug bounties en m\u00faltiples organizaciones.<\/p>\n El ataque de confusi\u00f3n de dependencias sigue una secuencia directa:<\/p>\n La confusi\u00f3n de dependencias no se limita a un solo lenguaje o ecosistema. Los siguientes son todos susceptibles:<\/p>\n La raz\u00f3n por la que la confusi\u00f3n de dependencias es tan peligrosa es que los package managers soportan ejecuci\u00f3n autom\u00e1tica de c\u00f3digo durante la instalaci\u00f3n<\/strong>. En npm, esto ocurre a trav\u00e9s de scripts Mientras que la confusi\u00f3n de dependencias apunta espec\u00edficamente a los registros de paquetes, el envenenamiento de artefactos<\/strong> es una categor\u00eda m\u00e1s amplia de ataques a la cadena de suministro que puede apuntar a cualquier artefacto externo consumido durante el ciclo de vida del desarrollo de software. La superficie de ataque se extiende mucho m\u00e1s all\u00e1 de los package managers.<\/p>\n Las im\u00e1genes de contenedores obtenidas de Docker Hub u otros registros p\u00fablicos son un vector de ataque com\u00fan. Un atacante puede publicar una imagen maliciosa con un nombre similar a una imagen base popular, o comprometer una imagen existente obteniendo acceso a la cuenta del mantenedor. Si su Dockerfile especifica Los templates de GitHub Actions y GitLab CI referenciados desde repositorios p\u00fablicos representan otra superficie de ataque significativa. Cuando un workflow referencia Los ataques de typosquatting explotan errores ortogr\u00e1ficos comunes y similitudes visuales en nombres de paquetes. Los ejemplos incluyen registrar Cuando un atacante obtiene acceso a la cuenta de un mantenedor leg\u00edtimo de paquetes \u2014 a trav\u00e9s de credential stuffing, phishing o ingenier\u00eda social \u2014 puede publicar versiones con backdoor de paquetes ampliamente utilizados. Debido a que el nombre del paquete y el mantenedor son leg\u00edtimos, estas versiones comprometidas son extremadamente dif\u00edciles de detectar por medios automatizados.<\/p>\n Los sistemas de compilaci\u00f3n como Gradle, Maven y webpack soportan plugins que se ejecutan durante el proceso de compilaci\u00f3n. Los plugins maliciosos o comprometidos en estos ecosistemas pueden modificar los resultados de compilaci\u00f3n, exfiltrar secrets o inyectar backdoors en artefactos compilados. Debido a que los plugins de compilaci\u00f3n a menudo reciben menos escrutinio que las dependencias de aplicaci\u00f3n, representan un objetivo de alto valor.<\/p>\n Varios incidentes importantes ilustran el impacto real del envenenamiento de artefactos:<\/p>\n Los pipelines CI\/CD son particularmente vulnerables a la confusi\u00f3n de dependencias y el envenenamiento de artefactos debido a c\u00f3mo est\u00e1n dise\u00f1ados para operar. Comprender por qu\u00e9 los pipelines son objetivos principales es esencial para construir defensas efectivas.<\/p>\n Cada vez que un pipeline de CI ejecuta Los entornos CI\/CD t\u00edpicamente est\u00e1n configurados con secrets necesarios para el despliegue: credenciales de proveedores cloud, tokens de API, contrase\u00f1as de bases de datos, claves de firma y credenciales de registros. Una dependencia maliciosa que se ejecuta durante la fase de compilaci\u00f3n puede acceder a estos secrets a trav\u00e9s de variables de entorno o almacenes de secrets montados. Esto hace que los pipelines CI\/CD sean objetivos mucho m\u00e1s valiosos que las laptops de los desarrolladores.<\/p>\n En la mayor\u00eda de las organizaciones, las versiones de dependencias se especifican en archivos de manifiesto ( Su aplicaci\u00f3n puede declarar 50 dependencias directas, pero esas dependencias tienen sus propias dependencias, creando un \u00e1rbol que puede incluir miles de paquetes transitivos. Usted no tiene control directo sobre lo que sus dependencias dependen. Cuando una dependencia transitiva es comprometida \u2014 como en el incidente de Prevenir la confusi\u00f3n de dependencias requiere configurar sus package managers y registros para eliminar la ambig\u00fcedad entre paquetes p\u00fablicos y privados. Aqu\u00ed est\u00e1n las mitigaciones m\u00e1s efectivas.<\/p>\n La defensa individual m\u00e1s efectiva es utilizar nombres de paquetes con namespace o scope para todos los paquetes internos. En npm, esto significa usar paquetes con scope como Nunca conf\u00ede en el comportamiento de resoluci\u00f3n predeterminado. Configure expl\u00edcitamente su package manager para obtener paquetes con scope de su registro privado y todo lo dem\u00e1s del registro p\u00fablico.<\/p>\n Ejemplo de configuraci\u00f3n Ejemplo de Ejemplo de Despliegue un proxy de registro como JFrog Artifactory, Sonatype Nexus o GitHub Packages que se sit\u00fae entre sus sistemas de compilaci\u00f3n y los registros p\u00fablicos. Configure el proxy para:<\/p>\n Esto crea una \u00fanica fuente de verdad para todas las dependencias y elimina completamente la ambig\u00fcedad p\u00fablico\/privado.<\/p>\n Registre los nombres de sus paquetes internos en registros p\u00fablicos como paquetes placeholder. Estos paquetes no deben contener c\u00f3digo real \u2014 solo un README explicando que el nombre est\u00e1 reservado. Esto evita que los atacantes reclamen esos nombres. Aunque esta no es una defensa primaria, agrega una capa extra de protecci\u00f3n.<\/p>\n Fijar dependencias por hash criptogr\u00e1fico asegura que el artefacto exacto que usted audit\u00f3 sea el que se instala durante las compilaciones. Incluso si un atacante publica una versi\u00f3n maliciosa, el hash no coincidir\u00e1 y la instalaci\u00f3n fallar\u00e1.<\/p>\n Para pip (Python):<\/strong><\/p>\n Para npm:<\/strong><\/p>\n npm registra autom\u00e1ticamente hashes de integridad en Debido a que el envenenamiento de artefactos abarca una gama m\u00e1s amplia de vectores de ataque, la defensa requiere controles en capas a trav\u00e9s de im\u00e1genes de contenedores, templates de CI, dependencias y procesos de compilaci\u00f3n.<\/p>\n Nunca referencie im\u00e1genes de contenedores por tags mutables como Referencie GitHub Actions por su SHA de commit completo en lugar de un tag mutable:<\/p>\n Donde est\u00e9 disponible, verifique firmas criptogr\u00e1ficas para confirmar que los artefactos fueron publicados por sus mantenedores esperados:<\/p>\n Un Software Bill of Materials (SBOM) inventar\u00eda cada componente en su aplicaci\u00f3n. Al generar SBOMs para cada compilaci\u00f3n y compararlos, puede detectar adiciones o cambios inesperados en su \u00e1rbol de dependencias. Herramientas como Syft, Trivy y CycloneDX pueden generar SBOMs en formatos est\u00e1ndar (SPDX, CycloneDX).<\/p>\n Despliegue herramientas automatizadas que escaneen continuamente sus dependencias en busca de vulnerabilidades conocidas y cambios sospechosos:<\/p>\n Los hermetic builds son compilaciones que no pueden acceder a la red. Todas las dependencias deben ser pre-obtenidas y cacheadas antes de que comience la compilaci\u00f3n. Esto evita que una compilaci\u00f3n obtenga un paquete malicioso reci\u00e9n publicado. Bazel soporta nativamente hermetic builds, y un aislamiento similar puede lograrse con el flag Mantenga una lista aprobada de dependencias y sus versiones. Cualquier nueva dependencia o cambio de versi\u00f3n requiere aprobaci\u00f3n expl\u00edcita a trav\u00e9s de un proceso de revisi\u00f3n. Aunque esto agrega fricci\u00f3n, previene que paquetes no autorizados entren en su pipeline de compilaci\u00f3n.<\/p>\n Incluso con controles preventivos fuertes, las capacidades de detecci\u00f3n son esenciales para capturar ataques que eludan sus defensas.<\/p>\n Implemente verificaciones de CI que marquen pull requests que introduzcan nuevas dependencias. Requiera justificaci\u00f3n y revisi\u00f3n expl\u00edcita para cualquier adici\u00f3n a su manifiesto de dependencias. Esto es particularmente importante para dependencias transitivas \u2014 una nueva dependencia directa podr\u00eda traer docenas de transitivas.<\/p>\n Una dependencia que salta de la versi\u00f3n Implemente herramientas que identifiquen espec\u00edficamente paquetes con install scripts. Aunque los install scripts tienen usos leg\u00edtimos, son el vector de ejecuci\u00f3n principal para ataques de confusi\u00f3n de dependencias. Marque y revise cualquier paquete que incluya scripts Compare regularmente SBOMs de compilaciones consecutivas. Cambios inesperados \u2014 nuevos paquetes que aparecen, versiones que cambian sin actualizaciones correspondientes del manifiesto, o paquetes de registros inesperados \u2014 deber\u00edan activar alertas e investigaci\u00f3n.<\/p>\n M\u00e1s all\u00e1 de la gesti\u00f3n de dependencias, la configuraci\u00f3n de su pipeline CI\/CD en s\u00ed necesita hardening para resistir ataques a la cadena de suministro.<\/p>\n Los lock files ( Ejemplo de GitHub Actions \u2014 verificar integridad del lockfile:<\/strong><\/p>\n Ejemplo de GitLab CI \u2014 verificaci\u00f3n de lockfile con pip:<\/strong><\/p>\n Use un proceso de compilaci\u00f3n en dos fases: primero resuelva y descargue las dependencias en un entorno aislado, luego ejecute la compilaci\u00f3n real con el acceso a red deshabilitado. Esto evita que una dependencia comprometida exfiltre datos o descargue payloads adicionales durante la compilaci\u00f3n.<\/p>\n Para compilaciones de alta seguridad, use entornos con red restringida que solo puedan acceder a su proxy de registro interno. Esto elimina la posibilidad de que las dependencias se obtengan directamente de registros p\u00fablicos durante la compilaci\u00f3n.<\/p>\n En lugar de obtener dependencias de registros p\u00fablicos en cada compilaci\u00f3n, cachee versiones aprobadas en almacenamiento interno (Artifactory, Nexus, buckets de almacenamiento cloud). Su pipeline de CI deber\u00eda obtener exclusivamente de este cach\u00e9 de confianza. Actualice el cach\u00e9 a trav\u00e9s de un proceso controlado y auditado.<\/p>\n La confusi\u00f3n de dependencias y el envenenamiento de artefactos explotan suposiciones de confianza profundamente arraigadas en la cadena de suministro de software. Cada La defensa efectiva no es una sola herramienta o cambio de configuraci\u00f3n. Requiere controles en cada capa del ciclo de vida de las dependencias:<\/p>\n Las organizaciones que ser\u00e1n m\u00e1s resilientes a los ataques a la cadena de suministro son aquellas que tratan las dependencias con el mismo rigor que aplican a su propio c\u00f3digo: revisadas, verificadas, monitoreadas y nunca confiadas impl\u00edcitamente. Comience implementando los controles de mayor impacto \u2014 paquetes con scope, configuraci\u00f3n de registro, verificaci\u00f3n de lockfile en CI \u2014 y agregue capas progresivamente a medida que su programa de seguridad de cadena de suministro madure.<\/p>\n","protected":false},"excerpt":{"rendered":" Introducci\u00f3n Los ataques a la cadena de suministro de software han aumentado tanto en frecuencia como en sofisticaci\u00f3n en los \u00faltimos a\u00f1os. En lugar de atacar las aplicaciones directamente, los adversarios apuntan cada vez m\u00e1s a las capas de resoluci\u00f3n de dependencias y distribuci\u00f3n de artefactos que sustentan el desarrollo de software moderno. Dos de … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,60],"tags":[],"post_folder":[],"class_list":["post-645","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-threats-attacks"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/645","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/comments?post=645"}],"version-history":[{"count":1,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/645\/revisions"}],"predecessor-version":[{"id":657,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/645\/revisions\/657"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=645"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=645"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=645"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=645"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Confusi\u00f3n de Dependencias Explicada<\/h2>\n
C\u00f3mo los Package Managers Resuelven Nombres<\/h3>\n
La Investigaci\u00f3n Original: Alex Birsan (2021)<\/h3>\n
La Mec\u00e1nica del Ataque<\/h3>\n
\n
package.json<\/code> filtrados, source maps de JavaScript, mensajes de error, ofertas de empleo o repositorios open-source que referencian dependencias internas.<\/li>\n99.0.0<\/code>).<\/li>\nnpm install<\/code>, pip install<\/code> o un comando equivalente, el package manager resuelve la dependencia al paquete p\u00fablico del atacante debido al n\u00famero de versi\u00f3n m\u00e1s alto.<\/li>\nEcosistemas Afectados<\/h3>\n
\n
--extra-index-url<\/code> de pip verifica tanto el \u00edndice privado como el p\u00fablico, prefiriendo la versi\u00f3n m\u00e1s alta.<\/li>\nInstall Scripts como Vector de Payload<\/h3>\n
preinstall<\/code>, install<\/code> y postinstall<\/code> definidos en package.json<\/code>. En Python, setup.py<\/code> puede ejecutar c\u00f3digo arbitrario durante pip install<\/code>. Estos hooks fueron dise\u00f1ados para tareas leg\u00edtimas de compilaci\u00f3n pero proporcionan a los atacantes un vector de ejecuci\u00f3n ideal \u2014 el c\u00f3digo se ejecuta antes de que la aplicaci\u00f3n siquiera se compile, a menudo con privilegios elevados.<\/p>\nEnvenenamiento de Artefactos: M\u00e1s All\u00e1 de los Paquetes<\/h2>\n
Im\u00e1genes Base de Contenedores Comprometidas<\/h3>\n
FROM python:3.11<\/code> usando un tag mutable, una imagen comprometida publicada en ese tag ser\u00e1 incorporada en cada compilaci\u00f3n subsiguiente.<\/p>\nTemplates de CI\/CD Manipulados<\/h3>\n
uses: some-org\/some-action@main<\/code>, el c\u00f3digo ejecutado en su pipeline es controlado por quien tenga acceso de push a ese repositorio. Si el repositorio de la action es comprometido, cada pipeline que la referencia tambi\u00e9n queda comprometido.<\/p>\nTyposquatting<\/h3>\n
co1ors<\/code> (con un n\u00famero uno) en lugar de colors<\/code>, lodahs<\/code> en lugar de lodash<\/code>, o reqeusts<\/code> en lugar de requests<\/code>. Estos paquetes contienen c\u00f3digo malicioso y dependen de que los desarrolladores cometan errores tipogr\u00e1ficos al agregar dependencias. Las herramientas automatizadas han detectado miles de paquetes de typosquatting en npm y PyPI.<\/p>\nCuentas de Mantenedores Secuestradas<\/h3>\n
Plugins de Build Tools<\/h3>\n
Incidentes del Mundo Real<\/h3>\n
\n
event-stream<\/code> (1.5 millones de descargas semanales). Agreg\u00f3 una dependencia a un paquete malicioso, flatmap-stream<\/code>, que conten\u00eda c\u00f3digo cifrado dirigido a la billetera Bitcoin Copay, intentando robar criptomonedas.<\/li>\nua-parser-js<\/code> (7 millones de descargas semanales) fue secuestrado cuando la cuenta del mantenedor fue comprometida. Se publicaron versiones maliciosas que instalaban cryptominers y malware de robo de credenciales en sistemas Linux y Windows.<\/li>\nnode-ipc<\/code> a\u00f1adi\u00f3 deliberadamente c\u00f3digo que eliminaba archivos en sistemas con direcciones IP rusas o bielorrusas, demostrando que incluso los mantenedores de confianza pueden convertirse en un vector de amenaza (a veces llamado \u00abprotestware\u00bb).<\/li>\n<\/ul>\nC\u00f3mo Estos Ataques Explotan CI\/CD<\/h2>\n
Ejecuci\u00f3n Autom\u00e1tica de C\u00f3digo Durante las Compilaciones<\/h3>\n
npm install<\/code>, pip install -r requirements.txt<\/code> o docker build<\/code>, est\u00e1 ejecutando c\u00f3digo de fuentes externas. Esto sucede autom\u00e1ticamente en cada commit, pull request o compilaci\u00f3n programada. No hay un humano en el proceso para revisar qu\u00e9 c\u00f3digo se est\u00e1 realmente incorporando y ejecutando.<\/p>\nLos Entornos de Compilaci\u00f3n Tienen Acceso a Credenciales<\/h3>\n
Las Dependencias Obtenidas en Tiempo de Compilaci\u00f3n No Est\u00e1n Pre-Auditadas<\/h3>\n
package.json<\/code>, requirements.txt<\/code>) pero el c\u00f3digo real se obtiene fresco de los registros en tiempo de compilaci\u00f3n. Entre el momento en que un desarrollador agrega una dependencia y cuando el sistema CI la instala, el contenido del paquete podr\u00eda cambiar \u2014 o un paquete de confusi\u00f3n de dependencias podr\u00eda aparecer en el registro p\u00fablico. T\u00edpicamente no hay un paso de verificaci\u00f3n entre la resoluci\u00f3n y la ejecuci\u00f3n.<\/p>\nLas Dependencias Transitivas Expanden la Superficie de Ataque<\/h3>\n
event-stream<\/code> \u2014 el ataque se propaga a trav\u00e9s de todo el \u00e1rbol de dependencias sin ning\u00fan cambio en sus propios archivos de manifiesto.<\/p>\nDefensa Contra la Confusi\u00f3n de Dependencias<\/h2>\n
Utilice Namespace y Scope en Sus Paquetes Privados<\/h3>\n
@yourcompany\/package-name<\/code>. Un atacante no puede registrar paquetes bajo el scope de su organizaci\u00f3n en el registro p\u00fablico de npm.<\/p>\nConfigure la Prioridad del Registro Expl\u00edcitamente<\/h3>\n
.npmrc<\/code>:<\/strong><\/p>\n# Always fetch @yourcompany scoped packages from private registry\n@yourcompany:registry=https:\/\/npm.yourcompany.com\/\n\n# All other packages come from the public npm registry\nregistry=https:\/\/registry.npmjs.org\/\n\n# Authentication for private registry\n\/\/npm.yourcompany.com\/:_authToken=${NPM_PRIVATE_TOKEN}<\/code><\/pre>\npip.conf<\/code> para Python:<\/strong><\/p>\n# IMPORTANT: Use --index-url (NOT --extra-index-url) for your private registry\n# --extra-index-url checks BOTH registries and picks the higher version (vulnerable!)\n# --index-url uses ONLY your private registry as the primary source\n\n[global]\nindex-url = https:\/\/pypi.yourcompany.com\/simple\/\n\n# If you need public PyPI packages, configure your private registry\n# (Artifactory, Nexus) to proxy public PyPI \u2014 do NOT use --extra-index-url<\/code><\/pre>\n.yarnrc.yml<\/code> para Yarn Berry:<\/strong><\/p>\nnpmScopes:\n yourcompany:\n npmRegistryServer: \"https:\/\/npm.yourcompany.com\"\n npmAuthToken: \"${NPM_PRIVATE_TOKEN}\"\n\nnpmRegistryServer: \"https:\/\/registry.yarnpkg.com\"<\/code><\/pre>\nUtilice Proxies de Registro Privado<\/h3>\n
\n
Registro Defensivo<\/h3>\n
Fije Dependencias por Hash<\/h3>\n
# Generate hashes for your requirements\npip-compile --generate-hashes requirements.in -o requirements.txt\n\n# Install with hash verification\npip install --require-hashes -r requirements.txt<\/code><\/pre>\npackage-lock.json<\/code>. Aseg\u00farese de hacer commit del lockfile y use npm ci<\/code> (no npm install<\/code>) en CI para forzar la verificaci\u00f3n de integridad:<\/p>\n# In CI, always use npm ci \u2014 it strictly follows the lockfile\n# and verifies integrity hashes for every package\nnpm ci<\/code><\/pre>\nDefensa Contra el Envenenamiento de Artefactos<\/h2>\n
Fije Im\u00e1genes de Contenedores por Digest<\/h3>\n
latest<\/code> o incluso 3.11<\/code>. En su lugar, fije al digest SHA256 inmutable:<\/p>\n# Vulnerable: tag can be overwritten with a compromised image\nFROM python:3.11-slim\n\n# Secure: digest is immutable \u2014 this exact image or nothing\nFROM python:3.11-slim@sha256:a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2<\/code><\/pre>\nFije GitHub Actions por SHA<\/h3>\n
# Vulnerable: v3 tag can be moved to point to compromised code\n- uses: actions\/checkout@v3\n\n# Secure: pinned to specific commit SHA\n- uses: actions\/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v3.5.2<\/code><\/pre>\nVerifique Firmas en las Dependencias<\/h3>\n
\n
npm audit signatures<\/code> para verificar firmas del registro en los paquetes.<\/li>\nsigstore-python<\/code> est\u00e1n trayendo la verificaci\u00f3n de firmas a PyPI.<\/li>\n<\/ul>\nGenere y Rastree SBOMs<\/h3>\n
Automatice la Revisi\u00f3n de Dependencias<\/h3>\n
\n
Restrinja el Acceso a Red Durante las Compilaciones (Hermetic Builds)<\/h3>\n
--network=none<\/code> de Docker o pol\u00edticas de red espec\u00edficas de la plataforma CI.<\/p>\nPre-Apruebe y Cree Allowlists de Dependencias<\/h3>\n
Detecci\u00f3n y Monitoreo<\/h2>\n
Monitoree Nuevas Dependencias Inesperadas<\/h3>\n
Alerte sobre Saltos de Versi\u00f3n de Dependencias<\/h3>\n
1.2.3<\/code> a 99.0.0<\/code> es un fuerte indicador de un ataque de confusi\u00f3n de dependencias. Implemente monitoreo que alerte sobre cambios de versi\u00f3n inusuales, especialmente grandes saltos de versi\u00f3n mayor en paquetes internos.<\/p>\nAproveche las Herramientas de Escaneo de Seguridad<\/h3>\n
\n
Escanee Install Scripts y Hooks Post-Instalaci\u00f3n<\/h3>\n
preinstall<\/code>, install<\/code> o postinstall<\/code> en npm, o un setup.py<\/code> con c\u00f3digo ejecutable en Python.<\/p>\nCompare SBOMs Entre Compilaciones<\/h3>\n
Hardening Espec\u00edfico de CI\/CD<\/h2>\n
Haga Commit y Verifique Lock Files en CI<\/h3>\n
package-lock.json<\/code>, yarn.lock<\/code>, Pipfile.lock<\/code>, poetry.lock<\/code>) registran las versiones exactas y hashes de cada dependencia. Su pipeline de CI deber\u00eda fallar si el lock file tiene cambios inesperados.<\/p>\nname: Build\non: [push, pull_request]\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v3.5.2\n\n - name: Setup Node.js\n uses: actions\/setup-node@1a4442cacd436585916f1b3aa94e4166f1a22160 # v3.8.2\n with:\n node-version: '20'\n\n - name: Verify lockfile has not been tampered with\n run: |\n # npm ci will fail if package-lock.json is out of sync\n # with package.json or if integrity hashes don't match\n npm ci\n\n - name: Check for lockfile modifications\n run: |\n if ! git diff --exit-code package-lock.json; then\n echo \"ERROR: package-lock.json was modified during install.\"\n echo \"This could indicate a dependency confusion attack.\"\n exit 1\n fi\n\n - name: Audit dependencies\n run: npm audit --audit-level=high<\/code><\/pre>\nstages:\n - verify\n - build\n - test\n\nverify-dependencies:\n stage: verify\n image: python:3.11-slim@sha256:abc123... # Pin by digest\n script:\n - pip install pip-tools pip-audit\n # Verify that requirements.txt hashes match actual packages\n - pip install --require-hashes --no-deps -r requirements.txt\n # Audit for known vulnerabilities\n - pip-audit -r requirements.txt\n # Ensure no unexpected changes to lockfile\n - pip-compile --generate-hashes requirements.in -o \/tmp\/requirements-check.txt\n - diff requirements.txt \/tmp\/requirements-check.txt\n rules:\n - if: '$CI_PIPELINE_SOURCE == \"merge_request_event\"'\n - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'\n\nbuild:\n stage: build\n image: python:3.11-slim@sha256:abc123...\n script:\n - pip install --require-hashes --no-deps -r requirements.txt\n - python -m build\n needs: [verify-dependencies]<\/code><\/pre>\nSepare la Resoluci\u00f3n de Dependencias de la Ejecuci\u00f3n de Compilaci\u00f3n<\/h3>\n
Entornos de Compilaci\u00f3n Air-Gapped o con Red Restringida<\/h3>\n
# Docker-based hermetic build example\n# Phase 1: Fetch dependencies (with network)\ndocker run --name dep-fetch my-builder:latest \\\n npm ci --prefer-offline\n\n# Phase 2: Build (without network)\ndocker run --network=none -v deps:\/app\/node_modules \\\n my-builder:latest npm run build<\/code><\/pre>\nCachee Dependencias en Almacenamiento Interno de Confianza<\/h3>\n
Conclusi\u00f3n<\/h2>\n
npm install<\/code>, cada docker pull<\/code>, cada directiva uses:<\/code> en un workflow de GitHub Actions es una decisi\u00f3n de confianza \u2014 y los atacantes est\u00e1n trabajando activamente para abusar de esa confianza.<\/p>\n\n
npm ci<\/code> o --require-hashes<\/code>, deshabilite install scripts donde sea posible.<\/li>\n