Skip to content
SARC

Kosli integration — a fully independent governance lane

SARC proves it runs either compliance system for real, side by side. podtato-head is governed end-to-end by Fides; a second deployment, podtato-head-kosli (AWS), is governed end-to-end by Kosli — its own pipeline lane, its own namespaces, its own deploy gate, and its own ServiceNow change record. Same 6 images (a second deploy, not a second build). Kosli is no longer attached to the Fides pipeline — each service answers to exactly one system. Full mechanics: docs/ci/kosli-parallel.md.

What Kosli is

Section titled “What Kosli is”

Kosli is a SaaS binary-provenance / DevOps change-management system. Its model maps almost 1:1 onto Fides (which is why the migration was clean):

Kosli noun Meaning
Flow a delivery stream (≈ a service/repo). SARC uses one: karc-pipeline.
Trail one run of a flow (keyed by the Git commit SHA).
Artifact a built deliverable identified by its SHA256 fingerprint.
Attestation evidence about a trail/artifact (tests, scans, SBOM, deploy).
Environment a runtime you kosli snapshot and gate with a policy.

Gates are kosli assert artifact (against an environment policy) and the newer kosli evaluate trail (a Rego policy over a trail’s attestations).

What SARC does with Kosli today

Section titled “What SARC does with Kosli today”

Shipped 2026-09. GitLab-only, driven by scripts/ci/kosli-attest.sh + .gitlab/ci/templates/kosli-attest.yml (the Kosli sibling of the Fides templates). Backend: flow karc-pipeline, org Calitii, host app.kosli.com, 12 environments ({aws,azure,gcp,local}-karc-{dev,qa,prod}). CLI v2.16.0, curl-installed into an alpine job (the image ships no binary).

Job (all allow_failure) Stage Kosli command
kosli:begin:trail attest kosli begin trail <sha> --flow karc-pipeline
kosli:attest:artifact:podtato (6-cell matrix) attest kosli attest artifact <img> --artifact-type oci --fingerprint <sha256>
kosli:attest:policy:aliases (8-cell matrix) attest kosli attest generic --name <control> --compliant=true [--attachments <report>]
kosli:attest:deploy:{dev,qa,prod} deploy-* kosli attest generic --name deployment-<env> --compliant=true
kosli:assert:qa deploy-qa kosli assert artifact — advisory (|| echo …)

Every job skips cleanly when KOSLI_API_TOKEN is unset, so a Kosli outage never blocks the Fides-gated pipeline. The 8 policy:aliases names (sast-semgrep-scan, secret-detection-scan, dependency-scan-gemnasium, container-scan-grype, iac-scan-terraform, k8s-manifest-scan, sbom-cyclonedx, pipeline-validation) match the flow template exactly — which is what makes the trail COMPLIANT. See docs/ci/kosli-parallel.md.

Are we doing the right thing with Kosli?

Section titled “Are we doing the right thing with Kosli?”

What is correct (matches Kosli’s documented best practice):

  • Image attestation by digest without a Docker daemon — kosli attest artifact --artifact-type oci --fingerprint <sha256> is exactly the pattern Kosli recommends for CI. We resolve the digest from the GitLab registry API, so no daemon or pull is needed.
  • Trail keyed on the commit SHA, one flow, attestation names matching the flow template so compliance is real, not cosmetic.
  • allow_failure + skip-when-unconfigured — Kosli is a parallel demo, never a blocker.

Deliberate scope (attestation-only, by design): Fides holds the authoritative gate, so Kosli intentionally does not run a change/deploy gate, cosign/SLSA supply-chain, a kosli snapshot k8s runtime reporter, or verify-chain. That’s a correct choice for a Fides-primary platform — but it means the Kosli trail is evidence, not enforcement, here.

Honest weaknesses (worth fixing if Kosli should ever decide, not just record):

  • The kosli:attest:deploy:* and kosli:assert:qa jobs use placeholder fingerprints (an all-zeros digest; the git SHA in the assert). So the advisory assert can never match a real artifact — it’s decorative. To make Kosli a real gate, feed the assert the same registry-resolved image digest the artifact job already computes, and attach an environment policy.
  • Tests go through kosli attest generic rather than the idiomatic kosli attest junit (which auto-parses JUnit XML). Low priority, but junit is the richer path.
  • The artifact attestation omits --repo-url/--commit-url/--build-url, so the Kosli provenance links back to Git/CI less richly than it could.

Kosli and ServiceNow

Section titled “Kosli and ServiceNow”

Kosli has a ServiceNow integration — listed under ITSM on kosli.com/integrations. It surfaces audit-ready evidence inside a ServiceNow change request (an “Evidence tab powered by Kosli”: the commit, the pipeline run, and the results of required tests/scans), so approvers see real evidence instead of pasted build IDs and screenshots.

SARC does not use it. In our platform, ServiceNow change requests and their evidence come from the Fides path (servicenow-cr.sh, servicenow-fides-sync.sh → the u_fides_* tables and the DevOps change spine); Kosli only attests to its own flow. Kosli and ServiceNow are entirely separate paths — no Kosli↔ServiceNow wiring exists in the pipeline.

Is that right? For a Fides-primary platform, yes — we deliberately made Fides the single ServiceNow evidence source and change-gate, and Kosli runs parallel purely to prove “the same build also satisfies Kosli.” We are not misusing Kosli’s ServiceNow integration; we are not using it, by design. For a customer who standardises on Kosli (and not Fides), the right move is to enable Kosli’s own ServiceNow integration so Kosli evidence lands on the CR — replacing, not duplicating, the Fides→ServiceNow path. That’s a supported future option, not a gap in correctness.

Summary

Section titled “Summary”
Fides (primary) Kosli (parallel)
Attestations Yes Yes
Change / deploy gate Yes (fides-change-gate, promote.sh) Advisory assert only
Supply chain (cosign/SLSA) Yes No
Runtime snapshot Yes (reporter) No
ServiceNow evidence + CR Yes (servicenow-fides-sync) Not wired (Kosli’s own SN integration available if needed)

Kosli today is correct as an attestation-parallel demo and uses the CLI the right way; it is not wired as a gate or to ServiceNow, which is the intended design while Fides is primary.

Sources

Section titled “Sources”