En este capítulo
Seguridad de producto
Un producto digital puede incluir hardware, software, servicios de actualización y componentes de terceros. Su seguridad debe considerarse desde diseño y configuración inicial hasta soporte y fin de vida. Secure by design significa anticipar riesgos antes del lanzamiento; secure by default reduce exposiciones en las opciones iniciales. El fabricante necesita conocer qué funcionalidades pueden ser atacadas y qué dependencias afectan al producto. La diferencia jurídica entre producto y servicio puede modificar obligaciones, por lo que conviene estudiar el supuesto concreto. Un dispositivo conectado sigue necesitando mantenimiento después de su venta, especialmente cuando aparecen vulnerabilidades nuevas.
Conceptos de este apartado
- Producto vs servicio
- Secure by design y secure by default
- Ciclo de vida de soporte
- Superficie de ataque del producto
- Responsabilidad del fabricante
- Coordinación entre ingeniería, seguridad y legal
Dependencias y composición de software
Las aplicaciones dependen de bibliotecas y paquetes, incluidos componentes incorporados indirectamente por otras dependencias. Una vulnerabilidad en una biblioteca puede afectar múltiples productos a la vez. El análisis de composición de software o SCA ayuda a identificar versiones y problemas conocidos, pero depende de un inventario razonablemente correcto. Ataques como typosquatting aprovechan nombres engañosamente parecidos, mientras que dependency confusion explota configuraciones de resolución de paquetes. La respuesta requiere proteger repositorios, revisar fuentes y definir políticas de componentes permitidos. No todo componente desactualizado supone el mismo riesgo: deben valorarse exposición y utilización real.
Conceptos de este apartado
- Librerías y paquetes
- Dependencias transitivas
- SCA
- Repositorios y registries
- Typosquatting y dependency confusion
- Política de componentes permitidos
SBOM y trazabilidad
Una lista de materiales de software o SBOM identifica componentes y versiones presentes en un producto. Formatos como SPDX y CycloneDX facilitan su representación e intercambio. La SBOM no garantiza que el software sea seguro, pero ayuda a localizar qué productos utilizan una biblioteca vulnerable. También puede apoyar compras, investigación de incidentes y cumplimiento de licencias. Su utilidad depende de actualidad, precisión y relación con versiones distribuidas. Si un proveedor entrega una SBOM del producto anterior, el documento puede ser formalmente correcto y operativamente inútil. Mantener trazabilidad de componentes es una tarea continua.
Conceptos de este apartado
- Concepto y objetivos de SBOM
- SPDX y CycloneDX: conceptos
- Inventario de componentes
- Asociación con vulnerabilidades
- Versiones y actualizaciones
- Uso de SBOM en incidentes y due diligence
Seguridad del proceso de build
El proceso de construcción o build transforma código y dependencias en artefactos distribuibles. Un repositorio legítimo puede producir software alterado si el sistema de compilación fue comprometido. Las firmas y la información sobre procedencia o provenance permiten verificar ciertos pasos de elaboración y distribución. SLSA ofrece una referencia para mejorar integridad de la cadena de suministro, aunque los niveles y controles deben interpretarse con precisión. Las construcciones reproducibles facilitan comparar resultados cuando el entorno lo permite. Proteger credenciales y sistemas CI/CD es parte esencial de la seguridad del producto, porque un fallo allí puede afectar a todos los clientes.
Conceptos de este apartado
- Build reproducible
- Integridad de artefactos
- Firma y provenance
- Protección de repositorios
- Compromiso de pipeline
- Principios de SLSA y cadena de confianza
Vulnerability disclosure y mantenimiento
La divulgación coordinada de vulnerabilidades establece canales para recibir informes, evaluar su gravedad y desarrollar correcciones. Un equipo de respuesta de producto o PSIRT puede coordinar ingeniería, seguridad y comunicación. Es importante distinguir descubrimiento, confirmación, exposición real, solución disponible y notificación. Publicar detalles técnicos antes de que exista una mitigación puede aumentar riesgos, pero retrasar indefinidamente información también puede perjudicar a usuarios. Las obligaciones legales y contractuales deben comprobarse según producto y jurisdicción. La gestión responsable conserva evidencia de decisiones, versiones afectadas y plazos de remediación.
Conceptos de este apartado
- Canales de reporte
- CVD y responsible disclosure
- PSIRT
- Priorización y parches
- Coordinación con investigadores
- Fin de soporte y comunicación a usuarios
Regulación y assurance de producto
El Cyber Resilience Act europeo introduce requisitos de seguridad para determinados productos con elementos digitales. Su aplicación depende de definiciones, categorías, roles económicos y fechas específicas. Las obligaciones pueden abarcar documentación técnica, evaluación de conformidad y tratamiento de vulnerabilidades durante el ciclo de vida. Para cumplir no basta con colocar un distintivo de seguridad en la caja: deben existir procesos, controles y evidencias acordes con la norma. El análisis debe distinguir obligaciones de fabricante, importador o distribuidor según el caso. La seguridad de producto une arquitectura, mantenimiento, contratación y responsabilidad en una misma cadena.
Conceptos de este apartado
- Obligaciones del CRA
- Documentación técnica
- Evaluación de conformidad
- Vulnerabilidades explotadas
- Actualizaciones de seguridad
- Evidencias de cumplimiento durante el ciclo de vida
Un caso para comprenderlo
Un fabricante descubre una vulnerabilidad en una biblioteca incorporada a varias versiones de su producto. Una SBOM actualizada permite localizar productos afectados; la gestión de divulgación coordina corrección y comunicación; el análisis jurídico identifica obligaciones aplicables. La seguridad depende del ciclo de vida, no solo de las pruebas realizadas antes de vender.
Cómo aplicar estos conceptos
El punto de partida es describir el sistema o situación con precisión, distinguir hechos de suposiciones y seleccionar qué información permitiría comprobar una conclusión. A partir de ahí se identifican riesgos, controles, responsabilidades y evidencias posibles. La utilidad de estos conocimientos aumenta cuando se relacionan con otras áreas de la ciberseguridad y del Derecho informático.
Fuentes y lecturas de referencia
Para aplicar estos marcos a un caso concreto deben comprobarse la versión vigente, el ámbito de aplicación y las condiciones del supuesto.