300 connectors. One schema. Every claim signed.
Sandworm integrates with 300 unique vendors across 23 categories under one OCSF 1.3 contract. The count is publicly verifiable — every aggregator response is signed with Ed25519 over the canonical-JSON inventory, and the verification math runs on your laptop with one CLI command.
Competitive position
| Vendor | Connectors | Format uniform | Signed catalog | OCSF native |
|---|---|---|---|---|
| Sandworm | 300 | Yes — OCSF 1.3 | Yes — Ed25519 | Yes |
| Splunk Cloud | ~210 | No — per-app | No | Partial (CIM) |
| Microsoft Sentinel | ~180 | No — per-connector | No | Recent (preview) |
| CrowdStrike Falcon | ~80 | No — Falcon-shape | No | Outbound only |
| Wiz | ~50 | Cloud-only | No | No |
Competitor counts from public integration catalogs as of 2026-05-26. The Sandworm catalog ships signed and becomes publicly verifiable at GA.
Architecture
23 connector-*-svc services, one per category:
identity ┐ edr ┐ network ┐ cloud-aws ┐ saas ┐
itsm ─┤ siem┤ email ┤ cloud-gcp┤ ... │
collab ┴ ... ┴ ... ┴ cloud-azure ┘
│
│ Each exposes GET /admin/catalog → list of vendors
│ (vendor, auth_model, capabilities, ingest_modes, sub_actions)
▼
connector-catalog-aggregator-svc
│ • polls every service every 5 min
│ • unions + dedupes by vendor name
│ • signs the canonical JSON with Ed25519
▼
GET https://trust.sandworm-security.com/connectors
Verify offline:
sandworm catalog verify --file catalog.json
→ uses /public/keys + nacl to check signature locally1. The claim, signed — not a slide
Sandworm integrates 300 unique vendors across 23 category services, and the catalog is built to ship as a signed attestation rather than a marketing artifact. At launch you will be able to verify the count yourself: a single request to the public trust endpoint returns a JSON document listing every vendor, their authentication model, capabilities, and the Ed25519 signature over the canonical-JSON payload. Cross-reference the signing key id against the published keys, run the verification math in any nacl-compatible library, and you have a cryptographic proof of the count.
Most security platforms publish their connector list as a marketing artifact — a slide deck, a documentation page, a PDF. Sandworm publishes it as a signed attestation backed by the same Ed25519 chain we use for triage decisions, response actions, and tenant data residency proofs. Every claim signed isn't a slogan; it's the protocol.
2. Why 300 is the threshold, not 30
A modern enterprise security team manages 60–80 vendor relationships across endpoint, network, identity, cloud, email, SaaS, and the long tail of compliance / DLP / DSPM / IGA tools. A SIEM that integrates with 30 of them leaves the other 50 as blind spots — events flow into someone else's console, and detection rules can't see them.
300 is the threshold at which the long tail collapses. Cyera + BigID + Securiti + Varonis + Sentra + Concentric + Normalyze + Symmetry + Bionic + Eureka — that's 10 DSPM vendors in one category service, covering >95% of enterprise DSPM purchases. Same density in EDR, identity, SaaS audit, vuln management, and threat intel. Customers don't need to compromise their vendor choices to fit our integration list.
3. OCSF uniformity is the structural moat
Splunk and Sentinel both have larger raw connector counts than us in absolute terms, but their connectors output per-vendor schemas. The Okta connector emits an Okta-shaped log; the Crowdstrike connector emits a Crowdstrike-shaped log. To write a detection rule that fires on "privileged user authenticated from unusual location AND endpoint shows process injection" you have to join across two different schemas, and the joinconditions depend on which versions of which connectors are installed.
Sandworm's 300 connectors all emit OCSF 1.3. Identity events from Okta, Entra, Duo, JumpCloud, Auth0, Ping, CyberArk Identity, ForgeRock, FusionAuth, Beyond Identity, HYPR, Transmit Security, RSA SecurID — 13 vendors — all map to OCSF 3002 Authentication with the same field names. A rule that fires on "authentication.user.email + endpoint.detection_finding.host where the event times are within 60 seconds" works against every combination. We write one rule and you get coverage across your specific vendor stack, whatever it is.
4. The verification protocol
Every Sandworm cluster runs a connector-catalog-aggregator service that polls the /admin/catalog endpoint on each of the 23 per-category services. The aggregator unions and deduplicates the vendor list, builds a Pydantic-validated ConnectorCatalogAttestationV1 document, and signs it with the cluster's Ed25519 key. The signature spans canonical JSON (sort_keys=True, separators removed) over the payload with the signature field set to null — a property that lets any verifier reconstruct exactly the bytes that were signed.
Run `sandworm catalog verify --file ./att.json` from the CLI and the local nacl library checks the signature against the kid's public key fetched from /public/keys. No round-trip to Sandworm during verification — the math runs on your laptop. If anyone tampered with the catalog after we signed it, the signature breaks and the CLI exits with status 1. This is the same protocol the triage agent uses to attest auto-close decisions (Move 9) and the response agent uses to attest autonomous remediation actions (Move 12), applied to the connector inventory.
5. How you will verify it at launch
At GA, three commands — no login, no NDA, no demo booking:
$ curl -sSL https://trust.sandworm-security.com/connectors | jq .vendor_count # 300
$ curl -sSL https://trust.sandworm-security.com/connectors > catalog.json
$ pip install sandworm && sandworm catalog verify --file catalog.json # verified: true
The proof will be on the wire, not in a slide.
Open by design, signed by protocol
The catalog and the verification protocol ship as part of the platform, not as a documentation artifact. At GA, a single curl command to the public trust endpoint returns the signed inventory — no login, no demo booking, no sales conversation required to confirm the count.