security-supplychain-validator_skill

This skill validates software supply chain security by generating SBOMs, scanning dependencies, and verifying provenance to strengthen artifacts.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
security-supplychain-validator skill by williamzujkowski/cognitive-toolworks | VeilStrat