En diciembre de 2020, el mundo descubri\u00f3 que SolarWinds<\/strong> \u2014 una plataforma de gesti\u00f3n de TI ampliamente confiable \u2014 hab\u00eda sido comprometida. Los atacantes inyectaron c\u00f3digo malicioso en el proceso de build del software Orion, distribuyendo una actualizaci\u00f3n contaminada a aproximadamente 18.000 organizaciones, incluyendo agencias del gobierno de EE.UU. y empresas del Fortune 500. El ataque no fue contra el repositorio de c\u00f3digo fuente de SolarWinds directamente, sino contra su build pipeline<\/em>. Este \u00fanico incidente redefini\u00f3 c\u00f3mo la industria piensa sobre la seguridad del software.<\/p>\n Luego lleg\u00f3 Log4Shell<\/strong> a finales de 2021. Una vulnerabilidad cr\u00edtica de ejecuci\u00f3n remota de c\u00f3digo en Apache Log4j \u2014 una biblioteca de logging de Java omnipresente \u2014 expuso a pr\u00e1cticamente todas las empresas del planeta. Las organizaciones se apresuraron a determinar si siquiera usaban<\/em> Log4j, revelando una falta fundamental de visibilidad sobre las dependencias de software. La lecci\u00f3n fue clara: no puedes asegurar lo que no puedes ver.<\/p>\n M\u00e1s recientemente, la backdoor de XZ Utils<\/strong> (CVE-2024-3094) a principios de 2024 demostr\u00f3 un vector de ataque a\u00fan m\u00e1s insidioso. Una campa\u00f1a paciente de ingenier\u00eda social a largo plazo permiti\u00f3 a un contribuidor malicioso insertar una backdoor en una biblioteca de compresi\u00f3n cr\u00edtica utilizada en casi todas las distribuciones de Linux. El ataque apunt\u00f3 espec\u00edficamente al sistema de build, activ\u00e1ndose solo bajo ciertas condiciones de compilaci\u00f3n \u2014 un ataque a la supply chain de extraordinaria sofisticaci\u00f3n.<\/p>\n Estos incidentes comparten un hilo com\u00fan: los atacantes ya no solo apuntan a tu c\u00f3digo de aplicaci\u00f3n \u2014 est\u00e1n apuntando a toda la cadena de herramientas, dependencias, procesos e infraestructura que entrega software a producci\u00f3n.<\/strong> Esta es la software supply chain, y asegurarla se ha convertido en uno de los desaf\u00edos m\u00e1s cr\u00edticos en la ingenier\u00eda moderna.<\/p>\n Esta gu\u00eda completa cubre cada dimensi\u00f3n de la seguridad de la supply chain de software \u2014 desde la gesti\u00f3n de dependencias hasta la integridad de builds, firma de artefactos, provenance, SBOMs y frameworks de cumplimiento. Ya seas ingeniero DevOps, arquitecto de seguridad o l\u00edder de ingenier\u00eda, esta gu\u00eda proporciona una hoja de ruta pr\u00e1ctica e integral para fortalecer tu software supply chain.<\/p>\n Antes de poder asegurar la supply chain, necesitamos entender sus componentes. Una supply chain de software moderna consta de cinco etapas interconectadas:<\/p>\n Aqu\u00ed es donde los desarrolladores escriben, revisan y hacen commit del c\u00f3digo. La etapa de c\u00f3digo fuente incluye sistemas de control de versiones (Git), procesos de code review, reglas de branch protection y firma de commits. Las amenazas en esta etapa incluyen cuentas de desarrolladores comprometidas, commits maliciosos y cambios no autorizados en archivos de configuraci\u00f3n de CI\/CD (pipeline poisoning).<\/p>\n Las aplicaciones modernas dependen en gran medida de bibliotecas y paquetes de terceros. Una aplicaci\u00f3n t\u00edpica de Node.js puede incorporar cientos o miles de dependencias transitivas. La etapa de dependencias abarca registros de paquetes (npm, PyPI, Maven Central), lockfiles, resoluci\u00f3n de versiones y escaneo de vulnerabilidades. Esta es una de las etapas m\u00e1s frecuentemente explotadas de la supply chain.<\/p>\n La etapa de build transforma el c\u00f3digo fuente y las dependencias en artefactos desplegables. Esto incluye compilaci\u00f3n, bundling, construcci\u00f3n de im\u00e1genes de contenedores y ejecuci\u00f3n de tests. Los sistemas de build \u2014 ya sea Jenkins, GitHub Actions, GitLab CI u otros \u2014 son objetivos de alto valor porque comprometer un proceso de build puede inyectar c\u00f3digo malicioso en cada artefacto producido.<\/p>\n Los outputs del build \u2014 im\u00e1genes de contenedores, binarios, paquetes \u2014 se almacenan en registros de artefactos (Docker Hub, Amazon ECR, Artifactory, etc.). La etapa de artefactos involucra firma, verificaci\u00f3n, adjunci\u00f3n de metadata y control de acceso. Sin controles de integridad adecuados, los artefactos pueden ser manipulados despu\u00e9s del build.<\/p>\n La etapa final entrega los artefactos a los entornos de producci\u00f3n. El despliegue involucra plataformas de orquestaci\u00f3n (Kubernetes), admission controllers, aplicaci\u00f3n de pol\u00edticas y verificaci\u00f3n en runtime. Esta es la \u00faltima l\u00ednea de defensa \u2014 el punto donde verificas que lo que est\u00e1s desplegando es exactamente lo que fue construido.<\/p>\n Cada etapa presenta superficies de ataque \u00fanicas y requiere medidas defensivas espec\u00edficas. El resto de esta gu\u00eda recorre cada una en detalle.<\/p>\n Las dependencias son posiblemente el componente m\u00e1s vulnerable de la software supply chain. La investigaci\u00f3n muestra consistentemente que m\u00e1s del 80% del c\u00f3digo en las aplicaciones modernas proviene de dependencias de c\u00f3digo abierto. Esto crea una enorme superficie de ataque que es dif\u00edcil de monitorear y controlar.<\/p>\n Dependency confusion<\/strong> (tambi\u00e9n llamada confusi\u00f3n de namespace) explota la forma en que los gestores de paquetes resuelven dependencias. Cuando una organizaci\u00f3n usa paquetes internos con nombres que no existen en registros p\u00fablicos, un atacante puede publicar un paquete malicioso con el mismo nombre en el registro p\u00fablico. Si el gestor de paquetes est\u00e1 mal configurado, puede descargar el paquete del atacante en lugar del interno. Este vector de ataque fue demostrado famosamente por el investigador de seguridad Alex Birsan en 2021, afectando a Apple, Microsoft y otras grandes empresas.<\/p>\n Typosquatting<\/strong> apunta a desarrolladores que cometen errores tipogr\u00e1ficos al especificar nombres de paquetes. Los atacantes publican paquetes maliciosos con nombres que se asemejan mucho a bibliotecas populares \u2014 por ejemplo, Cuentas de mantenedores comprometidas<\/strong> permiten a los atacantes enviar actualizaciones maliciosas a paquetes leg\u00edtimos y ampliamente utilizados. El incidente de Para una inmersi\u00f3n profunda en estos vectores de ataque y defensas pr\u00e1cticas, consulta nuestra gu\u00eda detallada: Dependency Confusion y Artifact Poisoning: Ataques y Defensas<\/a>.<\/p>\n Lockfiles y version pinning:<\/strong> Siempre haz commit de los lockfiles ( Configuraci\u00f3n de registro privado:<\/strong> Configura los gestores de paquetes para resolver paquetes internos exclusivamente desde tu registro privado. Usa paquetes con scope (por ejemplo, Escaneo de vulnerabilidades:<\/strong> Integra herramientas de Software Composition Analysis (SCA) en tu pipeline de CI\/CD. Herramientas como Revisi\u00f3n de dependencias y allow-listing:<\/strong> Establece un proceso de revisi\u00f3n para nuevas dependencias. Eval\u00faa los paquetes bas\u00e1ndote en la actividad de mantenimiento, cantidad de contribuidores, estad\u00edsticas de descargas y vulnerabilidades conocidas. Algunas organizaciones mantienen una allow-list de paquetes aprobados y requieren revisi\u00f3n de seguridad antes de agregar nuevos.<\/p>\n La etapa de build es donde el c\u00f3digo fuente y las dependencias se transforman en artefactos desplegables. Si un atacante puede comprometer el proceso de build, puede inyectar c\u00f3digo malicioso en el output sin modificar el c\u00f3digo fuente \u2014 exactamente como sucedi\u00f3 en el ataque de SolarWinds. La integridad del build asegura que el proceso de build en s\u00ed mismo sea confiable.<\/p>\n Un build reproducible<\/strong> es aquel que produce un output id\u00e9ntico dado el mismo c\u00f3digo fuente, dependencias, entorno de build e instrucciones de build. La reproducibilidad es una propiedad de seguridad poderosa porque permite la verificaci\u00f3n independiente: cualquiera puede reconstruir desde los mismos inputs y confirmar que el output coincide. Si el output difiere, indica manipulaci\u00f3n.<\/p>\n Lograr builds reproducibles requiere eliminar fuentes de no-determinismo:<\/p>\n Un build herm\u00e9tico<\/strong> est\u00e1 aislado del entorno del host y de la red. Solo puede acceder a inputs expl\u00edcitamente declarados \u2014 sin llamadas de red, sin acceso a rutas del filesystem del host fuera del sandbox de build, sin dependencia de herramientas preinstaladas. Los builds herm\u00e9ticos aseguran que el output del build dependa solo de inputs declarados, haciendo imposible que un atacante inyecte dependencias o herramientas adicionales durante el proceso de build.<\/p>\n Sistemas de build como Bazel<\/strong>, Buck2<\/strong> y Pants<\/strong> est\u00e1n dise\u00f1ados para builds herm\u00e9ticos desde su concepci\u00f3n. Para builds de contenedores, herramientas como BuildKit<\/strong> con aislamiento de red y ko<\/strong> para aplicaciones Go proporcionan capacidades de build herm\u00e9tico.<\/p>\n Para un recorrido completo de implementaci\u00f3n de builds reproducibles y herm\u00e9ticos en tu pipeline de CI\/CD, consulta: Integridad del Build: Builds Reproducibles en CI\/CD<\/a>.<\/p>\n M\u00e1s all\u00e1 del proceso de build en s\u00ed, la plataforma de build requiere hardening:<\/p>\n Una vez que un build produce un artefacto \u2014 una imagen de contenedor, un binario, un paquete \u2014 \u00bfc\u00f3mo te aseguras de que no ha sido manipulado antes del despliegue? La firma de artefactos<\/strong> proporciona prueba criptogr\u00e1fica de que un artefacto fue producido por un proceso de build confiable y no ha sido modificado desde entonces.<\/p>\n La firma de c\u00f3digo tradicional depende de claves criptogr\u00e1ficas de larga duraci\u00f3n. Esto crea desaf\u00edos operacionales significativos: generaci\u00f3n de claves, almacenamiento seguro, rotaci\u00f3n, revocaci\u00f3n y distribuci\u00f3n. Si una clave de firma es comprometida, cada artefacto firmado con esa clave es sospechoso. La gesti\u00f3n de claves ha sido hist\u00f3ricamente tan onerosa que muchos equipos simplemente omiten la firma por completo.<\/p>\n Sigstore<\/strong> es un proyecto open-source que simplifica fundamentalmente la firma de artefactos al eliminar la necesidad de claves de larga duraci\u00f3n. Sigstore consta de varios componentes:<\/p>\n En un pipeline de CI\/CD, la firma keyless con Sigstore funciona de la siguiente manera:<\/p>\n En el momento del despliegue, verificas la firma comprobando el transparency log de Rekor y validando que la identidad de firma coincide con tu workflow de CI\/CD esperado.<\/p>\n Para un tutorial pr\u00e1ctico sobre la implementaci\u00f3n de Sigstore y Cosign en tu pipeline, consulta: Firma y Verificaci\u00f3n de Im\u00e1genes de Contenedores con Sigstore y Cosign<\/a>.<\/p>\n La firma te dice qui\u00e9n<\/em> produjo un artefacto, pero no te dice c\u00f3mo<\/em> fue producido. El provenance<\/strong> responde las preguntas cr\u00edticas: \u00bfQu\u00e9 c\u00f3digo fuente se us\u00f3? \u00bfQu\u00e9 proceso de build se ejecut\u00f3? \u00bfQu\u00e9 dependencias se incluyeron? \u00bfQu\u00e9 builder se us\u00f3? El provenance proporciona un registro verificable del origen del artefacto y su proceso de build.<\/p>\n SLSA<\/strong> (Supply-chain Levels for Software Artifacts, pronunciado \u00absalsa\u00bb) es un framework desarrollado por Google y la OpenSSF que define niveles crecientes de seguridad de la supply chain. En su n\u00facleo, SLSA especifica un formato est\u00e1ndar de provenance que captura:<\/p>\n El provenance SLSA es generado por la plataforma de build (no por el script de build), lo cual es crucial \u2014 significa que un script de build comprometido no puede falsificar su propio provenance. Plataformas como GitHub Actions y Google Cloud Build tienen generadores nativos de provenance SLSA.<\/p>\n in-toto<\/strong> es un framework para asegurar la integridad de toda la software supply chain. Mientras SLSA se enfoca principalmente en el provenance del build, in-toto proporciona un framework de attestation m\u00e1s general que puede capturar cualquier paso en la supply chain \u2014 code review, testing, escaneo, aprobaci\u00f3n y despliegue.<\/p>\n Una attestation in-toto sigue el formato DSSE (Dead Simple Signing Envelope)<\/strong> y consiste en:<\/p>\n Se pueden adjuntar m\u00faltiples attestations a un solo artefacto, creando un conjunto rico de metadata que los motores de pol\u00edticas pueden evaluar en el momento del despliegue.<\/p>\n Para una gu\u00eda detallada sobre generaci\u00f3n y verificaci\u00f3n de provenance y attestations, consulta: Artifact Provenance y Attestations: SLSA e in-toto<\/a>.<\/p>\n Un SBOM<\/strong> (Software Bill of Materials) es un inventario completo de todos los componentes, bibliotecas y dependencias en un artefacto de software. Piensa en ello como una etiqueta nutricional para el software \u2014 le dice a los consumidores exactamente qu\u00e9 hay dentro. Los SBOMs se han convertido en un requisito regulatorio en muchos contextos y son esenciales para la gesti\u00f3n de vulnerabilidades y la respuesta a incidentes.<\/p>\n Cuando Log4Shell impact\u00f3 en diciembre de 2021, las organizaciones que pudieron determinar r\u00e1pidamente si usaban Log4j \u2014 y d\u00f3nde \u2014 pudieron responder en horas. Las organizaciones sin esta visibilidad tardaron semanas o meses. Los SBOMs proporcionan esta visibilidad de forma proactiva, antes de que ocurra un incidente.<\/p>\n Los SBOMs sirven para m\u00faltiples prop\u00f3sitos:<\/p>\n Dos formatos principales de SBOM dominan la industria:<\/p>\n Los SBOMs deben generarse como parte del pipeline de CI\/CD, lo m\u00e1s cerca posible del paso de build. Las herramientas comunes para la generaci\u00f3n de SBOMs incluyen:<\/p>\n Generar un SBOM es solo el primer paso. Para hacer los SBOMs confiables, deben ser firmados y adjuntados a los artefactos como attestations. Usando Cosign, puedes hacer attest de un SBOM a una imagen de contenedor:<\/p>\n Esto crea una attestation firmada que vincula el SBOM a un digest de artefacto espec\u00edfico, asegurando que el SBOM no pueda ser separado o falsificado para el artefacto que describe. Los consumidores pueden entonces verificar tanto la firma del artefacto como la attestation del SBOM antes del despliegue.<\/p>\n Para un laboratorio pr\u00e1ctico sobre generaci\u00f3n, escaneo y attestation de SBOMs, consulta nuestro laboratorio de SBOMs en la serie de CI\/CD Security<\/a>.<\/p>\n Varios frameworks y est\u00e1ndares proporcionan enfoques estructurados para la seguridad de la supply chain. Comprender estos frameworks ayuda a las organizaciones a priorizar inversiones y demostrar cumplimiento.<\/p>\n SLSA define cuatro niveles de madurez creciente en seguridad de la supply chain:<\/p>\n Para una checklist pr\u00e1ctica de cumplimiento y gu\u00eda de implementaci\u00f3n para cada nivel SLSA, consulta: Niveles SLSA Explicados: Una Checklist Pr\u00e1ctica de Cumplimiento<\/a>.<\/p>\n El SSDF<\/strong> (SP 800-218) proporciona un conjunto de pr\u00e1cticas de alto nivel y agn\u00f3sticas de tecnolog\u00eda para el desarrollo seguro de software. Est\u00e1 organizado en cuatro grupos:<\/p>\n El SSDF es particularmente relevante para organizaciones que suministran software al gobierno federal de EE.UU., ya que es referenciado por la Orden Ejecutiva 14028 y los memorandos relacionados de la OMB.<\/p>\n El OWASP SCVS<\/strong> proporciona un framework enfocado espec\u00edficamente en el an\u00e1lisis de componentes de software y la gesti\u00f3n de riesgos de la supply chain. Define requisitos de verificaci\u00f3n en seis categor\u00edas: BOM, identidad del software, provenance, integridad de paquetes, an\u00e1lisis de componentes y pedigree. SCVS es \u00fatil como una checklist detallada para evaluar las pr\u00e1cticas de seguridad de la supply chain de tu organizaci\u00f3n.<\/p>\n El proyecto OpenSSF Scorecard<\/strong> eval\u00faa autom\u00e1ticamente proyectos open-source contra un conjunto de heur\u00edsticas de seguridad \u2014 branch protection, pinning de dependencias, releases firmados, tests de CI y m\u00e1s. Ejecutar Scorecard contra tus dependencias te ayuda a evaluar su postura de seguridad e identificar riesgos. Integrar Scorecard en tu proceso de revisi\u00f3n de dependencias agrega una capa adicional de defensa.<\/p>\n Asegurar una software supply chain es un viaje, no un proyecto \u00fanico. La siguiente hoja de ruta por fases proporciona un camino pr\u00e1ctico desde la higiene fundacional hasta posturas de seguridad avanzadas.<\/p>\n Enfoque en visibilidad y controles b\u00e1sicos:<\/p>\n Agrega controles de integridad criptogr\u00e1fica:<\/p>\n Aplica pol\u00edticas en el momento del despliegue:<\/p>\n Persigue defensa en profundidad y mejora continua:<\/p>\n La teor\u00eda es importante, pero la pr\u00e1ctica es esencial. Los siguientes laboratorios proporcionan experiencia pr\u00e1ctica con las herramientas y t\u00e9cnicas cubiertas en esta gu\u00eda:<\/p>\n Elegir las herramientas correctas es cr\u00edtico para una seguridad efectiva de la supply chain. Las siguientes gu\u00edas de comparaci\u00f3n te ayudan a evaluar opciones en categor\u00edas clave:<\/p>\n Para comparaciones detalladas de estas herramientas, incluyendo matrices de caracter\u00edsticas y orientaci\u00f3n de recomendaciones, consulta nuestra Comprendiendo el Modelo de Supply Chain de Software<\/h2>\n
1. C\u00f3digo Fuente<\/h3>\n
2. Dependencias<\/h3>\n
3. Build<\/h3>\n
4. Artefactos<\/h3>\n
5. Despliegue<\/h3>\n
Riesgos y Defensas de Dependencias<\/h2>\n
Ataques Comunes a Dependencias<\/h3>\n
reqeusts<\/code> en lugar de requests<\/code>, o lodash-utils<\/code> imitando a lodash<\/code>. Estos paquetes a menudo contienen c\u00f3digo de exfiltraci\u00f3n de datos o miner\u00eda de criptomonedas.<\/p>\nevent-stream<\/code> en 2018 y el compromiso de ua-parser-js<\/code> en 2021 son ejemplos notables. Debido a que los paquetes son leg\u00edtimos y confiables, el c\u00f3digo malicioso se propaga r\u00e1pidamente.<\/p>\nEstrategias Defensivas<\/h3>\n
package-lock.json<\/code>, Pipfile.lock<\/code>, go.sum<\/code>, Cargo.lock<\/code>) en el control de versiones. Los lockfiles registran las versiones exactas y los hashes de integridad de cada dependencia, asegurando instalaciones reproducibles. Fija las dependencias a versiones exactas en lugar de usar rangos de versiones para prevenir actualizaciones inesperadas.<\/p>\n@tuempresa\/nombre-paquete<\/code>) y configura mapeos de registro para prevenir ataques de dependency confusion. Herramientas como Artifactory y Nexus pueden actuar como proxy de registros p\u00fablicos mientras proporcionan una capa adicional de escaneo y control.<\/p>\nTrivy<\/code>, Grype<\/code>, Snyk<\/code> y Dependabot<\/code> escanean dependencias contra bases de datos de vulnerabilidades (NVD, OSV, GitHub Advisory Database) y pueden bloquear builds que introducen vulnerabilidades conocidas. Para una comparaci\u00f3n de herramientas de escaneo disponibles, consulta nuestras gu\u00edas de comparaci\u00f3n de herramientas de CI\/CD Security<\/a>.<\/p>\nIntegridad del Build: Builds Reproducibles y Herm\u00e9ticos<\/h2>\n
Builds Reproducibles<\/h3>\n
\n
SOURCE_DATE_EPOCH<\/code> para normalizar los timestamps.<\/li>\nBuilds Herm\u00e9ticos<\/h3>\n
Seguridad de la Plataforma de Build<\/h3>\n
\n
.github\/workflows\/<\/code>, .gitlab-ci.yml<\/code>, Jenkinsfile<\/code>) deben estar protegidos por reglas de branch protection y requerir code review para cambios.<\/li>\nFirma y Verificaci\u00f3n de Artefactos con Sigstore y Cosign<\/h2>\n
El Desaf\u00edo de la Firma Tradicional<\/h3>\n
Sigstore: Firma Keyless para la Software Supply Chain<\/h3>\n
\n
Firma Keyless en CI\/CD<\/h3>\n
\n
Provenance y Attestations: SLSA e in-toto<\/h2>\n
SLSA Provenance<\/h3>\n
\n
Attestations in-toto<\/h3>\n
\n
Software Bills of Materials (SBOMs)<\/h2>\n
Por Qu\u00e9 los SBOMs Importan<\/h3>\n
\n
Formatos de SBOM<\/h3>\n
\n
Generaci\u00f3n de SBOMs<\/h3>\n
\n
Attestation de SBOMs<\/h3>\n
cosign attest --predicate sbom.spdx.json --type spdxjson <image><\/code><\/pre>\nFrameworks y Est\u00e1ndares<\/h2>\n
SLSA (Supply-chain Levels for Software Artifacts)<\/h3>\n
\n
NIST SSDF (Secure Software Development Framework)<\/h3>\n
\n
OWASP Software Component Verification Standard (SCVS)<\/h3>\n
OpenSSF Scorecard<\/h3>\n
Hoja de Ruta de Implementaci\u00f3n<\/h2>\n
Fase 1: Fundaci\u00f3n (Semanas 1-4)<\/h3>\n
\n
Fase 2: Integridad (Semanas 5-12)<\/h3>\n
\n
slsa-github-generator<\/code>.<\/li>\nFase 3: Verificaci\u00f3n (Semanas 13-20)<\/h3>\n
\n
Fase 4: Avanzado (Continuo)<\/h3>\n
\n
Laboratorios Pr\u00e1cticos<\/h2>\n
\n
Herramientas y Comparaciones<\/h2>\n
\n\n
\n \nCategor\u00eda<\/th>\n Herramientas<\/th>\n Caso de Uso<\/th>\n<\/tr>\n<\/thead>\n \n Esc\u00e1neres de Vulnerabilidades<\/strong><\/td>\n Trivy, Grype, Snyk, Clair<\/td>\n Escaneo de dependencias e im\u00e1genes de contenedores en busca de vulnerabilidades conocidas<\/td>\n<\/tr>\n \n Firma de Artefactos<\/strong><\/td>\n Cosign, Notation, GPG<\/td>\n Firma criptogr\u00e1fica de artefactos para asegurar integridad y autenticidad<\/td>\n<\/tr>\n \n Generaci\u00f3n de SBOMs<\/strong><\/td>\n Syft, Trivy, cdxgen, CycloneDX CLI<\/td>\n Creaci\u00f3n de inventarios de componentes de software en formato SPDX o CycloneDX<\/td>\n<\/tr>\n \n Provenance<\/strong><\/td>\n SLSA GitHub Generator, Witness, in-toto<\/td>\n Generaci\u00f3n de provenance de build verificable y attestations<\/td>\n<\/tr>\n \n Aplicaci\u00f3n de Pol\u00edticas<\/strong><\/td>\n Kyverno, OPA Gatekeeper, Sigstore Policy Controller<\/td>\n Aplicaci\u00f3n de pol\u00edticas de supply chain en el momento del despliegue mediante admission de Kubernetes<\/td>\n<\/tr>\n \n Gesti\u00f3n de Dependencias<\/strong><\/td>\n Dependabot, Renovate, Socket.dev<\/td>\n Actualizaciones automatizadas de dependencias, monitoreo y detecci\u00f3n de paquetes maliciosos<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n