saksi

Every software release nowadays carries an implicit trust assumption: that the artifact you just deployed wasn't tampered with somewhere between a developer's laptop and your production cluster. High-profile supply chain attacks like the SolarWinds incident and the CodeCov breach exposed the fragility of that trust. Logging alone can't protect you - an attacker with sufficient access can sanitize logs - rewrite history, and vanish without a trace. The industry needs something stronger: a witness that can't be silenced. Saksi doesn't just log events - it creates tamper-proof, independently verifiable witnesses that can survive even a repository compromise.

We built Saksi as an open-source toolkit after watching too many incident postmortems end with "we're not sure exactly what happened because the logs were incomplete. " In production environments, we found that traditional CI/CD audit logs failed to capture the critical linkage between what a developer intended, what the pipeline actually built. And what got deployed. Saksi fills that gap by generating cryptographically signed attestations at every decision point, turning each pipeline step into a durable witness that can be verified offline. If you're running a mobile CI/CD pipeline that produces artifacts for the Google Play Store or Apple App Store, this changes everything - and we'll explain how.

In this post, I'll walk through the architecture, the cryptographic underpinnings, real production lessons and how you can integrate Saksi into a GitHub Actions or GitLab CI workflow today. Whether you're aiming for SLSA Level 3 compliance or just want to know your build artifacts haven't been silently replaced, a proper witnessing system moves you from "trust but verify" to "verify, then trust. "

Why Traditional CI/CD Logging Falls Short as a Witness

Most teams rely on stdout, CI platform webhooks. And artifact storage logs for forensics. The problem is that all of those sources are mutable if an attacker compromises the CI runner or the storage backend. A malicious actor who gains access to your pipeline's service account can delete log entries, overwrite S3 objects. Or even retroactively modify build metadata. We saw this firsthand when a compromised GitHub personal access token allowed an outsider to push a backdoored APK that passed all existing checks because the deployment log was cleanly removed from the build service.

Logging frameworks like Fluentd, Loki, or CloudWatch provide aggregation and search. But they weren't designed to offer non-repudiation. Even with append-only integrity controls, the log producer itself is co-located with the process under attack. That's like letting the suspect write the police report. To establish a trustworthy witness, you need attestations that are generated in-process but verified out-of-band, using public-key cryptography so that no single machine can forge or delete a witness once it has been produced.

That's the fundamental shift Saksi introduces: every pipeline event that matters - code checkout, dependency resolution, compilation, signing, artifact upload - produces an immutable, signed statement of fact. These statements are published to a transparency log (a la Certificate Transparency), making it impossible to alter history without detection. We'll dissect that mechanism shortly.

What Saksi Actually Is-and Isn't

Saksi isn't a logging aggregator? It's a witnessing toolkit that integrates into your existing pipeline jobs to generate in-toto link attestations, wrapped with Sigstore-based keyless signing. And optionally stored in a Rekor transparency log. The name, taken from the Filipino word for "witness," reflects its role: it bears testimony to the exact sequence of operations that produced an artifact and anyone can cross-examine that testimony without trusting the original infrastructure.

The toolkit ships as a lightweight binary (written in Rust for minimal footprint) and a set of GitHub Actions, Jenkins shared-library steps. And a GitLab CI template. Under the hood, in-toto defines the supply chain layout - a verifiable description of the steps and the authorized functionaries - while the signing layer uses Sigstore for short-lived ephemeral certificates bound to OIDC identities. The result is that a witness statement contains not only what happened but also exactly which identity (e g., a GitHub Actions workflow ref) executed it, with a signature that's verifiable against the public Fulcio CA.

A common misconception is to equate Saksi with a binary authorization system. While you can certainly gate deployments based on valid witnesses, the core mission is forensic integrity: ensuring that if something bad happens, you can reconstruct the chain of custody with cryptographic certainty that's a crucial nuance, especially for heavily regulated mobile apps where proving compliance to SOC 2 or GDPR can hinge on a single piece of evidence.

How Saksi Fits into a Mobile CI/CD Pipeline

Let's ground this in a concrete flow. Imagine a React Native app built with GitHub Actions. The pipeline checks out code, runs npm install, compiles the Android APK, signs it with Google Play App Signing. And uploads to Firebase App Distribution. Without Saksi, the only record that "npm install" ran at commit abc123 with dependency tree X is a line in the workflow log. With Saksi, the npm install step creates a witness that records the SHA256 of the resulting node_modules directory, the exact command invoked, the OIDC token of the action, and a timestamp. That witness is signed and pushed to the transparency log.

When the build step produces an APK, Saksi creates another witness that links the artifact hash back to the dependency witness. This creates a chain: code → dependencies → compiled artifact. For iOS pipelines, the same principle applies - the Xcode archive step generates a witness that captures the provisioning profile's UUID and the derived data digest. For teams publishing to the App Store, you can even attach a witness to the notarization submission, ensuring the artifact you submitted matches what the pipeline built.

This approach is especially powerful in mobile contexts because the final artifact is often shipped to end-user devices where you lose all control. A Saksi witness bundle acts as your warranty: you can prove to regulators or security researchers that the APK on a device corresponds exactly to a known, attested build. We've used this in post-incident analyses for clients who discovered malicious code; the witnesses allowed them to pinpoint the exact commit and build number where the compromise was introduced, reducing mean-time-to-remediate from days to hours.

The Cryptography Behind a Saksi Witness

Each Saksi witness is an envelope containing three layers: the subject (a hash of the file, container image, or in-memory state), the predicate (a typed claim about the subject, following the in-toto attestation spec), and a DSSE (Dead Simple Signing Envelope) wrapper. The signing key is generated ephemerally using Sigstore's Fulcio OIDC flow. So no long-lived secrets need to be managed by the pipeline.

Fulcio checks the OIDC token from your CI provider (e, and g, a GitHub token with the repo and workflow claims) and issues a short-lived X. 509 certificate bound to that identity. The private key never leaves the runner and is discarded after signing. The resulting signature, certificate, and attestation are then written to the Rekor transparency log. Which returns an inclusion proof. That proof, along with the attestation, becomes the complete witness bundle you store alongside your artifact or in a separate attestation registry like Rekor's public instanceAnyone can verify the witness Using the Sigstore tooling without needing the original runner's keys.

One design decision we made early was to avoid custom formats. Saksi uses the in-toto specification (RFC-style layout) and Sigstore's standard bundles, so verification doesn't require Saksi at all - you can use cosign or the in-toto Python reference implementation. This avoids tooling lock-in and keeps the witness verifiable long after the pipeline has been decommissioned. In a mobile ecosystem. Where release cycles span years, that portability is vital.

How to Create an Immutable Witness Chain

A single witness is useful. But the real power comes from linking them into a verifiable supply chain layout. Saksi uses in-toto's layout metadata to define the expected steps, their material inputs. And outputs. For example, a layout may specify that the "compile" step must accept materials with hashes attested in the "dependency-resolution" witness, and produce an artifact whose hash matches the "artifact-upload" witness. Violating this layout breaks the chain and triggers a verification failure.

In practice, we define the layout as a YAML file checked into the repository, signed by a trusted admin. The CI job that generates the final witness bundle also fetches the layout and runs a verification pass. If any step is missing or a hash doesn't align, the job can block the release or flag the build for human review. This moves security left, catching misconfigurations (or insider threats) before they reach the App Store. For mobile builds distributed through TestFlight or internal tracks, the witness chain can also serve as proof that the QA team tested exactly the build that was attested.

We've seen teams get creative, extending the chain to include not just build steps but also infrastructure provisioning (Terraform applies) and even penetration test results. A witness for "pen-test completed on build ID X" can be linked to the artifact, creating an auditable trail from requirement to deployed binary. The schema is flexible because Saksi allows custom predicate types. Though we recommend sticking to the standard SLSA predicates for interoperability.

Verifying an Attestation: The Witness Validation Workflow

Verification is intentionally decoupled from the pipeline. A security engineer or a policy enforcement point (like OPA/Gatekeeper) can download the witness bundle and an artifact from any mirror, then run saksi verify --artifact --bundle witness json --layout root, and layoutThe CLI first verifies the Sigstore signature using Fulcio's CA certificate and checks the Rekor inclusion proof. It then extracts the subject digests from each attestation and compares them against the artifact's hash. Finally, it walks the layout to ensure all required steps are present and linked correctly.

If anything fails - a missing signature, a certificate issued outside its validity window, a hash mismatch - the CLI returns a non-zero exit code and a detailed error report. We've integrated this mechanism into our mobile CI/CD pipelines