NexusIncident Response
The Nexus incident-response posture and shared-responsibility split — who owns what when something goes wrong, how patches flow through the versioned pull-the-update model, and how the tenant-owned architecture bounds breach blast radius. Specific commitments live in your customer agreement.
This page describes how incidents are handled across the Stingray/customer boundary, how security fixes reach your deployment, and why the tenant-owned architecture limits how far any single incident can spread. It states the model honestly and does not invent SLA timers or recovery objectives — the specific contractual terms for your deployment are set in your customer agreement, not in marketing documentation.
Shared responsibility: who owns what
Because Nexus runs inside your Azure subscription, incident ownership is split cleanly. Getting this split right is the point of the tenant-owned model, so it is worth stating precisely.
| Domain | Owner | Why |
|---|---|---|
| Your Azure subscription, resource group, tenant configuration | Customer | It is your subscription; Stingray has no standing access to it |
| Your business data, connector secrets, Key Vault contents | Customer | They live only in your tenant; Stingray never holds them |
| Your identity configuration (Entra, conditional access, MFA) | Customer | Nexus inherits your Entra posture |
| Your network policy (VNet, NSG, private endpoints) | Customer | Provisioned into your tenant, governed by your policy |
| The Nexus server image and its code | Stingray | Built, signed, and published by Stingray |
| The signed adapter bundles | Stingray | Published through the control plane, dual-signed |
| The shared control plane (updates, catalog, licensing) | Stingray | The one Stingray-operated component |
| Deciding when to apply an update | Customer | You pull updates on your schedule |
The practical reading: a vulnerability in the Nexus image or an adapter is Stingray's to fix and publish; applying that fix is your action. A misconfiguration or compromise of your subscription, identities, or network is yours to detect and respond to, using your existing Azure security operations — Nexus does not sit outside that boundary where you cannot see it.
How security fixes reach your deployment (pull-the-update)
Nexus updates ship as new, versioned container images on the 2.1.x line, distributed through the control plane. The model is pull-the-update: you decide when to apply a new image. This is deliberate — it means a bad or unexpected update cannot be pushed into your tenant without your action, and you retain change control over what runs.
When a security fix is published, the flow is:
1. Finding confirmed → tracked in the security register (severity, date)
2. Fix developed → passes gated internal security review
3. Fix covered by the automated test suite (~1,300+ server tests)
4. New versioned image published to the control-plane registry
5. Update notification available to tenants
6. YOU pull the update on your schedule → new revision rolls out
For a high-severity fix, Stingray communicates the update through your representative so you can prioritize applying it. But the apply action stays with you, preserving your change control. See Updates for the mechanics and Secure Development & Vulnerability Management for how findings are tracked upstream of this flow.
Blast-radius reduction from the tenant-owned model
The tenant-owned architecture materially bounds the blast radius of the incidents that worry buyers most.
A Stingray-side breach cannot reach your data. Stingray operates no data plane, holds none of your secrets, and has no standing key into your tenant. A compromise of Stingray's corporate environment does not, by construction, hand an attacker your business data — that data never leaves your subscription. The worst-case Stingray-side supply-chain concern (a malicious image or adapter) is itself heavily constrained by the fail-closed, dual-signature verification described in Supply-Chain Integrity, and by the fact that you choose when to pull updates.
A control-plane outage does not take your tenant down or open it up. Licensing is verified locally against a public key inside your tenant, so a control-plane outage does not disable your deployment or force a fail-open. Your data path never traverses the control plane, so a control-plane incident is an update/catalog-availability event, not a data event.
A tenant-side compromise is contained by the internal controls. Inside your tenant, credential isolation prevents cross-user secret theft, the internal workspace is walled off from operational tables, RBAC bounds every principal, and the rolling-out process-isolation worker holds no signing or managed-identity secrets — so even a pipeline sandbox escape is designed to be contained rather than to become full compromise. See Tenant Isolation & Data Custody.
Cross-tenant spread does not apply. Because there is no shared data store, an incident in one customer's tenant has no path into another customer's tenant.
Detection, evidence, and recovery
Detection and forensic evidence for activity inside your tenant live inside your tenant, where you control retention:
- Nexus persists per-run execution detail, structured logs, and the complete traceback on failure, plus before/after audit snapshots and access events. See Audit & Telemetry.
- Azure-native logging and monitoring for the Container App, PostgreSQL, and Key Vault operate under your existing Azure security-operations tooling.
- Recovery uses Azure-native mechanisms you already run: point-in-time restore on PostgreSQL Flexible Server, and the versioned store behind pipelines/reports/sites/skills (history, diff, restore). See Backup & Disaster Recovery.
Because the audit trail and the recovery mechanisms are in your subscription, an incident responder from your team has direct access to the evidence without waiting on a vendor to produce logs.
Honest limits: what is set by contract, not here
This page describes the model. It deliberately does not state response-time SLAs, notification windows, RPO/RTO figures, or uptime commitments, because those are not architecture — they are contractual terms, and they belong in your customer agreement where they can be negotiated and made binding. Do not read any timing or recovery number into this page; there are none. For the specific incident-response commitments, notification obligations, and support terms that apply to your deployment, refer to your customer agreement and your Stingray representative.