Receber por email
← Voltar para o catálogo

sbom-generate

Usar para generar Software Bill of Materials para cumplimiento del CRA. También: Software Bill of Materials, inventario de componentes, CycloneDX, SPDX, cadena de suministro.

57estrelas
Atualizado há 4 meses

Ver no GitHub ↗

Como adicionar

/plugin marketplace add 686f6c61/alfred-dev

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/sbom-generate/svg)](https://www.skillteca.com.br/skills/sbom-generate)

Alerta por categoria

Receba novas skills de Design e Frontend toda segunda

1 email curto, só com as skills novas de Design e Frontend. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Generar SBOM (Software Bill of Materials)

Resumen

Este skill genera un inventario completo de todos los componentes de software incluidos en el proyecto, tanto dependencias directas como transitivas. El SBOM es un requisito del Cyber Resilience Act (CRA) europeo y una práctica recomendada de seguridad de la cadena de suministro.

El SBOM permite responder rápidamente a preguntas como "usamos la versión afectada por esta vulnerabilidad?" sin necesidad de investigar manualmente cada proyecto.

Proceso

  1. Detectar el ecosistema y las fuentes de dependencias. Identificar todos los ficheros de lock o manifiesto del proyecto:
  • Node.js: package-lock.json, yarn.lock, pnpm-lock.yaml.
  • Python: requirements.txt, Pipfile.lock, poetry.lock.
  • Rust: Cargo.lock.
  • Go: go.sum.
  • Java: pom.xml, build.gradle.
  • PHP: composer.lock.
  1. Listar dependencias directas. Para cada dependencia directa, registrar:
  • Nombre del paquete.
  • Versión exacta instalada.
  • Licencia.
  • Proveedor o autor.
  • URL del repositorio.
  • Hash de verificación (si está disponible en el lock file).
  1. Listar dependencias transitivas. Repetir el mismo proceso para todas las dependencias de las dependencias. Las transitivas suelen ser la mayoría y las más difíciles de rastrear.
  1. Incluir componentes no gestionados por paquetes. Algunos componentes se incluyen de forma manual:
  • Librerías copiadas directamente (vendoring).
  • Scripts de terceros incluidos vía CDN.
  • Binarios precompilados.
  • Componentes del sistema operativo base (especialmente relevante en contenedores Docker).
  1. Generar en formato estándar. Usar uno de los dos formatos aceptados por la industria:
  • CycloneDX: formato JSON o XML, preferido por OWASP. Más ligero y centrado en seguridad.
  • SPDX: formato estándar ISO (ISO/IEC 5962:2021). Más completo en información de licencias.

Si existen herramientas automáticas para el ecosistema (como cyclonedx-npm, syft, cdxgen), usarlas. Si no, generar manualmente con la plantilla templates/sbom.md.

  1. Verificar completitud. Cruzar el SBOM generado con el lock file para asegurar que no falta ninguna dependencia. Verificar que todas las licencias están identificadas (ninguna como "desconocida").
  1. Firmar o versionar el SBOM. Asociar el SBOM a una versión concreta del software (tag de Git, versión del paquete). El SBOM debe regenerarse con cada release.

Criterios de éxito

  • El SBOM incluye todas las dependencias directas y transitivas.
  • Cada componente tiene: nombre, versión, licencia, proveedor y hash.
  • El formato es compatible con CycloneDX o SPDX.
  • No hay licencias marcadas como "desconocida" sin justificación.
  • El SBOM está asociado a una versión concreta del software.
  • Se ha verificado la completitud contra el lock file del proyecto.
Compartilhar X LinkedIn