🧿 Cadena de Suministro de Software

Toda tu seguridad depende de cada eslabón: desde el código que no escribiste hasta el hardware donde se ejecuta.

1. EXPLICACIÓN EN PROFUNDIDAD

¿Qué es?

La cadena de suministro de software incluye todos los elementos, servicios, personas y tecnologías que participan en la creación, empaquetado, distribución, instalación y mantenimiento del software.

Esto implica:

• Código propio.

• Librerías de terceros.

• Entornos de construcción.

• CI/CD.

• Infraestructura (cloud, hardware).

• Firmas digitales y entrega.

¿Cómo se introducen vulnerabilidades?

A través de:

• Librerías comprometidas (ej: log4j).

• Repositorios falsos o inyectados (typosquatting).

• Firmware o controladores maliciosos.

• Manipulación en el empaquetado o en el CI/CD.

• Proveedores externos con seguridad deficiente.

🧠 ALEGORÍA REALISTA – Comida en un restaurante

Imagina que vas a un restaurante y pides una paella. Tú solo ves el plato final, pero no sabes:

• Quién cultivó el arroz (proveedor de software base).

• Si el marisco es fresco o congelado (librerías externas).

• Si la cocina está limpia (proceso de build).

• Si el chef está enfermo (desarrollador comprometido).

• O si alguien manipuló el plato en el camino (cadena de distribución).

Un solo fallo en ese proceso puede envenenar al comensal.
En software, una sola dependencia vulnerable o maliciosa puede abrir la puerta al atacante.

2. EJEMPLOS PRÁCTICOS

🎯 Casos reales:

• SolarWinds (2020): se insertó malware en el build del software Orion que fue firmado y distribuido a miles de clientes, incluyendo gobiernos.

• Log4Shell (2021): una vulnerabilidad en una librería ampliamente usada (log4j) permitió ejecución remota en miles de sistemas.

• Event-Stream (2018): se introdujo código malicioso en una dependencia de Node.js usada por millones de apps.

• ASUS Live Update (2019): atacantes firmaron firmware malicioso usando certificados válidos.

3. HERRAMIENTAS Y SOLUCIONES REALES

🧰 Escaneo y visibilidad (SCA – Software Composition Analysis)

• OWASP Dependency-Check Escanea tus dependencias y genera un informe con sus versiones y vulnerabilidades conocidas (CVEs). Detecta componentes obsoletos y peligrosos.
• OWASP Dependency-Track Plataforma que recibe informes de Dependency-Check y los gestiona como un sistema continuo de gestión de SBOM. Soporta alertas y cumplimiento.
• CycloneDX Especificación estándar de SBOM ligera y rápida de generar. Compatible con múltiples lenguajes y herramientas modernas.
• SPDX Estándar abierto más detallado y formal. Incluye licencias, metadatos legales, seguridad y origen de componentes.
• Syft (de Anchore) Escáner de contenedores e imágenes Docker para generar SBOM automáticamente. Compatible con CycloneDX y SPDX.
• Grype Motor de detección de vulnerabilidades que trabaja con Syft para comparar el SBOM con bases de datos CVE.
• Snyk / Sonatype Nexus / GitHub Dependabot Escanean repositorios y notificaciones automáticas sobre librerías vulnerables. Snyk incluso sugiere fixes.

4. VISIÓN ESTRATÉGICA

🔴 Red Team – Cómo se explota

Nivel 1 – Básico

• Buscar librerías conocidas vulnerables (log4j, struts, jquery, etc.).

• Escanear repositorios con truffleHog para detectar claves expuestas.

Nivel 2 – Intermedio

• Subir librerías maliciosas con nombres parecidos (typosquatting).

• Insertar backdoors en paquetes compartidos (supply chain poisoning).

Nivel 3 – Avanzado

• Comprometer el pipeline de CI/CD (GitHub Actions, Jenkins).

• Falsificar firmas digitales o manipular controladores en firmware.

🔵 Blue Team – Cómo se defiende

Nivel 1 – Básico

• Usar escaneo SCA con Dependency-Check.

• Parchear librerías obsoletas y evitar dependencias sin mantenimiento.

Nivel 2 – Intermedio

• Implementar un SBOM obligatorio para cada build.

• Aislar los entornos de desarrollo y producción.

• Validar firmas de binarios y firmware.

Nivel 3 – Avanzado

• Supervisar pipelines y validar integridad con hashes.

• Firmar código internamente (code signing + verificación).

• Establecer políticas para fuentes confiables en repos y paquetes.

🟣 Purple Team – Cómo se valida y mejora

Nivel 1 – Básico

• Ejecutar Dependency-Check en cada sprint y evaluar impacto.

Nivel 2 – Intermedio

• Introducir pruebas controladas de librerías vulnerables y simular si se detectan.

• Automatizar alertas en el SIEM cuando se use una librería comprometida.

Nivel 3 – Avanzado

• Integrar SBOM con correlación de eventos en SIEM y plataformas CASB.

• Establecer un entorno de pruebas para detectar backdoors en código externo.

5. RESUMEN PRÁCTICO

• Cada componente, librería, servicio, o firmware puede introducir un riesgo en la cadena de suministro.

• El uso de SBOM + SCA es fundamental para identificar y remediar vulnerabilidades antes del despliegue.

• Red Team explota librerías y pipelines mal gestionados.

• Blue Team protege con controles de origen, aislamiento, firmas y actualizaciones.

• Purple Team prueba la detección, validación y refuerza la visibilidad continua.

🔐 Diseño de Seguridad – Cadena de Suministro de Software

1. Planificación y Diseño

Riesgos Clave:

• Inclusión de dependencias no auditadas desde la etapa inicial.

• Arquitecturas inseguras o con confianza implícita entre componentes.

• Ausencia de políticas sobre listas de materiales (SBOM) y análisis de seguridad.

Controles de Seguridad Recomendados:

• Realizar modelado de amenazas para identificar riesgos antes de escribir código.

• Revisar y validar la arquitectura en términos de segregación, autenticación y actualización.

• Definir desde el inicio el uso obligatorio de SAST, SCA y generación de SBOM.

Herramientas Sugeridas:

• OWASP Threat Dragon, Archimate, Microsoft SDL

2. Desarrollo de Software

Riesgos Clave:

• Uso de librerías de terceros vulnerables o sin mantenimiento.

• Inclusión accidental de claves, tokens o secretos en el código.

• Inserción de código malicioso en dependencias (supply chain poisoning).

Controles de Seguridad Recomendados:

• Análisis de Composición de Software (SCA) para detectar vulnerabilidades en librerías.

• Análisis estático de código (SAST) para detectar errores comunes de seguridad.

• Herramientas automáticas que detecten secretos embebidos en el código.

Herramientas Sugeridas:

• OWASP Dependency-Check, GitLeaks, SonarQube, Snyk

3. Integración y Pruebas

Riesgos Clave:

• Inyección de componentes maliciosos durante pruebas o integración.

• Ausencia de pruebas específicas de seguridad.

• Ambientes compartidos o sin aislamiento adecuados.

Controles de Seguridad Recomendados:

• Automatización de pruebas de seguridad en los pipelines de integración.

• Implementar sandboxing y firmar los artefactos generados.

• Validar el comportamiento del software ante entradas maliciosas.

Herramientas Sugeridas:

• Checkov, Grype, OPA / Gatekeeper, Unit Tests con seguridad

4. Construcción y Empaquetado

Riesgos Clave:

• Manipulación del entorno CI/CD por falta de controles.

• Ausencia de verificación de integridad en artefactos construidos.

• Falta de firma digital del código o binarios.

Controles de Seguridad Recomendados:

• Seguridad en CI/CD: usuarios mínimos necesarios, aislamiento de entornos, control de secretos.

• Validación de integridad mediante hashes o checksums.

• Firma digital de binarios y contenedores para garantizar autenticidad.

Herramientas Sugeridas:

• Jenkins Security Plugins, HashiCorp Vault, Sigstore, GitHub Actions Secure

5. Despliegue y Operación

Riesgos Clave:

• Entornos cloud mal segmentados o con accesos innecesarios.

• Configuración insegura de redes, IAM o recursos.

• Acceso abierto a APIs o servicios no autorizados.

Controles de Seguridad Recomendados:

• Revisión periódica de configuraciones IAM y políticas de acceso.

• Escaneo de infraestructura como código (IaC) antes del despliegue.

• Uso de plataformas de seguridad cloud (CSPM) para monitoreo continuo.

Herramientas Sugeridas:

• AWS CloudTrail, Azure Sentinel, Prowler, IAM Access Analyzer

6. Mantenimiento y Actualización

Riesgos Clave:

• Falta de parches o actualizaciones en librerías o firmware.

• Pérdida de visibilidad sobre las dependencias a lo largo del tiempo.

• Reutilización de código obsoleto con vulnerabilidades conocidas.

Controles de Seguridad Recomendados:

• Gestión proactiva de vulnerabilidades (Vulnerability Management).

• Regenerar y mantener actualizado el SBOM en cada versión o parche.

• Escaneo periódico de firmware, controladores y bibliotecas activas.

Herramientas Sugeridas:

• OWASP Dependency-Track, Syft + Grype, Patch Manager, SBOM Viewer

Lista técnica completa sobre Supply Chain Security

– Software Supply Chain – Cadena de suministro de software
Conjunto de procesos, herramientas y proveedores involucrados en el desarrollo, entrega y mantenimiento del software.

– Dependency – Dependencia
Módulo externo del cual una aplicación necesita apoyarse para funcionar correctamente.

– Third-party Component – Componente de terceros
Código o librería que no fue creada por el equipo de desarrollo principal y que se integra en el software.

– Trusted Source – Fuente confiable
Origen verificado desde donde se descargan o integran componentes o datos.

CI/CD – Canal de construcción / Integración continua – Build Pipeline
Secuencia automatizada para compilar, probar y preparar el despliegue del software.

CI/CD – Integración / Entrega continua – Continuous Integration / Delivery
Práctica DevOps para automatizar la entrega de software con alta frecuencia y seguridad.

SCA – Análisis de composición de software – Software Composition Analysis
Evaluación automática de librerías externas para detectar vulnerabilidades conocidas.

SAST – Análisis de seguridad estático de aplicaciones – Static Application Security Testing
Revisión del código fuente en busca de errores de seguridad sin ejecutar la aplicación.

DAST – Análisis de seguridad dinámico de aplicaciones – Dynamic Application Security Testing
Escaneo de la aplicación mientras está en ejecución para detectar vulnerabilidades en tiempo real.

SSDLC – Ciclo de vida seguro de desarrollo de software – Secure Software Development Lifecycle
Incorporación de seguridad en cada etapa del desarrollo del software desde el diseño hasta el mantenimiento.

BOM – Lista de materiales – Bill of Materials
Listado completo de componentes que forman parte de un sistema o producto (no solo software).

SBOM – Lista de materiales de software – Software Bill of Materials
Inventario detallado de todas las librerías, dependencias y subcomponentes usados en una aplicación.

OSS – Software de código abierto – Open Source Software
Software cuyo código es accesible, editable y redistribuible por la comunidad.

– Code Signing – Firma de código
Proceso criptográfico para asegurar que el código no ha sido alterado desde su firma.

– Hash Validation – Validación de hash
Comparación de hashes para comprobar la integridad de un archivo o ejecutable.

– Typosquatting – Suplantación por error tipográfico
Técnica donde un atacante sube un paquete malicioso con un nombre similar a uno legítimo.

– Backdoor – Puerta trasera
Acceso oculto e intencionado a un sistema que permite eludir los controles de seguridad.

– Code Injection – Inyección de código
Ataque en el que se introducen comandos maliciosos en entradas que no fueron sanitizadas.

– Malicious Package – Paquete malicioso
Componente de software diseñado intencionadamente para comprometer la seguridad del sistema donde se instala.

npm/pip/Maven – Gestor de paquetes – Package Manager
Herramienta que permite instalar, actualizar y administrar dependencias de software automáticamente.

– Repository – Repositorio
Ubicación donde se almacena y gestiona código fuente, artefactos o librerías.

– Artifact – Artefacto / Compilado – Artifact
Resultado final de un proceso de build, listo para ser desplegado o distribuido.

CycloneDX – Formato SBOM: CycloneDX – SBOM Format: CycloneDX
Especificación ligera para generar SBOMs, fácil de integrar en pipelines modernos.

SPDX – Formato SBOM: SPDX – SBOM Format: SPDX
Estándar abierto que estructura datos de componentes, licencias y seguridad para SBOMs.

– Supply Chain Attack – Ataque a la cadena de suministro
Compromiso de un eslabón (librería, proveedor, pipeline, etc.) para propagar malware o acceso no autorizado.

– CI/CD Pipeline Security – Seguridad del pipeline CI/CD
Aplicación de controles en el flujo de integración y entrega continua para evitar inyecciones o abusos.

– Privileged Escalation – Escalada de privilegios
Acción por la cual un atacante consigue más permisos de los que debería tener.

– Code Repository Poisoning – Envenenamiento del repositorio de código
Inyección maliciosa de código en repositorios abiertos o privados para comprometer proyectos que lo consuman.

– Secure Boot – Arranque seguro
Proceso que asegura que solo software firmado y confiable puede ejecutarse al iniciar el sistema.

– Firmware Validation – Validación de firmware
Verificación de la autenticidad e integridad del software embebido en hardware.

– Firmware Update – Actualización de firmware
Proceso de reemplazo del firmware existente por una versión corregida o mejorada.

TPM – Módulo de plataforma segura – Trusted Platform Module
Chip que guarda de forma segura claves, certificados y datos sensibles, y verifica integridad del sistema.

– Hardware Root of Trust – Raíz de confianza de hardware
Componente físico base desde el cual se garantiza la confianza del resto del sistema.

– Secure Enclave – Enclave seguro
Zona protegida del procesador que ejecuta datos críticos de forma aislada y cifrada.

CASB – Corredor de seguridad de acceso a la nube – Cloud Access Security Broker
Intermediario que supervisa, restringe y audita el acceso y uso de servicios en la nube por parte de usuarios y dispositivos.