Supply-chain risk & SBOM

This page is for SCRM (supply-chain risk management) reviewers, contract counsel evaluating EO 14028 / NIST SP 800-218 alignment, and government OSPO teams. It documents the current Pleach build pipeline posture honestly, including what is not yet in place.

Current state (2026-06-15)

Build artifacts are produced by tsup (the standard TypeScript bundle tool) and published to npmjs.org with npm-default signatures. There is no SBOM emitted with the publish, and tarballs are not signed by Sigstore yet.

Two things are in place today that materially reduce SCRM exposure:

1. Vendor-neutrality at the SKU boundary

@pleach/core and @pleach/compliance carry zero cloud-SDK runtime dependencies. This is enforced at the SKU boundary, not by convention:

• @pleach/core declares no dependency on @aws-sdk/*, @azure/*, @google-cloud/*, or @anthropic-ai/sdk.
• @pleach/compliance declares no dependency on any cloud SDK.
• Provider integrations live in separate SKUs that the host opts into. For example, the IAM identity provider at @pleach/gateway/identity/providers/iam accepts an injected STSClient and does not declare @aws-sdk/client-sts as a build-time dep.

For an air-gapped or fed-cloud deployment, this means the core runtime ships without dragging in a transitive dependency tree of cloud SDKs the operator does not want. A vendored snapshot of @pleach/core is small, auditable, and has no cloud-vendor side imports.

2. Per-SKU dependency review

Every @pleach/* SKU's package.json carries an explicit dependencies / peerDependencies / optionalDependencies block. Optional peers (like pdfkit for PDF export in @pleach/compliance) are declared as optional and the runtime gracefully degrades when they are absent. There is no implicit transitive runtime dependency that the operator is not asked to install.

A current npm ls snapshot for any SKU is available on request and is the operator's audit anchor today, pending the SBOM workflow below.

Build pipeline

The pipeline produces deterministic output (modulo timestamp embeddings) and is reproducible from a clean checkout at the publish SHA. The audit:harness-package:local-clone nightly gate verifies this end-to-end — it packs @pleach/core as a tarball, installs it in a tmpdir scratch environment, and smoke-imports SessionRuntime + createPleachRuntime. It reports a clean 8.8 MB tarball, 3.7 s install time, no runtime warnings.

v1.x roadmap

Three SCRM-relevant deliverables are explicitly v1.x (post-1.0 minor release):

SLSA provenance attestation

Target: SLSA Build Level 3 provenance for every published tarball. Build Level 3 requires hosted build (so the build environment is audit-anchored) and provenance signed by the build platform.

The governmentAgent recipe accepts slsaProvenance: boolean and stamps it on the runtime as procurement-visible metadata today. The attestation artifact itself is not yet produced — that is a publish- pipeline addition, not a runtime addition.

Sigstore signing

Target: keyless Sigstore signing of every published tarball under the project's trusted-publisher identity (npm OIDC trusted publishing). Sigstore provides a public, append-only transparency log of every signed publish, so a downstream consumer can verify the tarball they installed matches what the project published.

Pending operator-attended setup of the OIDC trusted-publisher relationship on the npm side.

SBOM emission

Target: CycloneDX 1.5 or SPDX 2.3 SBOM attached to each npm publish under a known artifact name. The dependency graph is derivable from package.json + the resolved lockfile, so the workflow is mechanical once Sigstore signing is in place (so the SBOM itself can be signed under the same trusted-publisher identity).

The governmentAgent recipe accepts sbomFormat: "cyclonedx-1.5" | "spdx-2.3" and surfaces it as procurement-visible metadata, so a host that wires SBOM emission externally can still declare the intended format.

Vendor-neutrality regression-lock

Two audit gates enforce that the SCRM posture above does not regress:

• audit:no-cross-sku-type-import-in-core — packages/core/src/ cannot import types from any sibling @pleach/* SKU outside the explicit allowlist (@pleach/core self + @pleach/compliance- contract). This defends against accidental coupling that would drag cloud SDKs into the core runtime via a transitive type-graph path.
• audit:domain-string-purity — @pleach/core cannot carry any host-specific or cloud-vendor-specific brand string.

Both gates run on every PR. They are mechanical regression-locks, not prescriptive design rules — they fail loud the moment a PR introduces a coupling the SKU boundary forbids.

Operator items

For SCRM reviewers, the following operator items are available today on request:

• npm ls snapshot for any @pleach/* SKU at any published version. Captures the exact dependency tree at publish time.
• Third-party dependency review schedule. The project reviews third-party runtime dependencies quarterly against known-CVE feeds and against the project's vendor-neutrality posture.
• Build environment anchor. The publish git SHA + tsup config
  • tsconfig.json are all under version control; a third-party reviewer can rebuild from source at any published version and byte-compare the bundle.
• License snapshot. Per-SKU LICENSE files; see License compatibility.

What this page does not claim

• Does not claim SLSA Build Level 3 today. The build is currently Level 1 (versioned source + scripted build); Level 3 is roadmap.
• Does not claim Sigstore-signed tarballs today. Roadmap.
• Does not claim SBOM emission today. Roadmap.
• Does not claim FedRAMP / IL5 / IL6 authorization. See the Government & public sector landing for the honest authorization posture.

Related

• Government & public sector landing
• License compatibility
• Air-gapped architecture
• Publishing contract
• Versioning