Software Supply Chain and Secure Updates

A communications platform is only as trustworthy as the process that produces and delivers its software. SANKET gives the customer the means to verify a release independently and to decide when it is installed.

30.1 Supply-Chain Controls

Table 52: Software supply-chain controls

The approach aligns with the practices of the NIST Secure Software Development Framework and the SLSA provenance model in intent;²³ SANKET does not claim a formal SLSA level.

30.2 Release Contents

An offline release package is a single archive with a SHA-256 sidecar, containing the signed manifest, image archives for SANKET's own services, the base and release Compose definitions, the hardening overlay, SQL migrations, edge, secrets-service and media-server configuration, deployment scripts and the artefact inventory. It excludes environment files, certificates, keys, secrets and licences. Third-party base images (database, cache, object store, edge, secrets service, push relay) are not bundled and must be pre-staged by the customer from a verified source.

30.3 Reference Update Process

Figure 16: Offline software update architecture

1. Build. Images are built from the pinned lockfile on a self-hosted runner and saved as archives.
2. Manifest and signature. The manifest of hashes is signed with the release key.
3. Package. The offline package and its checksum are published to the customer through an agreed channel.
4. Transfer. The customer moves the package across the air gap on controlled media under its custody procedure.
5. Scan. The customer scans the package with its own tools.
6. Verify. The verification tool recomputes the manifest digest, every image archive hash and size, and the configuration bundle hash, and verifies the Ed25519 signature with the release public key configured in the installation. It refuses a manifest that has expired or whose sequence number is below the installation's recorded floor. The compose file that names the images to run is never taken from the package: the verification tool writes it from the verified manifest. Each archive is checked at the exact path it is then loaded from, only the archives the manifest lists are loaded, and a connected upgrade refuses an artifact list that differs from the signed manifest. The manifest may also state, per platform (iOS, Android and desktop), the lowest client app version the release needs; that statement is covered by the same signature, its shape is checked, and it is reported only from a manifest whose signature was verified.
7. Stage. The customer installs the release in a staging environment and tests it.
8. Approve. The customer's change authority approves deployment.
9. Upgrade. The upgrade tool verifies again, loads images, snapshots the current state, switches versions, runs a health check and rolls back automatically on failure. Images are verified and loaded, and every image the new version needs is checked to be present, before any service is interrupted: a release that cannot be staged fails with the running version still serving. The manifest also lists every database migration with its class (expand: the previous version keeps working; contract: it may not) under the same signature. In the high-availability profile the upgrade runs host by host with health gates between steps, and every host performs the same signature, expiry, sequence and downgrade checks itself: a host given an unsigned or older package refuses it even when the others accept.
10. Record. The upgrade is recorded; post-upgrade gates check that running images match the manifest.

30.4 Independent Verification by an Air-Gapped Customer

The verification tool uses only built-in platform cryptography and can be run on an isolated machine. A customer can therefore: obtain the release public key once, out of band; recompute every hash in the package; verify the signature; compare the manifest's source commit with any source-escrow arrangement; and confirm after installation that running images match the manifest.

30.5 Rollback, Pinning and Emergency Patches

• Version pinning: every base and third-party image is pinned by version and content digest in the container builds and the deployed configuration, and a release check refuses a reference pinned by tag alone. SANKET's own images are pinned by the SHA-256 of their signed release archives, and post-install gates check the running images against the signed manifest.
• Rollback: automatic. An upgrade is complete only after the new version is healthy, has applied its database migrations and answers smoke checks; on any failure it restores the previous images, configuration and, where the switch requires it, databases from its encrypted restore point, then checks the previous version the same way. Restore points are integrity-checked and bound to their installation before use. Every upgrade and rollback is recorded in the release audit log.
• Release selection: which signed releases may be installed is governed by the customer's change management. An expired release is refused, so an old release cannot be presented as current indefinitely, and downgrades are refused by the signed sequence number as well as the release version unless explicitly authorised and recorded in the release audit log. A server also refuses a signed licence that requires a newer backend release. An organisation can therefore still roll back deliberately to an earlier signed release when operationally required.
• Emergency patches follow the same signed path; a configuration-only release can update the configuration bundle without new images.
• Connected upgrades (optional) fetch packages and their SBOMs with short-lived, signed download authorisations, check the registry's signed timestamp statement, verify the package and run the same process. Upgrade execution from the console is off by default.

---

Footnotes

1. OWASP Foundation, "CycloneDX Bill of Materials Standard" (ECMA-424); and The Linux Foundation, "SPDX Specification" (ISO/IEC 5962:2021). ↩

2. M. Souppaya, K. Scarfone, D. Dodson, "Secure Software Development Framework (SSDF) Version 1.1", NIST SP 800-218, February 2022. ↩

3. OpenSSF, "Supply-chain Levels for Software Artifacts (SLSA)" v1.0, slsa.dev. ↩