Sbom management

Skill Amey-Thakur/AI-SKILLS/skills/security/sbom-management

Plug-and-play skills and prompts for every AI coding agent

Install

npx -y skills add Amey-Thakur/AI-SKILLS --skill sbom-management

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

2 things to look at

18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
4 stars4 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

Produce signed software bills of materials from real artifacts and consume them to answer "are we affected" fast. Use when setting up build output, responding to a new advisory, or fielding a customer SBOM request.

SKILL.md

3.1 KB, as published. Nobody here has run it

SBOM management

A software bill of materials (SBOM) is the ingredient list for what you shipped. Without one, the day a critical advisory lands you are grepping lockfiles across repos and guessing what is actually deployed. Generated right and kept current, an SBOM turns that scramble into a query.

Method

Generate from the built artifact, not the source tree. Run syft against the final container image or binary: syft my-image:1.4 -o cyclonedx-json. Scanning source misses vendored code, build-time injections, and base-image packages, so the SBOM must describe what actually left the build.
Pick one format and hold it. CycloneDX and SPDX are both machine readable; CycloneDX carries dependency graph and VEX in one document, SPDX is common for license and compliance work. Convert on demand with cyclonedx-cli convert rather than maintaining two source formats.
Include the NTIA minimum elements. Every component needs supplier, name, version, a unique identifier (a PURL like pkg:npm/[email protected] or a CPE), dependency relationships, plus author and timestamp. An SBOM with no PURLs cannot be matched to an advisory feed and is decoration.
Sign the SBOM and bind it to the artifact digest. Attach it as an attestation with cosign attest --predicate sbom.json --type cyclonedx so a consumer can confirm the SBOM belongs to that exact image and was not swapped. An unsigned SBOM is a claim, not evidence.
Consume continuously, not once. Feed stored SBOMs to grype sbom:./sbom.json or load them into Dependency-Track, which re-evaluates every stored SBOM as new CVEs arrive. The point is that a fresh advisory flags an old release without anyone rebuilding it.
Emit VEX to kill the false positives. Publish an OpenVEX or CycloneDX VEX statement marking unreachable findings not_affected with a justification like vulnerable_code_not_in_execute_path, so consumers and your own dashboard stop paging on a CVE you already triaged.
Track coverage and freshness. Require an SBOM for every deployed artifact and regenerate it each release. A stale SBOM from three releases back answers "are we affected" confidently and wrongly.

Checks

Can you list every running service that contains log4j-core 2.14 from stored SBOMs in minutes, without rebuilding anything?
Does each release ship a signed SBOM whose component set matches what the image actually contains?
When a new CVE publishes, does something re-scan existing SBOMs automatically, or only the next build?

Boundaries

This skill covers producing and consuming the inventory. Hardening the pipeline that builds and signs artifacts belongs to supply-chain-defense, and gating or removing an individual risky package belongs to dependency-auditing. Format mandates from a specific regulator defer to that program's own requirements.