[{"data":1,"prerenderedAt":146},["ShallowReactive",2],{"seo-verification":3,"blog-proteger-la-cadena-de-suministro-npm-tras-asyncapi-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-proteger-la-cadena-de-suministro-npm-tras-asyncapi-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":79,"ctaBody":80,"ctaButton":81,"ctaUrl":82,"relatedPosts":83},202,"proteger-la-cadena-de-suministro-npm-tras-asyncapi",{"fr":12,"en":13,"ar":14,"es":10},"securiser-chaine-approvisionnement-npm-ci","securing-your-npm-ci-supply-chain-after-asyncapi","تأمين-سلسلة-توريد-npm-في-ci-بعد-حادثة-asyncapi","Proteger su cadena CI de npm tras AsyncAPI","Lockfile, verificación de hashes, SLSA y SCA automatizado: cómo endurecer su pipeline CI tras el incidente AsyncAPI de julio de 2026.",4,0,false,"2026-08-01T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":17,"name":23,"slug":24,"color":25,"icon":26},"Desarrollo","developpement","bg-warning\u002F10 text-warning","dev",[28],{"id":17,"name":23,"slug":24,"color":25,"icon":26},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fsecuriser-chaine-approvisionnement-npm-ci-poster.svg","En julio de 2026, varios paquetes del proyecto AsyncAPI se publicaron en npm con firmas OIDC válidas: las herramientas de detección habituales no vieron nada. Este incidente demostró que una cadena CI que solo verifica el lockfile o la firma sigue siendo vulnerable a un compromiso aguas arriba. Así puede añadir las capas de control que faltaban.",[34,38,48,51,73,76],{"type":35,"title":36,"body":37},"h2","Lo que cambió el incidente AsyncAPI","Durante dos semanas de julio de 2026, cinco versiones de paquetes de AsyncAPI circularon con una procedencia OIDC firmada, un mecanismo introducido precisamente para garantizar el origen de un paquete. Los atacantes habían comprometido el pipeline de publicación, no la clave de firma. Resultado: `npm audit signatures` devolvía un resultado limpio y los gestores de dependencias no lanzaban ninguna alerta. Esto cambia la manera de pensar la seguridad de las dependencias: la firma prueba la integridad del paquete en el momento de su publicación, no la integridad del proceso que lo produjo.",{"type":39,"title":40,"items":41},"ul","Medidas concretas que hay que implantar",[42,43,44,45,46,47],"**Política --frozen-lockfile** — prohibir cualquier modificación silenciosa del package-lock.json en CI (`npm ci` lo impone de forma nativa, `--frozen-lockfile` para yarn\u002Fpnpm).","**Verificación de los hashes en CI** — añadir un job que compare los hashes SHA-512 del lockfile con los registros de npm y detecte cualquier divergencia.","**SCA automatizado** — integrar un escáner de composición de software (OWASP Dependency-Check, Trivy, Snyk) como etapa bloqueante del pipeline.","**Procedencia SLSA de nivel 2 como mínimo** — en sus publicaciones, generar y adjuntar las atestaciones SLSA; en sus consumos, comprobar que los paquetes críticos disponen de ellas.","**Vigilancia de los digests de imagen** — anclar cada imagen Docker a su digest sha256 en lugar de a una etiqueta flotante.","**Alertas sobre las versiones nuevas no planificadas** — configurar Dependabot o Renovate para que avisen de toda versión publicada fuera de su ventana habitual.",{"type":35,"title":49,"body":50},"Lo que el lockfile garantiza — y lo que no garantiza","El package-lock.json registra la versión exacta y el hash de cada dependencia resuelta. Impide una subida de versión silenciosa en un `npm install` posterior. Lo que no hace: comprobar que el contenido del paquete correspondiente no ha cambiado en el registry después de su resolución inicial, ni que el pipeline que produjo el paquete estaba a su vez sano. El lockfile es una instantánea de lo que usted resolvió un día concreto, no una garantía sobre la cadena de fabricación aguas arriba.",{"type":52,"title":53,"steps":54},"steps","Endurecer su pipeline CI paso a paso",[55,58,61,64,67,70],{"title":56,"body":57},"Pasar a `npm ci` y desterrar `npm install` en CI","Sustituya todo `npm install` de sus workflows por `npm ci`. El comando se niega a ejecutarse si el package-lock.json falta o diverge del package.json. Añada `--ignore-scripts` si su árbol contiene postinstall de terceros sin auditar.",{"title":59,"body":60},"Activar `npm audit` en modo bloqueante","Añada `npm audit --audit-level=high` después de `npm ci` y antes del build. En GitHub Actions, la etapa falla si se detecta un resultado de severidad alta. Diferencie las dependencias de desarrollo con `--omit=dev`.",{"title":62,"body":63},"Verificar los hashes con `npm audit signatures`","Desde npm 8.8, `npm audit signatures` comprueba que cada paquete instalado tiene una firma válida registrada en el registry. Ejecute este comando después de `npm ci`. No detecta los casos como el de AsyncAPI (firma válida pero pipeline comprometido), pero constituye una primera red de seguridad.",{"title":65,"body":66},"Integrar un escáner SCA (Trivy u OWASP Dependency-Check)","Añada un job SCA independiente en su workflow de CI. Trivy analiza el package-lock.json directamente (`trivy fs --scanners vuln .`) sin necesidad de instalar las dependencias. Configúrelo para que falle ante las CVE con una puntuación CVSS superior a 7.",{"title":68,"body":69},"Consumir y emitir atestaciones SLSA","Para sus propios paquetes publicados, active la procedencia SLSA en su workflow de publicación (GitHub Actions slsa-framework\u002Fslsa-github-generator). Para las dependencias de terceros, verifique las atestaciones de los paquetes críticos a través de la API de Sigstore.",{"title":71,"body":72},"Fijar las actions de CI y las imágenes a su digest sha256","En sus archivos .github\u002Fworkflows\u002F*.yml o .gitlab-ci.yml, sustituya las etiquetas flotantes por digests sha256. Una etiqueta flotante puede apuntar a una imagen distinta al día siguiente de un compromiso del registry.",{"type":74,"body":75},"tip","No parchee nunca una dependencia directamente en producción modificando node_modules a mano: el lockfile divergiría y el siguiente despliegue desde la CI reintroduciría el paquete original. Toda corrección pasa por el lockfile versionado y se vuelve a aplicar desde la CI.",{"type":35,"title":77,"body":78},"Integración en su workflow Git alojado","Estos controles son etapas del pipeline, no costumbres manuales: pertenecen a su ci.yml (GitHub Actions) o a su .gitlab-ci.yml, y se disparan en cada push y en cada pull request. En un repositorio autoalojado (Gitea, GitLab CE), se aplican las mismas recetas. Proteja su rama principal con una regla de merge condicionada a la CI en verde y bloquee los merges si alguno de esos jobs SCA falla.","Entornos CI aislados para sus pipelines de build","Despliegue sus runners de CI en un VPS Cloud dedicado: aislamiento de red, control total de las dependencias del sistema y ningún recurso compartido con otros tenants.","Soluciones para desarrolladores","\u002Fsolutions\u002Fdeveloppeurs",[84,106,129],{"id":85,"slug":86,"slugs":87,"title":91,"excerpt":92,"readTime":17,"views":93,"isPinned":19,"publishedAt":94,"updatedAt":21,"category":95,"categories":100,"featuredImage":29,"bgImage":30,"posterImage":102,"relatedSolution":103},99,"gitea-vs-gitlab-que-forja-git-self-hosted-en-vps",{"fr":88,"en":89,"ar":90,"es":86},"gitea-vs-gitlab","gitea-vs-gitlab-which-self-hosted-git-forge-on-a-vps","gitea-مقابل-gitlab-أي-منصة-git-مستضافة-ذاتيا-على-vps","Gitea vs GitLab: ¿qué forja Git self-hosted en VPS?","Gitea vs GitLab self-hosted: huella de memoria, CI\u002FCD, registros y escalabilidad comparados para elegir su forja Git en un VPS.",2,"2026-03-13T00:00:00+00:00",{"id":96,"name":97,"slug":98,"color":99,"icon":98},5,"Comparativas","comparatif","bg-info\u002F10 text-info",[101],{"id":96,"name":97,"slug":98,"color":99,"icon":98},"\u002Fblog\u002Fcovers\u002Fgitea-vs-gitlab-poster.svg",{"categorySlug":104,"appSlug":105},"desarrollo","gitea",{"id":107,"slug":108,"slugs":109,"title":113,"excerpt":114,"readTime":17,"views":115,"isPinned":19,"publishedAt":116,"updatedAt":21,"category":117,"categories":123,"featuredImage":29,"bgImage":30,"posterImage":125,"relatedSolution":126},108,"proteger-vps-con-crowdsec",{"fr":110,"en":111,"ar":112,"es":108},"securiser-vps-crowdsec","securing-your-vps-with-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","Proteger su VPS con CrowdSec","Despliegue CrowdSec en su VPS para bloquear los ataques gracias a una detección de comportamiento y a una blocklist comunitaria compartida.",1,"2026-03-04T00:00:00+00:00",{"id":118,"name":119,"slug":120,"color":121,"icon":122},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[124],{"id":118,"name":119,"slug":120,"color":121,"icon":122},"\u002Fblog\u002Fcovers\u002Fsecuriser-vps-crowdsec-poster.svg",{"categorySlug":127,"appSlug":128},"ciberseguridad-bastion","crowdsec",{"id":130,"slug":131,"slugs":132,"title":136,"excerpt":137,"readTime":138,"views":18,"isPinned":19,"publishedAt":139,"updatedAt":21,"category":140,"categories":141,"featuredImage":29,"bgImage":30,"posterImage":143,"relatedSolution":144},43,"desplegar-una-aplicacion-nodejs-en-un-vps",{"fr":133,"en":134,"ar":135,"es":131},"deployer-nodejs-vps","deploy-a-nodejs-application-on-a-vps","نشر-تطبيق-nodejs-على-vps","Desplegar una aplicación Node.js en un VPS","Despliegue una aplicación Node.js en producción en un VPS: PM2, reverse proxy Nginx, SSL Let's Encrypt y arranque automático con el sistema.",3,"2026-05-08T00:00:00+00:00",{"id":17,"name":23,"slug":24,"color":25,"icon":26},[142],{"id":17,"name":23,"slug":24,"color":25,"icon":26},"\u002Fblog\u002Fcovers\u002Fdeployer-nodejs-vps-poster.svg",{"categorySlug":104,"appSlug":145},"nodejs-stack",1789665032591]