Security

The Shyft security model is based on a layered trust architecture that connects developer identity, organizational release trust, authenticated source history, trusted dependency sources, controlled build procedures, cryptographically signed release artifacts, and independent user-side verification.

The objective is to minimize the trusted computing base (TCB), ensure reproducible builds, and allow downstream consumers to independently verify the integrity and provenance of every released artifact.

Trust Model Overview

The following diagram summarizes the high-level trust model used by Shyft.

        ---
config:
  flowchart:
    nodeSpacing: 26
    rankSpacing: 36
  themeVariables:
    fontSize: 15px

---
flowchart TD

   subgraph ST["Source Trust"]
       A["Developer identity<br/>hardware-backed developer key"]
       B["Authenticated<br/>source history"]
       A -->|signed commits & tags| B
   end

   subgraph RT["Organizational Release Trust"]
       C["Offline certification authority"]
       D["Hardware-backed<br/>operational signing keys"]
       C -->|certifies| D
   end

   T["Trusted dependency sources<br/>• Distribution packages<br/>• Controlled local builds<br/>• Version-controlled package recipes"]

   E["Controlled build<br/>and release process"]

   F["Signed release artifacts<br/>PROVENANCE.txt<br/>SBOM"]

   G["Independent user verification"]

   H["Trusted installation<br/>and deployment"]

   B --> E
   T --> E
   D -->|authorizes release| E

   E --> F
   F --> G
   G --> H

Shyft trust model

The Shyft security model establishes trust through:

  • developer identity with authenticated source history;

  • organizational release trust based on an offline certification authority;

  • hardware-backed operational signing keys;

  • trusted software dependencies;

  • controlled and reproducible build procedures;

  • cryptographically signed release artifacts with provenance and SBOMs;

  • independent downstream verification before installation.

Threat Model

Shyft assumes a threat model where:

  • source code repositories may be subject to compromise or unauthorized modification;

  • third-party software dependencies may contain vulnerabilities, malicious modifications or unintended behaviour;

  • package repositories, build systems and distribution channels may be compromised;

  • developer workstations are only partially trusted and are not considered authoritative;

  • release artifacts may be intercepted, modified or redistributed by untrusted parties;

  • downstream users must be able to establish trust independently of the build environment.

Consequently, every external dependency—including libraries, build tools, compilers, packaging infrastructure and other build-time components—is considered part of the project’s trusted computing base (TCB). Minimizing and controlling these dependencies is therefore a fundamental security objective.

The security model is therefore designed to ensure that:

  • no single system implicitly defines trust;

  • all critical actions are cryptographically verifiable;

  • release artifacts are reproducible from authenticated sources;

  • external dependencies are minimized and originate from trusted distribution ecosystems or controlled local builds;

  • trust can be independently established by downstream consumers.

Structure of This Section

The security section is organized as follows:

Relationship to Releases

The security model described here provides the trust foundation for the Shyft release process, including dependency selection, controlled build procedures, artifact signing, provenance generation and package verification.

See also: