Partners — Fides + ServiceNow

SARC sits above Fides and ServiceNow. Fides is the self-hosted, tamper-evident evidence ledger that runs in the customer's own cloud; ServiceNow is the workflow system of record. SARC depends on Fides for evidence and ServiceNow for approval — it does not duplicate either. The separation is deliberate: Fides advises, ServiceNow decides (ADR-446).

Three-layer picture

SARC — orchestration + correlation

Multi-cloud (AWS / Azure / GCP / k3d / OpenShift), multi-CI (GitLab / GitHub / Azure DevOps). Runs the pipeline that produces Fides evidence, writes the Change Request back into ServiceNow, surfaces both in the karc-portal, packages the auditor evidence pack, and hosts the AUDITOR-role surfaces.

ServiceNow — workflow control plane

Change-request approval flow, CAB process, incident + problem records, CMDB, audit retention, ITIL automation. Consumes the Fides risk score (u_risk_score) as advisory input — it does not recompute compliance.

Fides — self-hosted evidence ledger

Attestations per build (artifact/SBOM, SAST/SCA/container/secret/IaC security, deploy). Trails per pipeline. Environment snapshots + drift detection. A tamper-evident hash chain + controls framework that produce a single change-gate verdict (approve / hold) and a 0-100 risk score. Runs in your cloud — no SaaS dependency.

What each does — and doesn’t

	Fides	ServiceNow	SARC
Tamper-evident attestations per build (hash chain)	✅
Environment snapshots, drift detection	✅
Per-trail evidence ground truth	✅
Change-gate verdict + 0-100 risk score	✅
Self-hosted, in your own cloud	✅
Change-request approval workflow (CAB)		✅
Standard vs Normal change model		✅
ITIL incident + problem management		✅
CMDB authoritative store		✅
Audit retention guarantees		✅
Pipeline orchestration (evidence -> CR -> deploy)			✅
Portal 5-axis risk view per CR			✅
Evidence pack one-button export (SOC 2 / DORA / PSD2 / ISO / NIST)			✅
AUDITOR magic-link sessions			✅
Cost-vuln correlation			✅
Change-window enforcement at deploy time			✅
Multi-cloud parity (AWS / Azure / GCP / on-prem)			✅
Multi-CI parity (GitLab / GitHub / ADO)			✅
Service ⇄ incident correlation graph			✅
AI agent recipes (vuln-fix, problem-investigate)			✅
MCP server for AI agent access			✅

The ServiceNow integration showcase

This is the headline of the demo. Now that evidence lives in a self-hosted Fides ledger, the ServiceNow Change Request stops being a hand-typed formality and becomes an evidence-backed, risk-scored record. Five things light up inside ServiceNow:

1. A change-gate that feeds the CR its risk score

At promotion time Fides evaluates the trail: GET /api/v1/trails/{id}/change-gate returns one verdict (approve / hold) plus a 0-100 risk_score, computed server-side from the org's governance controls (failed×25 + missing×15 + noncompliant×10, plus 20 if no human approver signed off). SARC then calls POST /api/v1/servicenow/change-gate, which writes the verdict and risk onto the CR as a work note + risk field. Crucially it does not transition CR state — Fides advises, ServiceNow decides (ADR-446).

Fields the CR carries: u_risk_score, u_risk_level, u_risk_assessment, u_risk_evidence_chain, u_fides_trail_url, u_auto_approved, u_sbom_url, u_sarif_results_url, u_security_scanners.

Approval routing reads that score, it does not recompute it: qa → Standard Change (auto-approve when compliant, threshold ≤5), prod → Normal Change (CAB review, threshold ≤2). dev auto-approves unconditionally.

2. The evidence chain, attached — not described

The CR does not just say "scans passed". SARC uploads the actual evidence: the CycloneDX SBOM, the SARIF security results, and the eight canonical Fides attestations (artifact/SBOM, SAST, SCA, container, secret, IaC, and deploy) as CR work notes. Fides evidence is also reconciled into dedicated custom tables — u_fides_artifact, u_fides_attestation, u_fides_test_result, u_fides_vulnerability (#306) — so an auditor can pivot from a CR straight into the underlying attestations without leaving ServiceNow.

3. Native CMDB reconciliation

Each deploy walks the Fides environment snapshot into ServiceNow CMDB CIs. Services match against cmdb_ci_kubernetes_workload (falling back to cmdb_ci_service) and are linked to the CR via task_cmdb_ci_service. The OpenShift path walks Build → BuildConfig → ImageStreamTag → Routes and fires a CR on build completion (#319). The result is a CMDB that reflects what is actually running, sourced from tamper-evident evidence rather than a manual discovery sweep.

4. Performance Analytics + incident/problem correlation

Because the CRs, CIs, incidents and problems now share a common evidence spine, ServiceNow Performance Analytics dashboards get real inputs: change throughput, auto-approve rate, risk-score distribution, deployment duration. SARC's service graph drives incident-to-service and CR-conflict correlation that ServiceNow can't compute natively, and pushes problem records (problem table) that link back to the offending CR and the Fides trail.

5. Separation of duties, by design

Fides approve requires at least one human session approver in addition to green controls — evidence alone never self-approves. ServiceNow then applies its own SoD via the change model (Standard vs Normal / CAB). Two systems gate two different questions — "is it technically compliant?" (Fides) and "is it operationally authorised?" (ServiceNow) — so there is no double-gate on the same decision, and the audit story is clean: Fides hash chain = evidence of record; ServiceNow CR = approval of record.

What this looks like in the portal

Fides evidence — attestations + trails + env snapshots, surfaced inside SARC.

ServiceNow CRs — enriched by SARC with the Fides risk score (u_risk_score) + trail link + SBOM/SARIF.

SARC's hash-chained audit log — the new surface that the partners can't compose alone.

The pull-through story

Customers come to the table with three procurement questions:

1. “How do we satisfy our auditor without compiling evidence by hand each quarter?”
2. “How do we ship faster without losing CAB control?”
3. “How do we do this on whichever cloud + CI we already have, without shipping our evidence to a SaaS?”

The honest answer is: Fides + ServiceNow + SARC together. Fides alone gives self-hosted evidence but no workflow. ServiceNow alone gives workflow but no automatic, tamper-evident evidence. SARC alone has nothing to orchestrate. Together, the three are the regulated-delivery story.

Because Fides is self-hosted in the customer's own cloud, the evidence never leaves their trust boundary — which is exactly what a regulated bank's auditor wants to hear.

Reading the partner relationship correctly

• SARC is not a Fides competitor. Fides’s evidence ledger is load-bearing for SARC; it owns the tamper-evident hash chain and the controls framework that produce the change-gate verdict.
• SARC is not a ServiceNow replacement. Workflow stays in ServiceNow; SARC writes into ServiceNow’s native change_request, problem, cmdb_ci_service, and the u_fides_* custom tables.
• SARC is the integration surface that lets the three tell the regulated-delivery story together. That’s the gap in the market.

×