Dominio 8: Cadena de suministro de software segura
Dominio 8: Cadena de suministro de software segura
El Dominio 8 (Secure Software Supply Chain) pesa 10% del examen y es el dominio que ISC2 reforzó de forma más notable en el refresh de septiembre de 2023. La razón es directa: hoy una aplicación típica está compuesta en un 70-90% de código que la organización no escribió — dependencias open source, librerías comerciales, contenedores base, modelos de IA, servicios de terceros. El riesgo ya no vive solo en tu código; vive en todo lo que confías e incorporas.
La mentalidad del dominio: cada componente externo es una relación de confianza que debe justificarse, verificarse y gobernarse durante todo el ciclo de vida, no solo en el momento de incorporarlo.
flowchart LR
A[Desarrolladores/proveedores] -->|código fuente| B[Repositorio / VCS]
B --> C[Build / CI-CD]
D[Dependencias open source] --> C
E[Registries: npm, PyPI, Maven] --> D
C --> F[Artefacto firmado]
F --> G[Registro de artefactos]
G --> H[Despliegue]
style D fill:#f88
style E fill:#f88
style C fill:#fb8
style B fill:#fb8Los nodos resaltados marcan los puntos de riesgo clásicos: dependencias comprometidas, registries envenenados, y el pipeline de build como blanco (SolarWinds).
8.1 Gestión de riesgos de la cadena de suministro (SCRM)
SCRM (Supply Chain Risk Management) es el proceso de identificar, evaluar y mitigar los riesgos introducidos por proveedores y componentes de terceros a lo largo de todo el ciclo de vida del software.
Fuentes de riesgo de terceros (third-party risk)
- Riesgo de componente: la dependencia contiene una vulnerabilidad (conocida o de día cero).
- Riesgo de proveedor: el proveedor tiene malas prácticas de seguridad, es insolvente, o es comprometido y se usa como vector (ataque a la cadena).
- Riesgo de integridad: el componente fue manipulado entre su origen y tu build (typosquatting, artefacto envenenado).
- Riesgo de mantenimiento / abandono: la dependencia deja de recibir soporte (EOL) o queda en manos de un único mantenedor sin sucesión (el caso xz-utils).
- Riesgo transitivo: no solo tus dependencias directas, sino las dependencias de tus dependencias (a menudo docenas de niveles), que rara vez revisas.
El principio central
El SCRM aplica la gestión de riesgo estándar (identificar → evaluar → tratar → monitorear) al universo de terceros, y su punto conceptual es que la confianza debe ser explícita y verificable, no implícita. “Lo bajé de npm y funciona” no es una evaluación de riesgo.
💡 Tip de examen: El SCRM no es un evento de compra; es un proceso continuo que abarca selección, incorporación, operación y retiro del componente. Si una pregunta trata la evaluación de un proveedor como algo que se hace “una vez al firmar el contrato”, es distractor: el riesgo del tercero debe monitorearse durante toda la relación.
8.2 Analizar el perfil de seguridad de software de terceros
Antes de confiar en un componente o proveedor, se evalúa su postura de seguridad. ISC2 espera que sepas qué instrumentos existen y qué evidencia aporta cada uno.
Instrumentos de evaluación
| Instrumento | Qué es | Qué evidencia aporta |
|---|---|---|
| Cuestionario SIG | Standardized Information Gathering (Shared Assessments) | Autoevaluación estructurada del proveedor sobre sus controles |
| CAIQ | Consensus Assessments Initiative Questionnaire (Cloud Security Alliance) | Autoevaluación específica para proveedores cloud |
| SOC 2 Type II | Reporte de auditoría independiente (AICPA) | Evidencia de terceros de controles operando en el tiempo. Más fuerte que una autoevaluación |
| ISO/IEC 27001 | Certificación de sistema de gestión de seguridad (ISMS) | Certificación acreditada de que existe un programa de seguridad gestionado |
| Pruebas independientes | Pentest / auditoría de código por un tercero | Evidencia técnica directa del estado de seguridad del producto |
Jerarquía de confianza de la evidencia
No toda evidencia vale igual. De menor a mayor confianza:
- Autoevaluación (SIG/CAIQ rellenado por el propio proveedor) — útil pero es “confía en mi palabra”.
- Certificación acreditada (ISO 27001) — un tercero verificó que existe un sistema de gestión.
- Atestación de auditoría (SOC 2 Type II) — un auditor independiente verificó controles operando durante un periodo.
- Prueba técnica independiente (pentest reciente sobre el producto real) — evidencia directa.
💡 Tip de examen: Prefiere evidencia independiente sobre autoevaluación. Entre un cuestionario SIG que el proveedor rellenó y un SOC 2 Type II de un auditor externo, el SOC 2 es más fuerte porque es atestación independiente de controles operando en el tiempo (Type II) frente a un punto único (Type I) o una autodeclaración. ISC2 valora la verificación por un tercero acreditado.
8.3 Verificar pedigree y provenance
Dos términos que el examen distingue con precisión y que suelen confundirse:
| Término | Definición | Pregunta que responde |
|---|---|---|
| Pedigree | El origen y la cadena de custodia/linaje de un componente: de dónde vino, qué componía originalmente, su historia | ”¿De dónde proviene y por qué manos pasó este componente?” |
| Provenance | El registro verificable de cómo se produjo un artefacto: qué fuente, qué build, qué proceso lo generó | ”¿Este artefacto fue construido a partir de esta fuente exacta por este proceso confiable?” |
En términos simples: pedigree es la genealogía/procedencia del componente; provenance es la prueba criptográfica de cómo y desde qué fuente se construyó el artefacto que tienes en la mano.
Mecanismos para garantizar integridad y provenance
- Firmas digitales de artefactos: garantizan integridad y autenticidad (el artefacto no cambió y viene de quien dice).
- Attestations: declaraciones firmadas y verificables sobre cómo se produjo un artefacto (qué build, qué materiales, qué controles).
- SLSA (Supply-chain Levels for Software Artifacts, “salsa”): framework de OpenSSF con niveles graduales de garantía de integridad de la build. Cada nivel exige más rigor:
| Nivel SLSA | Garantía principal |
|---|---|
| Nivel 1 | Provenance existe y está documentada (proceso de build genera metadatos) |
| Nivel 2 | Build en servicio hospedado con provenance firmada por el servicio |
| Nivel 3 | Build endurecida y resistente a manipulación (aislamiento, provenance no falsificable) |
- in-toto: framework que asegura la integridad de toda la cadena de pasos de la build; cada paso (checkout, test, compile, package) genera metadatos firmados que se verifican en conjunto, de modo que nadie insertó un paso no autorizado.
- Sigstore: infraestructura open source para firmar artefactos sin gestionar llaves de larga vida (firma con identidad OIDC efímera, registro público transparente en Rekor, firma con Cosign para contenedores).
💡 Tip de examen: Memoriza el par: pedigree = de dónde vino (linaje/origen); provenance = cómo y desde qué fuente se construyó (evidencia verificable de la build). SLSA es el framework de niveles que formaliza garantías de provenance; in-toto protege la cadena completa de pasos; Sigstore/Cosign firma sin gestionar llaves. Si preguntan “¿cómo pruebo que este binario fue construido desde este código fuente por un proceso confiable?”, la respuesta es provenance/attestations (SLSA).
8.4 Asegurar y verificar requisitos de seguridad de proveedores
Los requisitos de seguridad no nacen en el D8: fluyen desde el Dominio 3 (requisitos). Lo que el D8 hace es imponerlos y verificarlos en la relación con el proveedor.
- Flujo desde el D3: los requisitos de seguridad de la organización (clasificación de datos, cumplimiento, controles) se traducen en requisitos contractuales exigibles al proveedor. El proveedor debe cumplir el mismo estándar que se exigiría internamente para datos equivalentes.
- Derecho a auditar (right to audit): cláusula que reserva a la organización la facultad de auditar (o exigir evidencia de auditoría) los controles del proveedor. Sin este derecho, la verificación depende de la buena voluntad del proveedor.
- Gestión durante el contrato: la verificación es continua, no un chequeo único. Se revisan periódicamente reportes SOC 2 renovados, resultados de escaneos, notificaciones de incidentes y cambios de subprocesadores.
- Cuarta parte (fourth-party risk): los proveedores de tus proveedores. La cadena de confianza se extiende más allá del contrato directo.
💡 Tip de examen: Los requisitos de seguridad del proveedor derivan de los requisitos del negocio (D3) y se hacen exigibles vía contrato. El derecho a auditar es la palanca que convierte una exigencia escrita en algo verificable. Si una pregunta plantea que “el proveedor dice cumplir pero no hay forma de comprobarlo”, la falla de origen es que faltó el right to audit o la exigencia de evidencia independiente en el contrato.
8.5 Apoyar requisitos contractuales
El contrato es el instrumento donde el riesgo de la cadena de suministro se transfiere, distribuye y hace exigible. ISC2 espera que conozcas las cláusulas de seguridad típicas.
| Cláusula contractual | Qué establece |
|---|---|
| Requisitos de seguridad | Controles mínimos que el proveedor debe implementar y mantener |
| SLAs de seguridad | Compromisos medibles (tiempo de parcheo, tiempo de notificación de brecha) |
| Responsabilidad por vulnerabilidades | Quién responde y remedia cuando aparece una vuln en el componente del proveedor |
| Notificación de brechas | Obligación de notificar incidentes en un plazo definido (a menudo regulatorio) |
| Software escrow | Depósito del código fuente con un tercero neutral, liberado si el proveedor quiebra, es adquirido o incumple. Protege continuidad |
| EOL / EOS | End-of-Life / End-of-Support: cuándo el proveedor dejará de dar soporte/parches, para planificar migración |
| Derecho a auditar | (Ver 8.4) facultad de verificar el cumplimiento |
Software escrow y EOL/EOS
- Software escrow mitiga el riesgo de dependencia de un proveedor: si desaparece, la organización obtiene el código fuente depositado y puede mantener el sistema. Es una salvaguarda de continuidad, no de confidencialidad.
- EOL/EOS es crítico para la gestión de riesgo porque un componente sin soporte ya no recibe parches de seguridad, convirtiéndose en deuda de riesgo creciente. Debe planificarse la migración antes de la fecha de fin de soporte.
💡 Tip de examen: Software escrow protege la continuidad del negocio ante la desaparición del proveedor (te da acceso al código fuente), no la confidencialidad ni la calidad. Y EOL/EOS debe planificarse con antelación: usar un componente después de su End-of-Support significa correr sin parches de seguridad, un riesgo que ISC2 considera inaceptable sin una mitigación compensatoria.
SBOM: Software Bill of Materials en profundidad
El SBOM es un inventario formal y legible por máquina de todos los componentes de una pieza de software, incluidas dependencias transitivas, versiones y licencias. Es la analogía de la “lista de ingredientes” de un alimento: no puedes gestionar el riesgo de lo que no sabes que tienes.
El impulso regulatorio vino de la Executive Order 14028 (EE.UU., 2021), que exige SBOM a los proveedores del gobierno federal tras SolarWinds.
Formatos estándar
| Formato | Origen | Enfoque |
|---|---|---|
| SPDX | Linux Foundation (ISO/IEC 5962) | Estándar amplio, fuerte en licencias y cumplimiento; formato ISO |
| CycloneDX | OWASP | Orientado a seguridad; soporta VEX, SaaSBOM, y extensiones ML/AI BOM |
Casos de uso del SBOM
- Respuesta rápida a nuevas vulnerabilidades: cuando aparece un Log4Shell, con SBOM puedes responder en minutos “¿estoy afectado y dónde?” en vez de auditar manualmente durante días.
- Cumplimiento de licencias: identificar licencias incompatibles o restrictivas.
- Debida diligencia en adquisiciones y contratos.
- Detección de componentes EOL o sin mantenimiento.
VEX (Vulnerability Exploitability eXchange)
El SBOM te dice qué componentes tienes; VEX complementa diciendo si una vulnerabilidad conocida en un componente es realmente explotable en tu contexto. Un componente puede contener un CVE pero la función vulnerable nunca se invoca — VEX comunica ese estado (“not affected”, “affected”, “fixed”, “under investigation”), reduciendo el ruido y evitando remediaciones innecesarias.
💡 Tip de examen: El SBOM responde “¿qué tengo?”; el VEX responde “¿me afecta realmente?”. Son complementarios. El caso de uso estrella del SBOM en el examen es la respuesta rápida ante una nueva vulnerabilidad divulgada (tipo Log4Shell): sin inventario no puedes saber tu exposición. SPDX = fuerte en licencias (ISO); CycloneDX = fuerte en seguridad (OWASP, soporta VEX y ML-BOM).
Ataques históricos como lecciones
ISC2 usa incidentes reales para anclar los conceptos. No memorices trivia; entiende qué punto de la cadena falló en cada uno.
| Ataque | Qué pasó | Lección de cadena de suministro |
|---|---|---|
| SolarWinds (2020) | Atacantes comprometieron el pipeline de build de Orion e inyectaron backdoor en actualizaciones firmadas y legítimas | El build system es un blanco; la firma no ayuda si el proceso de build está comprometido. Motivó SLSA y provenance de build |
| Log4Shell (2021) | Vulnerabilidad crítica (RCE) en Log4j, una dependencia ubicua y transitiva | Necesidad de SBOM para conocer la exposición; el riesgo de dependencias transitivas invisibles |
| xz-utils (2024) | Un mantenedor malicioso ganó confianza durante años e insertó un backdoor en una librería de compresión de Linux | Riesgo del mantenedor único y de la ingeniería social contra proyectos open source; salud del proyecto importa |
| Typosquatting / dependency confusion | Paquetes maliciosos con nombres parecidos a los legítimos, o paquetes internos suplantados por versiones públicas de mayor versión en registries | Riesgo del registry; necesidad de verificar nombres, fijar fuentes y usar scopes privados |
Puntos que estos ataques enseñan
- SolarWinds: la firma digital garantiza que el artefacto no cambió después del build, pero no protege si el compromiso ocurre dentro del build. De ahí la importancia de provenance verificable (SLSA nivel 3), builds aisladas e in-toto.
- Log4Shell: no fue un ataque a la cadena en sentido estricto (fue una vuln), pero enseñó que no puedes responder a lo que no sabes que usas → SBOM.
- xz-utils: la confianza en open source no puede ser ciega; hay que evaluar la salud del proyecto (número de mantenedores, actividad, respuesta a vulnerabilidades).
- Dependency confusion: configurar correctamente los registries privados y verificar la procedencia de los paquetes.
💡 Tip de examen: El mensaje de SolarWinds para el examen es que firmar el artefacto no basta si el pipeline de build está comprometido — por eso importan la integridad del build y la provenance (SLSA/in-toto). El de Log4Shell es que sin SBOM no conoces tu exposición. No los confundas: SolarWinds = compromiso del build; Log4Shell = dependencia vulnerable; xz-utils = mantenedor malicioso/ingeniería social.
Frameworks regulatorios y de referencia
NIST SSDF (SP 800-218)
El Secure Software Development Framework es un conjunto de prácticas de desarrollo seguro agrupadas en cuatro categorías, que se ha vuelto la referencia para el cumplimiento derivado de la EO 14028:
- PO — Prepare the Organization: gente, procesos y tecnología listos para desarrollar seguro.
- PS — Protect the Software: proteger el software y sus artefactos de manipulación (integridad, provenance).
- PW — Produce Well-Secured Software: producir software con mínimas vulnerabilidades.
- RV — Respond to Vulnerabilities: identificar y remediar vulnerabilidades de forma continua.
El SSDF es agnóstico de metodología (funciona con cualquier SDLC) y es la base contra la que los proveedores del gobierno de EE.UU. atestan cumplimiento.
EO 14028
La Executive Order 14028 (“Improving the Nation’s Cybersecurity”, 2021), respuesta directa a SolarWinds, impuso requisitos como SBOM obligatorio, prácticas de desarrollo seguro (via SSDF) y atestaciones a los proveedores del gobierno federal. Es el motor regulatorio detrás del auge de SBOM y provenance.
Salud de proyectos open source: OpenSSF Scorecard
Para evaluar el riesgo de una dependencia open source, no basta con “es popular”. El OpenSSF Scorecard automatiza una evaluación de la salud y prácticas de seguridad de un proyecto, puntuando señales como:
- ¿Tiene revisión de código obligatoria (branch protection)?
- ¿Usa dependencias fijadas (pinned) y firma sus releases?
- ¿Corre análisis estático (SAST) y escaneo de dependencias en CI?
- ¿Responde a vulnerabilidades y tiene política de seguridad?
- ¿Hay actividad reciente y varios mantenedores (no un solo punto de fallo como xz-utils)?
Estas señales permiten decidir con datos si adoptar, monitorear o evitar una dependencia.
💡 Tip de examen: Al evaluar una dependencia open source, ISC2 quiere evaluación de salud del proyecto basada en señales objetivas (mantenimiento activo, múltiples mantenedores, respuesta a vulnerabilidades, prácticas de build seguras) — no la popularidad ni el número de estrellas. OpenSSF Scorecard es la herramienta que automatiza esa evaluación. El caso xz-utils es el ejemplo canónico de por qué el mantenedor único es una señal de riesgo.
Gestión práctica de dependencias
Más allá de la teoría de riesgo, el examen espera que reconozcas los controles operativos concretos para gestionar dependencias con seguridad.
| Control | Qué hace | Riesgo que mitiga |
|---|---|---|
| Lockfiles (package-lock, poetry.lock) | Fijan versiones y hashes exactos de todas las dependencias, incluidas transitivas | Instalaciones no reproducibles; sustitución silenciosa de versiones |
| Pinning por hash | Depender de un hash de contenido, no solo de un número de versión | Que un atacante republique una versión con el mismo número pero contenido distinto |
| Registries privados / proxy | Espejo interno controlado (Artifactory, Nexus) entre el registry público y el build | Dependency confusion, indisponibilidad del registry público, paquetes no aprobados |
| Allowlists de dependencias | Solo se permiten componentes previamente aprobados | Introducción de librerías no evaluadas |
| SCA en CI/CD | Software Composition Analysis: escanea dependencias contra bases de vulns y licencias | Uso de componentes con CVE conocidos o licencias incompatibles |
| Actualización controlada | Renovate/Dependabot con revisión, no auto-merge ciego | Quedarse en versiones EOL; pero también actualizar a versiones comprometidas |
La tensión de las actualizaciones
Actualizar es un arma de doble filo que el examen adora plantear: no actualizar deja vulnerabilidades sin parchear (deuda de riesgo), pero actualizar ciegamente puede introducir una versión comprometida (como en varios ataques a npm) o romper compatibilidad. La respuesta correcta casi siempre es un proceso controlado: actualizaciones evaluadas, probadas y aprobadas — ni parálisis ni auto-merge sin revisión.
💡 Tip de examen: Los lockfiles con hashes garantizan builds reproducibles y detectan sustitución de contenido; un registry proxy privado es la defensa canónica contra dependency confusion. Ante “¿cómo aseguras que el componente que descargas es exactamente el que evaluaste?”, la respuesta combina pinning por hash + registry controlado, no confiar en el número de versión.
SCA vs. otras técnicas de análisis
El Software Composition Analysis (SCA) es la herramienta central del D8 en la práctica, y conviene ubicarlo frente a las técnicas del D5/D6 para no confundirlas en el examen.
| Técnica | Qué analiza | Dominio principal |
|---|---|---|
| SCA | Dependencias de terceros (componentes, versiones, licencias, CVEs) | D8 / D5 |
| SAST | Tu código fuente en busca de vulnerabilidades | D5 / D6 |
| DAST | La aplicación en ejecución desde fuera | D6 |
| Secret scanning | Secretos filtrados en el código | D5 |
El SCA es lo que consume y produce SBOMs: identifica qué componentes tienes (genera el inventario) y los correlaciona con bases de vulnerabilidades (CVE/NVD) y licencias. Es la implementación práctica del “conoce tu cadena de suministro”.
Escenario integrado: respuesta a una nueva vulnerabilidad crítica
Cuando se divulga una vulnerabilidad crítica en una dependencia ubicua (el patrón Log4Shell), el valor de haber preparado la cadena de suministro se vuelve tangible:
sequenceDiagram
participant CVE as Divulgación de CVE crítico
participant SBOM as Inventario SBOM
participant VEX
participant Team as Equipo de seguridad
participant Ops as Operaciones
CVE->>SBOM: ¿Uso este componente y dónde?
SBOM->>Team: Lista de sistemas afectados en minutos
Team->>VEX: ¿La función vulnerable se invoca realmente?
VEX->>Team: 3 sistemas "affected", 5 "not affected"
Team->>Ops: Prioriza remediación de los 3 realmente explotables
Ops->>Ops: Actualiza componente / virtual patching temporal
Ops->>SBOM: Actualiza inventario con la nueva versiónSin SBOM, el paso “¿dónde lo uso?” toma días de auditoría manual. Sin VEX, se remedian sistemas que no estaban realmente expuestos, malgastando esfuerzo. Juntos convierten una emergencia caótica en una respuesta priorizada por riesgo.
💡 Tip de examen: El escenario “acaba de salir un CVE crítico en una librería muy usada, ¿qué te permite responder rápido?” tiene como respuesta el SBOM (saber dónde lo usas) complementado con VEX (saber si realmente te afecta). Es el argumento de valor número uno del SBOM en el examen.
Puntos clave
- El Dominio 8 (10%) es el más reforzado del refresh 2023: la mayor parte del software moderno es código de terceros, y el riesgo vive en todo lo que confías e incorporas.
- SCRM es gestión de riesgo continua sobre proveedores y componentes, incluyendo dependencias transitivas y el riesgo de cuarta parte. La confianza debe ser explícita y verificable.
- Al evaluar terceros, prefiere evidencia independiente (SOC 2 Type II, pentest) sobre autoevaluaciones (SIG, CAIQ); ISO 27001 certifica que existe un programa de gestión.
- Pedigree = origen/linaje del componente; provenance = prueba verificable de cómo y desde qué fuente se construyó. SLSA formaliza niveles de garantía de build; in-toto protege la cadena de pasos; Sigstore/Cosign firma sin llaves de larga vida.
- Los requisitos de seguridad del proveedor fluyen del D3 y se hacen exigibles por contrato; el derecho a auditar los vuelve verificables. Software escrow protege continuidad; EOL/EOS obliga a planear migración antes de perder soporte.
- El SBOM (SPDX = licencias/ISO; CycloneDX = seguridad/OWASP) responde “¿qué tengo?” y su caso estrella es la respuesta rápida a nuevas vulnerabilidades (Log4Shell). VEX añade “¿me afecta realmente?”.
- Lecciones de ataques: SolarWinds = el build system es un blanco y firmar no basta; Log4Shell = sin SBOM no conoces tu exposición; xz-utils = riesgo del mantenedor único y la ingeniería social; dependency confusion = riesgo del registry.
- NIST SSDF (PO/PS/PW/RV) y la EO 14028 son el contexto regulatorio que impulsó SBOM, provenance y atestaciones de desarrollo seguro.
- Para dependencias open source, evalúa la salud del proyecto con señales objetivas (OpenSSF Scorecard), no la popularidad.