Sealkeep release provenance and SBOM status

Status: Partial controls implemented; complete public per-release evidence planned
Reviewed: 2026-09-04
Current source package version: 0.10.0

This page states the release evidence Sealkeep can show today and the controls it does not yet claim. It is not a software-signing or supply-chain certification.

Available today

package-lock.json records the resolved npm dependency graph and integrity fields.
The package declares supported runtime and platform constraints.
The build runs from TypeScript source and the release process can be tied to a named

source revision.

Release tooling computes a SHA-256 digest and byte size for a packed artifact.
Release tooling emits an explicitly unsigned manifest when no signing key is

supplied; it does not silently make an unsigned artifact appear signed.

When a deliberately supplied release key is available, the manifest format supports

an Ed25519 signature and key identifier.

Automated tests cover cryptographic tampering, restore integrity, queue durability,

upload verification, tenant boundaries, device auth, and company collaboration.

Evidence expected with an enterprise delivery

Evidence	Current status
Product name, semantic version, build timestamp	Available in package/build metadata
Source revision	Record for the delivered build
Artifact filename, byte size, SHA-256	Supported by release tooling
Dependency lockfile	Available
Machine-readable SBOM (CycloneDX or SPDX)	Planned for public per-release publication
Signed release manifest and published verification key	Supported by tooling; public release operation and key policy remain to establish
OS code-signing/notarisation	Not currently claimed
Reproducible-build proof	Not currently claimed
Vulnerability scan summary and disposition	Process and public artifact remain to establish
Build-system attestation (for example SLSA provenance)	Not currently claimed

Acceptance rule

A buyer should treat only the evidence supplied for the exact delivered artifact as release provenance. A source lockfile, test run, checksum, signed manifest, SBOM, OS signature, and independent assessment answer different questions and must not be presented as interchangeable.

Planned public release bundle

Versioned artifact and SHA-256 checksums.
Source revision and build-environment identity.
CycloneDX or SPDX SBOM generated from the shipped dependency graph.
Signed manifest plus published verification procedure and key-rotation policy.
Test and vulnerability-scan summary with unresolved findings stated.
Platform signing/notarisation evidence when certificates are operational.

Supply-chain questions: security@spala.ai