sbom-generate
$
npx mdskill add 686f6c61/alfred-dev/sbom-generateGenerate SBOMs for CRA compliance and supply chain security.
- Automatically inventories software components across multiple ecosystems.
- Integrates with lock files from Node.js, Python, Rust, Go, Java, and PHP.
- Extracts version, license, and verification hash from dependency manifests.
- Outputs standardized SBOM reports in CycloneDX and SPDX formats.
SKILL.md
.github/skills/sbom-generateView on GitHub ↗
--- name: sbom-generate description: "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." --- # 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`. 2. **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). 3. **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. 4. **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). 5. **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`. 6. **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"). 7. **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.
More from 686f6c61/alfred-dev
- acceptance-criteriaGenerar criterios de aceptación en formato Given/When/Then. Activar cuando el usuario quiera definir criterios de aceptacion, usar formato Given When Then, escribir en Gherkin, saber como determinar que algo esta terminado o establecer una definicion de hecho.
- architecture-docsUsar para documentar la arquitectura del sistema. Activar ante: documentar arquitectura, diagrama del sistema, como funciona el proyecto, vision general tecnica
- bundle-sizeAnalizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion.
- choose-stackUsar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o comparar herramientas.
- ci-cd-pipelineConfigurar pipeline CI/CD adaptado al proyecto. Activar cuando el usuario quiera configurar CI, crear GitHub Actions, configurar GitLab CI, montar un pipeline de despliegue, automatizar tests o implementar integracion continua.
- code-review-responseUsar al recibir feedback de code review para responder técnicamente. Activar cuando el usuario quiera responder a comentarios de PR, gestionar feedback de code review, resolver comentarios de un revisor, o cuando el revisor pide cambios en el código.
- compliance-checkUsar para verificar cumplimiento RGPD, NIS2 y CRA. También: verificar RGPD, cumplimiento normativo, NIS2, CRA, Cyber Resilience Act, protección de datos, regulación europea.
- copy-reviewRevisar textos publicos: claridad, tono, ortografia y CTAs. Activar ante: revisar textos, mejorar copy, tono de comunicacion, textos de la web, landing page copy
- dependency-strategyEstrategia integral de gestion de dependencias: inventario, evaluacion de riesgo, politica de actualizaciones y documentacion. Usar para auditar el estado global de las dependencias del proyecto.
- dependency-updateRevisar dependencias desactualizadas, con CVEs o end-of-life, y proponer actualizaciones seguras. También: actualizar paquetes, actualizar dependencias, Dependabot, Renovate, versión desactualizada, breaking changes.