Recursos · 16
Aseguramiento de la cadena de suministro de software: componentes a liberar
Conecte componentes, procedencia, compilaciones, vulnerabilidades y actualizaciones a cada versión realmente implementada.
Actualizado · 3 min
Lo que esta guía ayuda a lograr
- Conoce las dependencias realmente enviadas
- Verificar origen de artefacto
- Priorizar fallas en contexto
- Reemplazo y reversión de pruebas
Comprobación rápida
- ¿La lista de materiales coincide con la versión implementada?
- ¿Se incluyen dependencias transitivas?
- ¿Quién puede firmar una autorización?
- ¿Hay alguna vulnerabilidad alcanzable en su uso?
- ¿Se puede eliminar un componente crítico sin improvisación?
Método paso a paso
- 1
Lanzamientos de mapas enviados
Identificar repositorios, dependencias directas y transitivas, construir herramientas, imágenes, servicios externos y propietarios. Conéctelos todos a una versión verificable.
Entregable: producto, componente, versión y mapa de propietarios.
- 2
Producir una lista de materiales utilizable
Generar un SBOM para cada lanzamiento y compararlo con los artefactos realmente enviados. Resuelva nombres inexactos, versiones faltantes y componentes internos.
Entregable: SBOM fechado y validado.
- 3
Proteger la compilación
Limitar los derechos de publicación, aislar etapas sensibles y conservar procedencia, resúmenes y firmas. Verifique esta evidencia antes del despliegue.
Entregable: registro de compilación y política de verificación.
- 4
Alertas de triaje
Conecta cada aviso de vulnerabilidad con el componente, versión, exposición y uso real. Asigne un propietario, fecha límite, decisión y evidencia de cierre.
Entregable: cola de triaje contextual.
- 5
Ensayar cambio
Reemplazar un componente crítico en un entorno de prueba, verificar los recorridos de negocios y ensayar la reversión. Mida las dependencias que bloquean el cambio.
Entregable: informe de ejercicio de reemplazo y respaldo.
- 6
Mantener evidencia
Revisar componentes y proveedores en lanzamientos importantes y después de incidentes. Conservar los registros durante un período que respalde la investigación y corrección.
Entregable: revisar calendario e historial de lanzamientos.
Indicadores de gestión
| Indicador | Qué mide | Primera acción |
|---|---|---|
| Cobertura SBOM | Lanzamientos enviados con inventario de componentes comprobados | Resolver discrepancias antes de la publicación |
| Procedencia verificada | Artefactos comprobados antes del despliegue | A las liberaciones de bloque les falta la evidencia esperada |
| Tiempo de triaje | Tiempo desde la notificación relevante hasta la decisión documentada | Escalar componentes expuestos |
| Reversibilidad | Reemplazos críticos probados con rollback | Eliminar dependencias de bloqueo |
Errores comunes
- Inventario de repositorio confuso con componentes implementados
- Mantener un SBOM sin actualizarlo
- Ranking de un defecto sólo por puntuación
- Firmar un artefacto sin verificar la procedencia de la compilación
Preguntas frecuentes
¿Es suficiente un SBOM?
No. Ayuda a identificar componentes, pero también es necesario verificar la procedencia, integridad, exposición y capacidad de actualización.
¿Debería liberarse cada bloque de vulnerabilidad?
Decidir a partir del uso real, exposición, controles compensadores y criticidad del negocio, y registrar el razonamiento.
¿Qué marco de referencia ayuda?
El marco de desarrollo de software seguro del NIST ofrece prácticas seguras de desarrollo y protección de software durante todo el ciclo de vida.
Referencias oficiales
Las referencias respaldan el método. Adapte los controles a su contexto; no constituyen certificación. Los títulos de referencia originales y los documentos fuente pueden estar en otro idioma.
