Reaching 48 of 48

48 of 48 controls passing. 0 failing. Across all 7 frameworks — SOC 2, ISO 27001, PCI-DSS, PSD2, NIST 800-53, SOX, DORA. Live, per change, auditor-ready.

This page explains exactly how that number is reached: what the pipeline has to produce, what Fides does with it, where ServiceNow fits, and why the last two controls can only be closed by a human.

The key insight — 48 controls, a handful of gates

Every control in the catalogue carries a pipelineGate — the binding between the control and one piece of delivery evidence. The resolver is control-agnostic: it keys on the gate, not the control. So satisfy a gate once, and every control that uses it — across every framework — turns green together.

That collapses 48 controls into eleven gates:

Gate	Satisfied by	Kind
sast	Static analysis scan → Fides attestation	automated
secret	Secret-detection scan	automated
dependency	Dependency / SCA scan	automated
container	Container image scan	automated
iac	Infrastructure-as-code scan	automated
sbom	CycloneDX SBOM → Fides attestation	automated
audit	Provenance / in-toto attestation	automated
rollback	Atomic-rollback plan evidence	automated
sod	Segregation-of-duties check	automated
peer_review	A human approves the merge request	human
cr_approved	A change board approves the ServiceNow CR	human

Nine gates are produced automatically by the pipeline. Two require a human — and that is the whole point (see Why the last mile is human).

The pipeline: manufacturing the evidence

Each push runs the pipeline, which builds, scans, and — critically — attests every result to Fides. An attestation is a signed claim (“this scan ran, here’s the result”) chained into a tamper-evident hash chain. The evidence gates resolve directly from these:

• Security scanners (SAST, secret, dependency, container, IaC) → Fides scan attestations
• CycloneDX SBOM generator → Fides sbom attestation
• fides:attest:* provenance jobs → the audit gate
• compliance:rollback-plan job → the rollback gate (atomic Helm rollback is in place)
• compliance:sod-check job → the sod gate (four-eyes enforced)
• fides:attest:pullrequest → the pull-request attestation the change-gate needs

The portal reads the deployment trail’s jobs, classifies each into its gate, and resolves the automated controls. Once these are flowing, the frameworks sit at 40/48 — everything except the two human gates.

The change-gate and ServiceNow: the ITSM half

The remaining two controls are about authorisation, so they route through the Fides change-gate and ServiceNow:

1. Fides scores the change. fides change-gate turns the evidence + control coverage into a 0-100 risk score and an approve / hold verdict.
2. It writes that verdict onto a ServiceNow Change Request — commit SHA, risk, evidence links, all embedded.
3. On HOLD it raises a ServiceNow Incident — a blocked change becomes a tracked, assignable ITSM record, not a silent CI failure.
4. A change board approves the CR. That approval — matched to the deployed commit by u_commit_sha — resolves cr_approved.
5. A reviewer approves the merge request. That resolves peer_review.

With both human sign-offs present, the gate flips hold → approve, the deploy proceeds, and the portal reads the approved MR + approved CR — closing the last two controls. 48/48.

The full flow, end to end

⛶ Fullscreen

sequenceDiagram
  autonumber
  participant Dev as Developer
  participant CI as GitLab CI
  participant Fides as Fides (Evidence Vault)
  participant SN as ServiceNow
  participant Portal as SARC Portal

  Dev->>CI: Open MR; a 2nd human approves it
  Note over CI: peer_review evidence
  CI->>Fides: attest sast, secret, dep, container, iac
  CI->>Fides: attest sbom, audit, rollback, sod, pull_request
  CI->>Fides: change-gate --trail <sha>
  Fides->>Fides: risk 0-100 vs control coverage
  Fides->>SN: write verdict onto Change Request
  alt evidence incomplete OR no human sign-off
    Fides->>SN: raise Incident — deploy blocked
    Fides-->>CI: HOLD (pipeline fails)
  else evidence complete + human sign-off
    SN->>SN: change board approves the CR
    Fides-->>CI: APPROVE
    CI->>CI: deploy
  end
  Portal->>Fides: read trail + attestations
  Portal->>SN: read CR approval by u_commit_sha
  Note over Portal: 48 / 48 · 0 fail

Why the last mile is human

You cannot automate your way to 48/48 — and that is a feature, not a limitation. peer_review and cr_approved exist precisely to prove that:

• a second person reviewed the code (four-eyes), and
• a change authority approved the production change (separation of duties).

A machine self-approving its own change would defeat the control. So the platform manufactures all the evidence automatically, computes the risk, and routes the decision to humans — then records their sign-off as first-class evidence. The 0 fail state is the healthy signal: nothing is broken; the only things ever “skipped” are approvals that genuinely haven’t happened yet.

This is the compliance story a regulator wants to hear: every change carries machine-verified evidence AND a documented human authorisation, and the portal can show both, per change, at source.

What role Fides plays

Fides is the evidence and provenance engine — the “advises” in Fides advises; ServiceNow decides. Everything green on the compliance page traces back to it:

• Trails + artifacts — every build is a trail keyed by commit SHA; artifacts keyed by SHA-256 digest.
• Attestations (12+ types) — sast, secret, dependency, container, IaC, SBOM, provenance/audit, rollback, SoD, pull_request, approval — each chained into a tamper-evident hash chain (verify-chain proves it’s intact).
• The change-gate — Fides is what turns raw evidence + control coverage into a risk score and an approve/hold verdict, and refuses to approve without a human session approver.
• ServiceNow write-back — Fides writes the verdict onto the CR and raises the incident on a block.
• Control coverage — Fides enforces the SARC controls across the environments and reports coverage; the portal’s Fides → Controls tab reads it directly.

Without Fides there is no signed evidence, no risk score, no tamper-evidence, and no gate — just scan logs nobody trusts. Fides is what makes the 48/48 provable rather than merely asserted.

In short — what it took

• Produce every piece of evidence in the pipeline and attest it to Fides (scans, SBOM, provenance, rollback, SoD, pull-request).
• Resolve every gate in the portal from the deployment trail — the nine automated gates from attestations, the two human gates from the GitLab MR approval and the ServiceNow CR approval.
• Enforce the human sign-offs — a merge-request approval rule for peer_review, and the Fides change-gate → ServiceNow CR → change-board approval for cr_approved.

Do all three and the frameworks read 48/48, 0 fail — automatically, on every change, with the evidence one click away.

See also: the Fides x ServiceNow showcase for the live walkthrough, the ServiceNow integration for the technical design, and Compliance frameworks for the control catalogue.