NexusEvaluator Evidence
A checklist of the artifacts a serious security and platform team can request when evaluating Nexus — architecture diagrams, deployment templates, data-flow inventory, threat-model summary, the security-findings register, red-team results, publisher permissions, telemetry field definitions, and support/access procedures — with what is public versus available under NDA.
This page exists for the reviewer who has read the rest of this section and is asking the right next question: "that is a good story — what can I actually see to verify it?" It is a concrete checklist of evidence available during a serious evaluation, with an honest marker of what is public (in these docs or on request) versus available under NDA. Nothing here is gated behind a sales call for its own sake; the NDA marker reflects that some artifacts (the raw findings register, red-team results) contain security-sensitive detail that should not be world-readable.
How to read the "availability" column
- Public — described in this documentation or providable without an NDA.
- On request — not published here for brevity, but shared with a prospective customer without an NDA.
- Under NDA — contains security-sensitive specifics (live findings, exploit paths, internal identifiers); shared with serious evaluators under a mutual NDA.
Architecture and data-flow evidence
| Artifact | What it shows | Availability |
|---|---|---|
| Architecture diagram | Components, where each runs, tenant vs control-plane boundary | Public — see Architecture and Security Architecture |
| Data-flow inventory | The complete enumerated set of data flows; what leaves the tenant and what does not | Public — see Security Architecture |
| Trust-boundary description | The single control-plane boundary and what it can/cannot reach | Public |
| Deployment templates (managed-application / IaC) | Exactly what resources are provisioned into your subscription | On request / under NDA depending on depth |
| Publisher managed-app permissions | The permissions the managed application requests in your subscription | On request |
A reviewer can reconcile the "what Stingray can and cannot access" table in Security Architecture against the actual deployment templates and requested permissions — the claim and the evidence are meant to match.
Threat model and security-program evidence
| Artifact | What it shows | Availability |
|---|---|---|
| Threat-model summary | The assets, trust boundaries, adversaries considered, and the controls mapped to each | Under NDA (summary form on request) |
| Security-findings register | Hundreds of tracked findings, severity-classified, dated, with status and remediation linkage | Under NDA |
| Red-team exercise results | Adversarial testing of the model, findings, and the fixes they drove | Under NDA |
| Internal security-review process | The gated review applied to sensitive changes | Public description — see Secure Development & Vulnerability Management |
| Remediation / disclosure process | How findings are triaged, fixed, tested, and shipped | Public description |
The register and red-team results are the substance behind the security-program narrative. They are held under NDA not to hide them from buyers but because they enumerate live, security-sensitive detail. A serious evaluator gets access to them; they are simply not published on the open web.
Supply-chain evidence
| Artifact | What it shows | Availability |
|---|---|---|
| Adapter signing scheme | Dual-signature ES256 across two Key Vaults, signed manifest, attestation, transparency log | Public — see Supply-Chain Integrity |
| Provenance attestations | SLSA-style build provenance for released bundles | On request |
| Transparency-log records | The append-only record of published bundles | On request |
| Capability manifests | The typed capability contract each adapter declares | Public — see Capability Matrix |
Identity, access, and operations evidence
| Artifact | What it shows | Availability |
|---|---|---|
| RBAC and execution-role model | Per-resource grants, roles, run-scoped elevation | Public — see Roles & RBAC, Execution Roles |
| Request-signing / replay-prevention design | Single-use signed requests, key rotation, near-real-time revocation | Public description — see Identity & Access |
| Telemetry field definitions | The exact fields in optional operational telemetry (proving it carries no business data) | On request |
| Support / operational-access procedures | Whether, when, and how any Stingray access to a tenant occurs, and how it is audited | On request / under NDA |
| Audit-trail schema | What is logged in-tenant and where retention is controlled | Public description — see Audit & Telemetry |
The telemetry field definitions are worth calling out: rather than asking you to trust "telemetry is metadata only," Stingray can show you the exact field list so your team can confirm no business data, secret, or query result is present. Telemetry is opt-in regardless.
Maturity and references evidence
| Artifact | What it shows | Availability |
|---|---|---|
| Release history / versioning | The 2.1.x line and update cadence |
Public — see Updates and the trust-and-maturity section |
| Automated test footprint | ~1,300+ automated server tests across the suite | Public — see Testing & Quality |
| Live deployment references | Two live tenants incl. a government-cloud (GCC-High) deployment and a real nightly production workload | Public — see Compliance & Shared Responsibility |
What a serious buyer should still expect to do
To be candid about the boundaries of this evidence: Nexus does not currently offer a third-party penetration-test report or an independent certification (SOC 2, ISO 27001, FedRAMP), and this page does not pretend one exists. A rigorous buyer will typically still want to:
- run their own review against the deployment templates and requested permissions in a non-production subscription;
- review the threat-model summary and the findings register under NDA;
- map Nexus's controls to their specific regulatory framework;
- agree specific incident-response, notification, and support terms in the customer agreement (see Incident Response);
- confirm current attestation status with the Stingray representative.
Stingray's position is that the tenant-owned architecture makes that due diligence tractable — most of it is due diligence on your Azure environment plus a bounded review of a small, signed, inspectable vendor surface — and that the evidence above is available to support it.