Supply-chain security

OpenSIP CLI is distributed through npm, so customer safety depends on two

layers:

install hooks, must be built from frozen dependencies, and must be published

with npm trusted publishing/provenance.

dependency lifecycle scripts during install unless the customer disables or

allowlists them. That means the curl installer is safer

after these gates, but it is not a zero-risk operation.

The project intentionally does not rely on a custom chained-checksum system.

Lockfiles already contain integrity hashes for registry tarballs, package

manager pins keep the install tool stable, and npm provenance ties published

packages back to the GitHub Actions release job. The checks below make those

standard controls explicit and fail closed.

What OpenSIP enforces before publish

pnpm supply-chain:verify runs in both CI and the release workflow. It fails if:

postinstall.

Corepack value.

allowBuilds, minimumReleaseAge, minimumReleaseAgeStrict,

minimumReleaseAgeIgnoreMissingTime, trustPolicy: no-downgrade,

trustLockfile: false, and blockExoticSubdeps: true.

enforcement, such as pnpm without --frozen-lockfile or Bun without

--frozen-lockfile.

executable npm publish step (including commands inside shell functions), or

references long-lived npm publish tokens in a publish step. A classic token used

solely for npm dist-tag add promotion in an OIDC publish workflow is the

documented exception (OIDC does not cover dist-tag).

SHA256SUMS, CycloneDX SBOM, or pinned GitHub Artifact Attestations before

publish.

Producer provenance lane

Ordinary OpenSIP releases publish with OIDC trusted publishing and

npm publish <tarball> --provenance. pnpm supply-chain:verify gates this in CI

and release.yml before publish. The only documented non-provenance exception is

the one-time bootstrap for brand-new package names — see RELEASING.md.

Tag releases also upload verification files to the GitHub Release:

opensip-cli-release-manifest.v1.json, SHA256SUMS, and

opensip-cli-sbom.cyclonedx.json. The same workflow creates pinned

actions/attest provenance/SBOM attestations for the release artifact set. See

Verifiable releases for hash and provenance

verification commands.

Consumption-side verification (install/load provenance checks for third-party

packages) is a separate trust gate coordinated with

ADR-0068 and

ADR-0061.

It is not enforced by the reusable check or the release gate in this repo yet.

The release workflow still installs npm 11 into a separate prefix because npm

11 is required for the trusted-publishing token exchange. The supply-chain gate

allows that package-manager bootstrap while continuing to reject mutable project

dependency installs.

Dependency update hygiene

Dependency update PRs are opened by Dependabot (see

ADR-0069) on a

weekly cadence. Automation is additive — it does not replace human review.

Every dependency merge still passes:

trustPolicy: no-downgrade, exact trustPolicyExclude / minimumReleaseAgeExclude

entries reviewed by maintainers)

Trust-policy exemptions are exact-version and hand-reviewed; Dependabot does not

edit pnpm-workspace.yaml automatically.

Customer install risk

For the global CLI install:

curl -fsSL https://opensip.ai/cli/install.sh | bash

OpenSIP's release gate protects customers from OpenSIP package-level install

hooks and from releases published with long-lived npm tokens. The remaining

risk is mostly outside the OpenSIP tarballs:

quieter customer-facing output.

for latest before the ecosystem has had time to take it down.

compromise can still affect the install.

For highly sensitive environments, prefer a pinned version and install through

an internal mirror or vetted cache:

curl -fsSL https://opensip.ai/cli/install.sh | OPENSIP_CLI_VERSION=0.8.5 bash

Customers who globally disable npm lifecycle scripts should test the CLI in

their environment first; native dependencies in the dependency graph may require

their own install/build step even when OpenSIP packages do not.

Capability-pack trust

Capability packs (fitness check packs, simulation scenario packs, graph

adapters) are executable extensions that load per run, so they get their own

trust bar

(ADR-0171):

pack is denied on load until an operator grants it.

opensip policy trust <pack> (revoked by opensip policy untrust <pack>).

Each grant binds the exact package id to the pack's provenance (its

opensipTools manifest hash) resolved at grant time. A resolved pack whose

provenance no longer matches the grant is denied with guidance to re-verify

and re-grant — a bare trusted name would be shadowable through the analyzed

repo's node_modules. * is never honored.

project's own opensip-cli.config.yml selects a pack for discovery but never

trusts it, and a trust block in the project config is a hard schema error —

only the out-of-repo user config carries grants.

untrusted repos. Repo-authored automation (the repo's own scripts and

workflows) is already arbitrary code execution and sits outside this

boundary.

Grant and revoke ceremonies, and every denial, are recorded on the local

trust-audit plane (opensip policy audit).

Using the reusable check

The universal check pack now includes package-supply-chain-policy. It inspects

package metadata, root lockfiles, package-manager config, and GitHub workflows

for npm/pnpm/Bun projects.

Run it directly:

opensip fit --check package-supply-chain-policy

It reports:

trustedDependencies.

This check is useful for OpenSIP customers too: it turns the same supply-chain

posture into a normal fitness rule they can add to their own CI.