Supply Chain Integrity

Verifiable builds.
Auditable dependencies.

Every production deployment of PRIVI 2.0 is accompanied by a public software bill of materials and a signed provenance attestation. A regulator, a buyer, or an independent auditor can verify exactly what was deployed, by whom, and from which source revision.

Zoriken treats software supply-chain integrity as a first-order regulatory commitment. The artefacts described below are produced automatically by our continuous-integration system on every push to main and are published at stable canonical URLs.

Software Bill of Materials

A complete bill of materials of every direct and transitive dependency in the production build is published at the canonical paths below. Two industry-standard formats are emitted on every deployment:

CycloneDX 1.5
/.well-known/sbom/latest.cdx.json
Default format. Used by OWASP Dependency-Track and most enterprise SCA tooling.
SPDX 2.3
/.well-known/sbom/latest.spdx.json
ISO/IEC 5962:2021. Used by Linux Foundation tooling and many UK / EU public-sector procurements.
Per-build archives
/.well-known/sbom/sbom-{commit}.cdx.json
Every build is archived under its commit SHA so historical builds remain verifiable.
Build manifest
/.well-known/build-manifest.json
Pointer to the latest SBOM, attestation issuer, and verifier instructions for the live deployment.

Build Provenance Attestation

Every deployment carries a Sigstore-issued attestation declaring the source commit, the workflow that produced the build, and the identity of the GitHub Actions runner that signed the result. Attestations follow the SLSA v1.0 provenance predicate and are verifiable using GitHub’s native attestation tooling:

gh attestation verify \
  --owner    Zoriken-Technologies \
  --predicate-type https://slsa.dev/provenance/v1 \
  public/.well-known/sbom/latest.cdx.json

The verification confirms three claims: (a) the artefact was produced by a workflow in our repository, (b) the workflow ran on a hosted GitHub runner, and (c) the artefact has not been tampered with since it was signed. The attestation is rooted in the Sigstore public-good transparency log, so revocation and inclusion are publicly observable.

SLSA Posture

✓
SLSA Build Level 2 — current
Builds run on a hosted, ephemeral GitHub Actions runner. Source code is version-controlled. Provenance is generated and signed automatically by an attested service.
✓
SLSA Build Level 3 — target
Reaching Level 3 requires hardened, isolated build infrastructure where the build platform itself is non-falsifiable. Roadmap target: Q4 2026, gated on adoption of GitHub-hosted ARC or equivalent hardened runners.
✓
CVE scanning
All third-party dependencies are tracked by GitHub Dependabot. Critical and high-severity advisories trigger an automated pull request within twenty-four hours of disclosure to the National Vulnerability Database.
✓
Reproducibility
A given commit produces an identical SBOM on any clean build. npm ci against a frozen package-lock.json guarantees byte-equivalent dependency closure.

How to Verify a Live Deployment

An auditor can independently verify the production deployment of a PRIVI 2.0 tenant against the published artefacts:

  1. Fetch the build manifest at /.well-known/build-manifest.json on the tenant’s production domain.
  2. Note the commit SHA and the cyclonedx_archive URL.
  3. Download the SBOM from that URL.
  4. Run gh attestation verify as shown above to confirm Sigstore signature.
  5. Cross-check the dependency closure against advisories in your preferred SCA tool.

Vulnerability Disclosure

Findings against a dependency or against a build itself should be reported under the Zoriken Vulnerability Disclosure Policy, encrypted with the public key at /.well-known/security/pgp-key.asc.

Last reviewed: April 2026 · Workflow: .github/workflows/sbom-publish.yml