Kusari operates inside your CI/CD pipeline to verify every dependency, generate signed SBOMs and VEX reports, and produce provenance attestations before a build is packaged. Cloudsmith then acts as the secure distribution layer: it stores those artifacts and their evidence packets, enforces policy on who can access or deploy them, and provides a full audit trail from build to production.

GUAC (Graph for Understanding Artifact Composition) is an OpenSSF project co-created by Kusari that aggregates SBOMs, SLSA provenance, CVEs, and VEX data into a queryable dependency graph. The Kusari platform builds on GUAC to answer questions like which containers are affected by a specific vulnerability across your entire software portfolio. Cloudsmith complements this by enforcing policy against those insights at the point of distribution.

Three common scenarios: regulated industries (fintech, healthcare, defence) that must produce signed SBOMs and attestations per CRA, SSDF, or EO 14028 requirements; platform engineering teams building internal developer platforms who want a vetted, policy-enforced artifact store downstream of their CI pipeline; and open source projects and ISVs who ship software to external customers and need provenance proof attached to every release.

Kusari generates a signed SBOM (in SPDX or CycloneDX format) and a VEX report as part of every CI build. Those documents are published to Cloudsmith alongside the artifact itself, so the SBOM is versioned, immutable, and co-located with the package it describes. Cloudsmith's policy engine can then inspect SBOM metadata to enforce license and vulnerability controls automatically.

Yes. Cloudsmith's OPA Rego-based policy engine lets you write rules that evaluate CVSS scores, vulnerability status, license types, and the presence or absence of required attestations. When combined with Kusari's context-aware vulnerability triage, you can enforce a hard gate: only builds that pass Kusari's checks and meet your Cloudsmith policy thresholds are available for download or deployment.

Kusari maintains a live dependency graph and monitors vulnerability feeds continuously. When a new CVE is disclosed, Kusari identifies every affected component in your build graph. Cloudsmith then lets you quarantine or block those specific artifact versions across all repositories instantly, preventing any further deployment of vulnerable packages before teams have finished their triage.

Yes. Both regulations require software producers to generate and maintain SBOMs, verify component provenance, and demonstrate that security checks were performed before release. Kusari automates the generation of signed SBOMs, VEX reports, and SLSA provenance attestations at build time. Cloudsmith stores and versions those documents alongside the artifact, giving you an audit-ready evidence packet that satisfies common regulatory requests.

Cloudsmith supports more than 30 artifact formats including Docker and OCI containers, Helm charts, npm, Maven, PyPI, Debian, RPM, NuGet, Cargo, and more. Any artifact format that Kusari secures at build time can be stored, policy-gated, and distributed through Cloudsmith with full provenance attached.

Yes. Cloudsmith gives you fine-grained entitlement tokens and repository-level access controls. Combined with Rego policies that check attestation metadata, you can ensure that only systems or users with the right permissions can pull artifacts that carry a valid Kusari attestation, and block everything else at the registry level.

Start by connecting your CI pipeline to both Kusari, for build-time attestation and SBOM generation, and Cloudsmith, for artifact storage and distribution. Configure Kusari to publish signed evidence packets to your Cloudsmith repository alongside each artifact. Then define Rego policies in Cloudsmith to enforce your vulnerability and license standards. The Cloudsmith integrations documentation covers API authentication, entitlement token setup, and repository configuration.