- Home
- Skills
- Williamzujkowski
- Cognitive Toolworks
- Security Supplychain Validator
security-supplychain-validator_skill
- Python
5
GitHub Stars
3
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill williamzujkowski/cognitive-toolworks --skill security-supplychain-validator- CHANGELOG.md1.1 KB
- index-entry.json726 B
- SKILL.md13.3 KB
Overview
This skill validates software supply chain security by generating SBOMs, scanning dependencies for vulnerabilities, verifying provenance, and producing SLSA attestation and compliance outputs. It supports SPDX and CycloneDX formats and provides tiered workflows for quick checks (T1) or full provenance and attestation (T2).
How this skill works
The skill detects artifact type and extracts package manifests or container base images, then generates SBOMs using appropriate tooling and scans them against NVD/OSV/GitHub advisories. For T2 it retrieves in-toto/Sigstore provenance, verifies signatures via transparency logs, assesses SLSA levels, and computes a supply-chain risk score and EO 14028 compliance status. Outputs are machine-readable JSON with optional human-readable summaries and SARIF for CI integration.
When to use it
- When SBOM generation is required for compliance (EO 14028 or NTIA minimum elements)
- Before deployment to assess dependency vulnerabilities and block on configured thresholds
- When verifying provenance or SLSA attestation for critical artifacts
- For container image validation prior to production rollout
- During software procurement or third-party component risk evaluations
Best practices
- Default to SPDX for broad NTIA alignment; use CycloneDX or both when VEX or extra security context is needed
- Set vulnerability_threshold appropriately (low/medium/high/critical) to enforce desired gate behavior
- Require T2 for production-critical services or when SLSA level is specified
- Redact secrets and internal paths; never expose credentials in SBOM outputs
- Log tool versions, database snapshot dates, and timestamps to ensure auditability
Example use cases
- Generate SPDX SBOM and run grype on a container image before CI deploy (T1)
- Produce both SPDX and CycloneDX for a production binary and run full provenance verification with cosign and Rekor (T2)
- Audit a third-party package set for unpinned dependencies and provenance coverage during procurement
- Validate EO 14028 compliance for a release by checking SBOM presence, signing, and attestations
FAQ
Supported artifact_type values: source, container, binary, package. Location must be an accessible path, URL, or registry reference.
How does vulnerability threshold affect deployment gating?
Thresholds map to blocking rules: critical blocks on any CRITICAL CVE; high blocks on CRITICAL or HIGH; medium blocks on CRITICAL/HIGH/MEDIUM; low reports but does not block.