Multi-CI architecture

SARC’s compliance pipeline runs on three CIs in parallel today. The customer adopts whichever they already own; no migration is required to deploy SARC.

Source-of-truth topology

GitLab.com/compliance-calitii/sarc        SOURCE OF TRUTH
        │
        │ (scheduled mirror, 2x/day)
        ▼
┌───────────────────────────┐         ┌────────────────────────────┐
│ GitHub: Freundcloud/SARC  │         │ Azure DevOps: olaffreund-  │
│ (full mirror)             │         │   0455/SARC/SARC (mirror)  │
└───────────────────────────┘         └────────────────────────────┘

GitLab is authoritative. Mirrors are force-pushed twice daily via scheduled jobs in .gitlab/ci/templates/mirror-sync.yml. Don’t commit directly to GitHub or ADO main — the next mirror push overwrites it.

Pipeline parity

The same compliance pipeline runs identically across all three CIs:

Stage	GitLab CI	GitHub Actions	Azure DevOps
Validate (yaml + shell + terraform + helm)	`.gitlab/ci/templates/validate-*.yml`	`.github/workflows/_reusable-validate.yml`	`ci/azuredevops/stages/validate.yml`
Build portal image	`build-portal.yml`	`_reusable-build-portal.yml`	`ci/azuredevops/stages/build.yml`
Build podtato image	`build-podtato.yml`	`_reusable-build-podtato.yml`	(Azure-only on ADO)
Security scans (SAST, SCA, container, secret, IaC)	`security-scans.yml`	`_reusable-security-scans.yml`	`security-native.yml` (MSDO + AdvSec)
Kosli attestations	`kosli-attest.yml`	`_reusable-kosli-attest.yml`	`ci/azuredevops/stages/kosli-attest.yml`
SBOM + license check	`sbom.yml`	`_reusable-sbom.yml`	(part of MSDO bundle)
ServiceNow CR enrichment	`servicenow-cr-enrich.yml`	`_reusable-servicenow-cr-enrich.yml`	`ci/azuredevops/stages/servicenow.yml`
Deploy (Helm)	`deploy-helm.yml`	`deploy-helm-{aws,azure,gcp}.yml`	`ci/azuredevops/stages/deploy.yml` (Azure-only)
Post-deploy Kosli report	`postsync-kosli-report.yml`	`_reusable-postsync-kosli-report.yml`	(via env Approvals + ServiceNow check)
DAST	`dast-podtato.yml`	`dast-postsync-qa.yml`	`dast.yml`

For each CI, the underlying shell scripts in scripts/ci/ (kosli-attest.sh, servicenow-cr.sh, gitops-bump-tag.sh, etc.) are the same. The CI-specific YAML is just orchestration on top.

CI scope per cloud

ADO is intentionally scoped to Azure only, podtato-head only — it’s parallel CI for Azure deploys, not a full CI replacement. GitLab handles everything (Source of truth + AWS deploys + Azure deploys + portal). GitHub Actions has full parity (every workflow GitLab has).

Per-cloud terraform ownership (current):

AWS terraform → GitLab CI runs it
Azure terraform → Azure DevOps runs it
GCP terraform → GitHub Actions runs it

This split mirrors which CI is most engaged for each cloud; in principle any CI could run any cloud’s Terraform.

Promotion pipeline

scripts/ci/promote.sh orchestrates dev → qa → prod promotion:

Generate release notes (HTML)
Compute Kosli risk score via scripts/ci/kosli-score.sh
Create ServiceNow CR with risk score + release notes
Enrich CR with SBOM + SARIF artifacts via scripts/ci/servicenow-cr-enrich.sh
Upload bulk attestations via scripts/ci/servicenow-upload-attestations.sh
qa: auto-approve if compliant; prod: manual approval only
Bump gitops image tag via scripts/ci/gitops-bump-tag.sh

This runs identically across GitLab + GitHub. ADO uses the same shell scripts wrapped in stage YAML.

Why GitLab is source of truth

Historical: SARC’s parent KARC was a GitLab-first project. Migrating that away would be expensive for no real gain. GitLab Premium also has the strongest compliance-framework feature (downstream compliance templates), which SARC’s customers use.

The mirror topology means the CHOICE of GitLab as source of truth is not visible to a customer who only uses GitHub or ADO — they get an identical experience.