audit-sbom
Reviews SPDX/CycloneDX JSON SBOMs to ensure release parity and valid metadata.
Install
mkdir -p .claude/skills/audit-sbom && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/18447" && unzip -o skill.zip -d .claude/skills/audit-sbom && rm skill.zipInstalls to .claude/skills/audit-sbom
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Audit generated SPDX/CycloneDX JSON SBOMs for salt release metadata, checksums, relationships, and release parityKey capabilities
- →Generate fresh SBOMs using `make sbom`
- →Inspect expected SPDX and CycloneDX JSON SBOMs
- →Validate document shape (e.g., `spdxVersion`, `bomFormat`)
- →Validate `salt` package/component metadata
- →Validate shipped file metadata (e.g., checksums, file types)
- →Validate `libsodium` dependency metadata and relationships
How it works
The skill generates or inspects SBOMs, then validates their structure, metadata for packages and files, and dependency relationships against defined criteria.
Inputs & outputs
When to use audit-sbom
- →Validate SBOM generation output
- →Check license and copyright compliance in SBOMs
- →Verify SPDX 2.3 and CycloneDX 1.6 compliance
- →Audit release staging metadata
About this skill
Audit SBOM Skill
Use this skill to review generated SBOMs and confirm the release workflow and local make sbom target produce complete, artifact-scoped SPDX JSON and CycloneDX JSON, and that outputs remain usable for vulnerability monitoring.
Workflow
-
Generate fresh SBOMs unless the user supplied specific files.
make sbom -
Inspect all expected SBOMs.
build/sbom/salt-linux-amd64.spdx.jsonbuild/sbom/salt-linux-amd64.cyclonedx.jsonbuild/sbom/salt-static-linux-amd64.spdx.jsonbuild/sbom/salt-static-linux-amd64.cyclonedx.json
-
Validate document shape.
spdxVersionisSPDX-2.3.- CycloneDX
bomFormatisCycloneDXandspecVersionis1.6. documentNamespaceis non-empty.creationInfoexists.- The document describes the release staging layout, not the whole repository.
-
Validate
saltpackage/component metadata.name: saltsupplier: Organization: CTFfactoryversionInfoequals the release version being validated (often0.0.0locally)downloadLocation: https://github.com/CTFfactory/saltlicenseDeclared: UnlicenselicenseConcluded: UnlicensecopyrightText: Copyright 2026 CTFfactory- external purl reference:
pkg:github/CTFfactory/salt - minimum metadata quality is present: component name, version, supplier, hash, and license fields are non-empty where policy requires.
-
Validate shipped file metadata.
- Dynamic SBOM has a
files[]entry forsalt. - Static SBOM has a
files[]entry forsalt-static. - Each SBOM has a shipped-file entry/component for
salt.1. - Each shipped file has non-zero SHA1/SHA256 or SHA-1/SHA-256 hashes from Syft all-file metadata.
- SPDX binary entries have
fileTypes: ["BINARY"]; SPDXsalt.1hasfileTypes: ["DOCUMENTATION"]. - File entries/components have Unlicense and
Copyright 2026 CTFfactorymetadata.
- Dynamic SBOM has a
-
Validate libsodium dependency metadata.
- A package named
libsodiumexists. - The package has
licenseDeclared: ISCandlicenseConcluded: ISC. - A
DEPENDS_ONrelationship links thesaltpackage SPDX ID toSPDXRef-Package-libsodium. - CycloneDX has a
libsodiumlibrary component with ISC license. - CycloneDX dependencies link the
saltmetadata component tolibsodium.
- A package named
-
Validate release parity.
.github/workflows/release.ymlinvokes Syft with the same source metadata asmake sbom.- Release workflow invokes
scripts/add-libsodium-to-sbom.shandscripts/add-ubuntu-provenance-to-sbom.sh. - Release workflow includes all four SBOMs in
SHA256SUMSand release assets. - Release workflow runs
scripts/validate-sbom.sh.
-
Validate vulnerability-monitoring readiness.
- Confirm SBOM outputs are consumable by the project vulnerability-monitoring workflow (for example
make sbom-vuln, Snyk, or Trivy usage documented for release triage). - If capability is missing or drifting, report it as an operational gap even when schema/policy checks pass.
- Confirm SBOM outputs are consumable by the project vulnerability-monitoring workflow (for example
Audit Snippet
python3 - <<'PY'
import json
import sys
expected = {
"build/sbom/salt-linux-amd64.spdx.json": "salt",
"build/sbom/salt-static-linux-amd64.spdx.json": "salt-static",
}
expected_version = "0.0.0"
for path, file_name in expected.items():
with open(path, encoding="utf-8") as handle:
data = json.load(handle)
assert data.get("spdxVersion") == "SPDX-2.3", path
packages = data.get("packages", [])
salt = next(package for package in packages if package.get("name") == "salt")
assert salt.get("supplier") == "Organization: CTFfactory", path
assert salt.get("versionInfo") == expected_version, path
assert salt.get("downloadLocation") == "https://github.com/CTFfactory/salt", path
assert salt.get("licenseDeclared") == "Unlicense", path
assert salt.get("copyrightText") == "Copyright 2026 CTFfactory", path
assert any(package.get("name") == "libsodium" for package in packages), path
file_entry = next(file for file in data.get("files", []) if file.get("fileName") == file_name)
checksums = {item["algorithm"]: item["checksumValue"] for item in file_entry["checksums"]}
assert len(checksums.get("SHA1", "")) == 40 and set(checksums["SHA1"]) != {"0"}, path
assert len(checksums.get("SHA256", "")) == 64, path
assert file_entry.get("licenseConcluded") == "Unlicense", path
assert file_entry.get("licenseInfoInFiles") == ["Unlicense"], path
assert file_entry.get("copyrightText") == "Copyright 2026 CTFfactory", path
print("OK: SBOM metadata is complete")
PY
Prefer the repository validator for full SPDX/CycloneDX coverage:
./scripts/validate-sbom.sh \
--salt-version 0.0.0 \
--spdx build/sbom/salt-linux-amd64.spdx.json:salt \
--spdx build/sbom/salt-static-linux-amd64.spdx.json:salt-static \
--cyclonedx build/sbom/salt-linux-amd64.cyclonedx.json:salt \
--cyclonedx build/sbom/salt-static-linux-amd64.cyclonedx.json:salt-static
Report Format
Summarize findings in this order:
- Document validity — SPDX/CycloneDX version and namespace/serial.
- Package/component metadata —
salt, purl, license, copyright, supplier, version. - File metadata — shipped-file checksums/hashes, license, copyright, file type.
- Dependency metadata — libsodium package and relationship.
- Release parity — Makefile, workflow, checksums, release assets.
- Vulnerability-monitoring readiness — SBOM outputs remain actionable for CVE triage tooling.
When not to use it
- →When specific SBOM files are not supplied and fresh generation is not desired
Limitations
- →The skill validates against SPDX-2.3 and CycloneDX 1.6 specifications
- →The skill expects specific file paths for generated SBOMs
- →The skill requires `salt` package and `libsodium` dependency metadata
How it compares
This skill provides a structured, automated audit of SBOMs for specific project requirements, unlike a manual review that might miss compliance details.
Compared to similar skills
audit-sbom side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| audit-sbom (this skill) | 0 | 2mo | Review | Advanced |
| secrets-management | 5 | 3mo | Review | Advanced |
| security-scanning-security-hardening | 3 | 3mo | No flags | Advanced |
| sast-configuration | 3 | 2mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
secrets-management
wshobson
Implement secure secrets management for CI/CD pipelines using Vault, AWS Secrets Manager, or native platform solutions. Use when handling sensitive credentials, rotating secrets, or securing CI/CD environments.
security-scanning-security-hardening
sickn33
Coordinate multi-layer security scanning and hardening across application, infrastructure, and compliance controls.
sast-configuration
wshobson
Configure Static Application Security Testing (SAST) tools for automated vulnerability detection in application code. Use when setting up security scanning, implementing DevSecOps practices, or automating code vulnerability detection.
dependency-auditor
alirezarezvani
Check dependencies for known vulnerabilities using npm audit, pip-audit, etc. Use when package.json or requirements.txt changes, or before deployments. Alerts on vulnerable dependencies. Triggers on dependency file changes, deployment prep, security mentions.
mcp-security-scan
cisco-ai-defense
Scans MCP servers, tools, prompts, and resources for security vulnerabilities using YARA rules, LLM analysis, and Cisco AI Defense API. Use this skill when the user wants to check MCP servers for security issues, detect prompt injection, tool poisoning, or analyze MCP configurations for threats.
fix-cves
okteto
Fix all CVEs in the Okteto CLI Docker image by scanning with Trivy and updating vulnerable dependencies and binaries