Sbom generation

Skill Hayatelin/devsecops-skills/skills/sbom-generation

A security skills pack for Claude Code, Cursor, Codex and Gemini CLI: secrets pre-flight, dependency audit, secret rotation, STRIDE threat modeling, secure code review, Dockerfile hardening and env hygiene.

Install

npx -y skills add Hayatelin/devsecops-skills --skill sbom-generation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generate a Software Bill of Materials (SBOM) and use it to track and remediate vulnerable components. Use when the user needs an SBOM for compliance (e.g. SSDF, EU CRA), wants full visibility into dependencies and licenses, or is setting up continuous supply-chain monitoring.

SKILL.md

1.9 KB, as published. Nobody here has run it

sbom-generation — know exactly what you ship

When to use

The user needs an SBOM for compliance/customers, wants a complete inventory of direct + transitive dependencies and their licenses, or wants to continuously watch shipped artifacts for newly-disclosed CVEs.

Process

Pick a format: CycloneDX (security-focused, common) or SPDX (license/compliance).
Generate from the source/artifact:
- General / containers: syft <dir-or-image> -o cyclonedx-json > sbom.json
- Node: cdxgen -o sbom.json · Python: cyclonedx-py environment
- Or build-tool plugins (Maven/Gradle/Cargo) for the most accurate graph.
Scan the SBOM for vulnerabilities: grype sbom:sbom.json or osv-scanner --sbom sbom.json.
Triage by severity + reachability + fix availability; record accepted risks.
Automate: regenerate the SBOM in CI on every release, store it as a build artifact, and re-scan stored SBOMs on a schedule so you catch CVEs disclosed after you shipped.

What to check

Direct AND transitive components are present (a shallow SBOM is misleading).
Each component has a version and, ideally, a license.
The SBOM is generated from the real build, not a guessed manifest.

How to fix / act

For each vulnerable component: upgrade to the patched version, or document a justified exception (with reachability rationale and an expiry date).
Flag GPL/AGPL or unknown licenses to the user if the project ships commercially.

Report back

Give the component count, top vulnerable components (by severity + fix availability), any risky licenses, and where the SBOM is stored.