Cadena de suministro: conoce lo que entregas

Una aplicación contiene más que el código de su equipo. Dependencias, herramientas, sistemas de compilación y distribución influyen en lo que se instala.

SBOM: Inventario que describe componentes de un producto de software.

El inventario responde una pregunta

Una SBOM describe componentes de un producto. Ayuda a investigar si un problema de dependencias afecta a una versión. Su utilidad depende de cobertura, versiones correctas y conexión con el artefacto real.

No demuestra seguridad total ni que toda vulnerabilidad listada sea alcanzable en esa aplicación. El inventario inicia una investigación; el contexto determina la respuesta.

Procedencia y firma responden cosas diferentes

La procedencia registra cómo se produjo un artefacto, por ejemplo su código y proceso de construcción. Una firma puede vincular una clave con bytes concretos si la verificación y la confianza en la clave son correctas.

Ninguna garantiza honestidad del firmante, código sin defectos o entorno protegido. Hace falta una política sobre identidades y condiciones de construcción aceptables.

Protege todo el recorrido

Revisa dependencias y limita permisos de construcción. No guardes credenciales de entrega en código ordinario. Restringe cambios de flujos y publicación. Fijar versiones mejora repetibilidad, pero requiere mantenimiento para no conservar problemas conocidos indefinidamente.

Define cómo localizar versiones afectadas, reconstruir desde código revisado, revocar credenciales comprometidas y comunicar correcciones. La trazabilidad facilita responder a incidentes.

Contrasta un paquete con una política escrita

Una aplicación comunitaria ficticia prepara el artefacto A42 desde la revisión de código S42. Son etiquetas cortas para los registros proporcionados. En un sistema real, los resúmenes criptográficos y la evidencia autenticada relacionan registros con bytes exactos. La plataforma de construcción aprobada es Maple; la política acepta la clave firmante K2 mediante una configuración de verificación gestionada por separado.

En este ejercicio, aceptar exige inventario y revisión de componentes correspondientes a A42, procedencia verificada que coincida con S42 y Maple, y firma válida de K2 sobre A42. La revisión de componentes debe resolver hallazgos aplicables o documentar una limitación aceptada expresamente. Noor responde por la entrega y por el seguimiento de futuras actualizaciones.

Birch-format es una biblioteca inventada. El registro de construcción indica que el candidato utiliza la versión 3.2. Ese cambio impide utilizar inventario y revisión anteriores como evidencia completa del candidato. No demuestra por sí solo que la versión 3.2 sea defectuosa. Distingue “sin cobertura” de “vulnerabilidad conocida”.

La firma no corrige la diferencia. Relaciona el candidato con la clave aceptada según las reglas de verificación, pero no convierte un inventario de otros bytes en inventario de esta entrega. Saber quién construyó el candidato tampoco establece que sus dependencias satisfagan la política de revisión.

PrediceSe propone renombrar I41 como “inventario A42” sin cambiar los registros de componentes. ¿Resolvería la carencia?

No. La etiqueta no demuestra que los componentes describan A42. Consigue un inventario relacionado con el candidato y revisa sus versiones reales. Reconstruir podría ser necesario si la construcción fuera incorrecta, pero estos hechos establecen una diferencia de evidencia, no ese defecto concreto.

Expresa la decisión y qué permitiría cambiarla

Aplaza aceptar bajo esta política. Dos requisitos tienen respaldo y dos no. Noor debe conseguir I42 y la revisión correspondiente. No hace falta descartar la procedencia y firma útiles si no cambian el artefacto ni los supuestos de verificación.

El paquete corregido aporta I42 con Birch-format 3.2 vinculado a A42 y una revisión de esos componentes sin hallazgos aplicables pendientes dentro de su cobertura. Los cuatro criterios quedan respaldados y puede justificarse aceptar frente a esta política. Eso no certifica todos los comportamientos de la aplicación ni anticipa avisos futuros.

Conserva juntos identidad del artefacto, cobertura, decisión y responsable. Un aviso nuevo puede exigir localizar entregas afectadas y revisar exposición aunque las versiones sigan fijadas. La repetibilidad ayuda a identificar qué se distribuyó; el mantenimiento determina qué hacer cuando cambia el conocimiento disponible. La persona que recibe el paquete debería poder distinguir cada conclusión sin depender de lo que alguien recuerde haber aprobado verbalmente.

EXPLORA EL CONCEPTO

¿Qué demuestra cada evidencia?

Una entrega ficticia incluye tres elementos.

Inventario de componentes

Ayuda a localizar dependencias. No certifica seguridad.

Firma verificada

Vincula bytes con una clave según tu política. Revisa quién la controla y qué aprobó.

Procedencia de un constructor aceptado

Respalda información del recorrido. La política decide si es suficiente.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Llévalo a una decisión

Pregunta por separado qué contiene, de dónde viene y por qué aceptas ese origen.