Pipelines + integration

SARC runs the same compliance pipeline on three CI platforms — GitLab CI, GitHub Actions, and Azure DevOps — and pushes the resulting evidence into the Evidence Vault / Fides and the resulting workflow events into ServiceNow.

This page is the conceptual integration map. It is enough to evaluate, design around, or have an architecture conversation about. It is not a copy-paste install guide — the underlying templates carry the secrets, the registry config, and the per-cloud auth wiring, and live in the repository for engagement customers.

The three-platform shape

Per CI platform, the pipeline has the same six logical stages:

1. Validate — yaml lint, shell lint, helm lint+template, type-check, schema-drift.
2. Test + scan — unit tests, SAST, SCA, container scanning, secret scanning, IaC scanning, dependency scanning.
3. Attest — push every scan + every artefact + every metadata blob to the Evidence Vault as attestations on the running trail.
4. Build + publish — container build + push to the registry (ECR / GHCR / ACR / Artifact Registry).
5. Approve + deploy — create / update the ServiceNow change request with the 5-axis risk score, wait on CAB if needed, deploy via Helm + ArgoCD.
6. Post-deploy — evidence env-snapshot attestation, ServiceNow CR closure, DAST follow-up, notifications.

Stage	GitLab CI source	GitHub Actions source	Azure DevOps source
Validate	.gitlab/ci/templates/validate-*.yml	.github/workflows/_reusable-validate.yml	ci/azuredevops/templates/validate-*.yml
Test + scan	.gitlab/ci/templates/security-scans.yml + GitLab Security templates	.github/workflows/_reusable-security-native.yml + _reusable-appsec.yml + _reusable-container-scan.yml + _reusable-sbom.yml	ci/azuredevops/templates/scan-*.yml
Attest	.gitlab/ci/templates/fides-attest.yml + fides-supply-chain.yml	.github/workflows/_reusable-fides.yml + _reusable-supply-chain.yml	ci/azuredevops/templates/fides-*.yml
Build + publish	.gitlab/ci/templates/build-portal.yml + build-podtato.yml	.github/workflows/_reusable-build-portal.yml + _reusable-build-podtato.yml	ci/azuredevops/templates/build-*.yml
Approve + deploy	.gitlab/ci/templates/deploy-helm.yml + servicenow-cr.yml	.github/workflows/_reusable-deploy.yml + _reusable-fides-change-gate.yml	ci/azuredevops/templates/servicenow-*.yml + deploy-helm.yml
Post-deploy	.gitlab/ci/templates/servicenow-cr.yml (close jobs)	.github/workflows/deploy-helm-*.yml (orchestrator)	ci/azuredevops/templates/postsync-*.yml

GitLab is the source of truth; GitHub Actions and Azure DevOps reach functional parity for the gates that matter (validate, attest, deploy, post-deploy). Some per-platform specifics — GitLab Security scanners vs. GitHub Advanced Security vs. ADO equivalents — differ in implementation but converge to the same attestation shape inside the Evidence Vault.

How CI talks to the Evidence Vault (Fides)

The Evidence Vault is the evidence data plane — SARC ships with Fides, and any compatible attestation backend can be integrated. Each pipeline run is a “trail.” Every scan, build, and deploy is an “attestation” on that trail.

The conceptual flow:

⛶ Fullscreen

flowchart TD
  SCAN["CI job: scan<br/>attest:security<br/>(SARIF report)"]
  BUILD["CI job: build<br/>attest:artifact<br/>(container digest)"]
  DEPLOY["CI job: deploy<br/>attest:deploy<br/>(env snapshot)"]
  TRAIL["Evidence Vault / Fides trail (per pipeline)<br/>policy-aliases -&gt; pullrequest -&gt; artifact -&gt; deploy"]
  PORTAL["SARC portal 'Fides' view<br/>+ risk score input"]

  SCAN --> TRAIL
  BUILD --> TRAIL
  DEPLOY --> TRAIL
  TRAIL -->|"sync: portal CronJob + karc-portal webhook"| PORTAL

  class SCAN,BUILD,DEPLOY ci
  class TRAIL fides
  class PORTAL portal

  classDef ci fill:#1f6feb,stroke:#0b3d91,color:#ffffff
  classDef fides fill:#2da44e,stroke:#116329,color:#ffffff
  classDef portal fill:#8957e5,stroke:#512a8f,color:#ffffff

Authentication: each CI platform uses a different mechanism, all of them short-lived (no long-lived API keys in the pipeline):

• GitLab CI — Fides API token in masked CI variable.
• GitHub Actions — Fides API token in encrypted GitHub secret.
• Azure DevOps — Fides API token in Azure Key Vault, surfaced via the ADO Library variable group.

The token’s scope is limited to write attestations on the configured flows; it cannot read other tenants’ data or modify the Evidence Vault policy.

Example of an attestation invocation (omitted: the full env wiring + the trail-naming convention):

# Container image attestation — happens after build, before push to env
fides attest artifact "${IMAGE}@${DIGEST}" \
  --flow karc-pipeline \
  --trail "${CI_COMMIT_SHORT_SHA}" \
  --build-url "${CI_JOB_URL}"

The trail-naming + flow-naming convention, and the per-cloud env-name mapping (${TARGET_CLOUD}-karc-${env}), are intentionally not documented in full here — they live in the engagement docs.

How CI talks to ServiceNow

ServiceNow is the workflow control plane. CRs, problems, incidents, and the (optional) u_fides_* custom tables.

Three integration points, mapped to when in the pipeline they happen and whether they read or write ServiceNow:

⛶ Fullscreen

flowchart TD
  subgraph ATTEST["attest stage — create + enrich the change record"]
    direction TB
    RC["READ service catalog -> assignment group<br/>READ change-window calendar -> planned window"]
    CR["cr:create (+ cr:create:infra)<br/>WRITE change_request<br/>+ u_sarc_risk_score (5-axis) · u_target_cloud · u_deploy_env"]
    RPT["cr:comply-report<br/>WRITE attachment: scan reports + evidence trail link"]
    SB["cr:sbom-attach<br/>WRITE attachment: CycloneDX SBOM zip"]
    SY["servicenow:fides:sync<br/>WRITE u_fides_artifact · u_fides_test_result · u_fides_vulnerability"]
  end

  subgraph APPROVE["deploy-qa / prod — the gate"]
    direction TB
    WAIT{"cr:wait-qa / cr:wait-prod<br/>READ approval state (poll)<br/>auto-approve if risk compliant<br/>prod = manual CAB only"}
  end

  subgraph POST["post-deploy — close the loop"]
    direction TB
    CL["cr:close:dev/qa/prod<br/>WRITE state: Implemented -> Closed"]
    CM["WRITE CMDB<br/>cmdb_ci_service · cmdb_ci_deployment<br/>image digest + evidence trail link"]
  end

  SNOW[("ServiceNow")]

  RC --> CR
  CR --> SNOW
  RPT --> SNOW
  SB --> SNOW
  SY --> SNOW
  SNOW --> WAIT
  WAIT -->|approved| POST
  CL --> SNOW
  CM --> SNOW

  class RC read
  class WAIT gate
  class CR,RPT,SB,SY,CL,CM write
  class SNOW snow
  classDef write fill:#2da44e,stroke:#116329,color:#ffffff
  classDef read fill:#1f6feb,stroke:#0b3d91,color:#ffffff
  classDef gate fill:#9a6700,stroke:#5c3d00,color:#ffffff
  classDef snow fill:#d29922,stroke:#8a6500,color:#ffffff

Reading it (green = write, blue = read, gold = approval gate): in attest the pipeline reads the service catalog and change-window calendar, then writes the change request, its risk score, and the evidence attachments. In approve-deploy it reads the CR’s approval state to gate qa/prod. In post-deploy it writes the CR to Closed and updates the CMDB. The three integration points below describe each in detail.

1. Create the CR + enrich it

After scans + attestations complete, the pipeline calls a ServiceNow create-CR endpoint with:

• short description (commit msg + change summary)
• assignment group (per-service, looked up from the SARC service catalog)
• planned start/end window (from the change-window calendar sync if configured)
• attached artefacts: SBOM (CycloneDX), SARIF reports, the evidence trail URL
• the 5-axis risk score as a custom field (u_sarc_risk_score)

A second job uploads the bulk attestations to the CR via the ServiceNow attachment API.

The 5-axis score is computed by scripts/ci/fides-score.sh (in the repo). The math is straightforward but the weights are tunable per-tenant — that part lives in tenant config.

2. Wait on approval

For QA and prod the pipeline blocks on CR approval. Two approval flows:

• Auto-approve — if all five risk axes are below tenant-configured thresholds. Configurable per-env.
• Manual — production always; QA when one or more axes exceeds threshold.

The wait is a polling job. Timeout + reschedule logic lives in scripts/ci/servicenow-cr-wait.sh.

3. Close the CR + push CMDB

After successful deploy:

• The CR moves to Implemented then Closed via the ServiceNow API.
• The CMDB (cmdb_ci_service, cmdb_ci_deployment) is updated with the new image digest + the evidence trail link.
• For OpenShift tenants, the BuildConfig → Build → ImageStreamTag → Route walk is pushed as separate CIs (see issue 319 in the migration plan).

The OAuth + REST API config on the ServiceNow side is the operator’s responsibility; SARC ships the calling code, not the SN instance setup.

How the rest of the systems plug in

System	What it is	How CI talks to it	Where it shows in the portal
GitLab Security	SAST, DAST, container, dep, secret scanning	GitLab CI templates (built-in artifacts)	/vulnerabilities, /scans
Trivy / Grype	Container vuln scanning (cross-platform)	Reusable scan steps on all three CI	/vulnerabilities
Checkov	IaC scanning (Terraform)	Reusable scan steps on all three CI	/scans
SonarQube (optional)	Code quality + SAST	Per-tenant webhook into the portal	/scans
Snyk (optional)	SCA / container	Per-tenant API key + webhook	/vulnerabilities
Wiz (optional)	Cloud posture	Per-tenant API key + nightly CronJob ingest	/scans
GitGuardian (optional)	Secret scanning	Per-tenant API key + webhook	/scans
CycloneDX	SBOM format	Generated in build step, attested to the Evidence Vault + attached to CR	/sbom
ArgoCD	GitOps controller	Pipeline updates gitops/ image tag; ArgoCD syncs	/argocd, /clusters
Kyverno	Policy gate	ArgoCD PreSync hook	/policies
Tekton (optional)	In-cluster pipelines	Per-tenant cluster wiring	/tekton
AWS Cost Explorer / Azure Cost Mgmt / GCP Billing	Cloud cost	Nightly CronJob ingest per cloud	/costs, /costs/chargeback
M365 / Google Calendar	Change windows	Bidirectional sync (CalendarSyncConfig + CalendarEventMapping)	/change-windows
GitLab Issues / GitHub Issues / ADO Work Items	Issue tracking	3-way broker (scripts/issue-sync/)	/issue-sync
Multi-provider LLM (Anthropic / Azure OpenAI / Bedrock / Vertex / on-prem)	AI for AskAI + agent recipes	Per-tenant key + provider selection	/settings/ai, AskAI popovers

The glue, in one diagram

⛶ Fullscreen

flowchart TD
  GL["GitLab CI"]
  GH["GitHub Actions"]
  ADO["Azure DevOps"]
  GATES["Shared compliance gates"]
  FIDES["Evidence Vault / Fides<br/>evidence ground truth"]
  PORTAL["SARC portal (karc-portal)<br/>composes Fides + ServiceNow<br/>computes 5-axis risk score<br/>enriches CRs · exports evidence"]
  SNOW["ServiceNow<br/>CRs + CMDB + tables"]
  ARGO["ArgoCD<br/>deploys per cloud"]
  CLOUD["AWS / Azure / GCP<br/>clouds · costs · cluster state"]

  GL --> GATES
  GH --> GATES
  ADO --> GATES
  GATES -->|"per-job: attest -&gt; Evidence Vault / Fides flow karc-pipeline"| FIDES
  FIDES -->|"webhook + CronJob"| PORTAL
  PORTAL --> SNOW
  PORTAL --> ARGO
  PORTAL --> CLOUD

  class GL,GH,ADO ci
  class GATES gate
  class FIDES fides
  class PORTAL portal
  class SNOW snow
  class ARGO argo
  class CLOUD cloud

  classDef ci fill:#1f6feb,stroke:#0b3d91,color:#ffffff
  classDef gate fill:#57606a,stroke:#32383f,color:#ffffff
  classDef fides fill:#2da44e,stroke:#116329,color:#ffffff
  classDef portal fill:#8957e5,stroke:#512a8f,color:#ffffff
  classDef snow fill:#d29922,stroke:#8a6500,color:#ffffff
  classDef argo fill:#e8590c,stroke:#9a3b08,color:#ffffff
  classDef cloud fill:#1b7c83,stroke:#0f4a4e,color:#ffffff

Where to go next

• Architecture — the system-shape view that frames why the integration looks like this
• Full pipeline action map — every stage and action, step by step, with the AI-agent intervention points
• Multi-cloud parity — how the TARGET_CLOUD switch keeps the same pipeline working on AWS / Azure / GCP / k3d
• Multi-CI parity — what’s identical and what’s per-platform across GitLab / GitHub / ADO
• Compliance frameworks — how the resulting evidence rolls up per framework
• Portal — what an operator actually sees on top of this pipeline

For implementation specifics

The exact pipeline templates, secret schemas, Evidence Vault (Fides) flow/trail names, ServiceNow OAuth wiring, and per-tenant configuration knobs are part of the engagement deliverable. This page deliberately stops at the architecture so the public site does not double as a copy-paste install guide.