Documentation / Security & Compliance

Supply-Chain Integrity

How Nexus verifies the code it runs — dual-signature ES256 adapter bundles signed by two separate Azure Key Vaults, signed file-hash manifests, SLSA-style provenance attestations, a transparency-log record, capability manifests, a runtime integrity check, and fail-closed verification before any adapter loads.

This page is for reviewers who want to know whether the code Nexus executes is the code Stingray published, unaltered — and how that is enforced rather than asserted. Nexus integrates data sources through adapter bundles distributed from the control plane. Every bundle is cryptographically verified before it loads, and verification fails closed: an adapter that does not pass every check does not run.

The problem this solves

A connector framework is, by nature, a place where third-party-published code runs close to your credentials and your data. The supply-chain risk is concrete: if an attacker could substitute a tampered adapter, or if a single signing key were compromised, malicious code could be loaded into a tenant. Nexus is engineered so that neither a tampered artifact nor a single compromised key is sufficient to get code loaded.

Dual-signature ES256, signed by two separate Key Vaults

Each adapter bundle is signed with two independent ES256 signatures, produced by two separate Azure Key Vaults. Verification requires both signatures to be valid.

This is the central control, so it is worth being precise about why it matters. A single-signature scheme has a single point of failure: whoever controls the one signing key can publish trusted code. Nexus's dual-signature scheme means an attacker must compromise two distinct Key Vaults to forge a bundle the tenant will accept. Splitting the signing authority across two vaults turns "compromise one key" into "compromise two independent key stores," which is a materially harder bar and the reason the scheme exists.

ES256 (ECDSA over P-256 with SHA-256) is a standard, well-understood signature algorithm; the security of the scheme rests on the key custody and the dual-authority requirement, not on anything bespoke.

Signed file-hash manifest

Each bundle carries a manifest that lists every file and its cryptographic hash, and the manifest itself is signed. Verification recomputes the hash of each file in the bundle and checks it against the signed manifest. This detects tampering at file granularity: flipping a single byte in any file in the bundle invalidates that file's hash, which invalidates the manifest match, which fails verification. The dual ES256 signatures cover the manifest, so the chain is: files → hashes → signed manifest → two independent signatures.

SLSA-style provenance attestation

Each bundle ships with a SLSA-style provenance attestation describing how and where the artifact was built. This lets a reviewer answer "where did this come from?" — that the artifact was produced by the expected build process rather than assembled by hand or on an untrusted machine. Consistent with this posture, locally-built bundles are refused; attestations are produced by the controlled build pipeline, so a hand-built artifact cannot masquerade as a released one.

Transparency-log record

Each published bundle is recorded in a transparency log — an append-only record of what was published. Transparency logging gives you an independent, tamper-evident account of the release history: a bundle that a tenant loads can be checked against the published record, and a bundle that was never published (or was quietly swapped) is detectable because it is absent from, or inconsistent with, the log. This is the same principle that underpins certificate transparency: make the set of "things that were signed" publicly and immutably observable so that covert issuance is caught.

Capability manifests

Each adapter declares a capability manifest — the typed set of operations and pushdown behaviors it supports (read, the specific write operations, the WHERE/ORDER/GROUP/aggregate pushdown it can perform, discover_schema, and so on). This is both a functional contract and a security control: the engine knows precisely what an adapter is entitled to do, capabilities are explicit rather than ambient, and the query engine enforces safe fallback (re-applying filters in-engine) when an adapter does not declare full pushdown. See Capability Matrix and the UQL capability semantics.

Runtime integrity check and fail-closed loading

Verification is not a one-time publish-side ceremony that the tenant takes on faith. The Nexus server performs a runtime integrity check before loading an adapter: it validates the signatures, recomputes and checks the manifest hashes, and confirms the artifact's integrity at load time, inside your tenant.

The loading policy is fail-closed. If any check fails — a signature does not verify, a file hash does not match, the artifact is not properly attested — the adapter is not loaded. There is no "load anyway with a warning" path and no degraded mode that runs unverified code. The default is refusal.

Adapter load sequence (all checks must pass; any failure = not loaded):

  1. Fetch bundle from the control-plane catalog
  2. Verify ES256 signature #1  (Key Vault A)   ─┐ both required
  3. Verify ES256 signature #2  (Key Vault B)   ─┘
  4. Recompute every file hash → match signed manifest
  5. Validate SLSA-style provenance attestation
  6. Check transparency-log consistency
  7. Load capability manifest (typed contract)
  8. Runtime integrity check
  ───────────────────────────────────────────────
  Pass → adapter available to bridges
  Any failure → FAIL CLOSED, adapter not loaded

Why this is strong

Put together, an attacker who wants to get malicious adapter code running inside a tenant must simultaneously: forge two ES256 signatures from two separate Key Vaults, produce a matching signed file-hash manifest, fabricate a convincing provenance attestation, and evade a tamper-evident transparency log — and even then, the fail-closed runtime check inside your tenant is the last gate. Each layer is independently sufficient to catch a naive tampering attempt; defeating the whole chain requires compromising multiple independent trust anchors at once.

What this does and does not do

It does: guarantee that adapters are the artifacts Stingray published, unaltered, verified inside your tenant before they run, with no single signing key as a point of failure and a public record of what was released.

It does not: claim a third-party audit of the signing infrastructure, and it does not extend automatically to code you write yourself. Customers with developers can build connectors on the adapter contract; when you author your own pipeline or connector code, you are the publisher for that code, and it runs under the sandbox and RBAC controls described elsewhere in this section rather than under Stingray's signing chain. The signing story here is about the adapters Stingray distributes.