gittens

The gittens pattern turns every Git commit into a tamper-evident, queryable event that your CI/CD pipeline, observability stack. And compliance tooling can agree on. It isn't a product you buy it's a design contract: treat the commit graph as the single source of truth for what changed, who authorized it, and where it ran. In production environments, we found that teams who adopt gittens spend less time reconciling deployment logs with audit spreadsheets and more time shipping code that can prove its own lineage.

The idea is simple on the surface and subtle underneath. A Git commit is already a content-addressed object. Its SHA identifies the exact tree, parent, author. And message at a point in time. Most engineering organizations treat that object as a bookmark for code review, then throw the metadata away once the container image ships. The gittens approach keeps the commit alive as a first-class artifact. Deployments, security scans - feature flags, and incident notes all anchor back to a commit hash. The result is an immutable backbone for the software supply chain.

This article explains the architecture of gittens, where it helps, where it breaks. And how to introduce it without replacing the tools you already use. We will look at Git internals, signing strategies, CI/CD patterns,, and and compliance automationBy the end, you should be able to decide whether gittens is worth a pilot in your own repositories.

Why Git Objects Form a Natural Audit Log

Git stores four object types: blobs, trees, commits, and tags. A commit object contains a pointer to a tree, one or more parent commit hashes, author and committer metadata. And a message. Because the SHA-1 (or SHA-256, since Git 2. 42) is computed over all of those fields, changing a single character changes the hash. That property makes commits an excellent primitive for audit logs. Once a commit is pushed and referenced, any rewrite-whether accidental or malicious-produces a new object with a new identity.

In practice, this means a gittens-based system can answer questions that normally require stitching together GitHub, Jenkins, Artifactory, Kubernetes. And a SIEM. Which artifact ran in production at 2:00 a m last Tuesday? Trace the running container back to its build provenance record, then to the commit hash, then to the pull request and the signed merge event. The commit graph becomes a linked list of truth. Teams using Git commit internals as a ledger tell us the biggest win isn't the hash itself; it's the social contract that the hash must exist before anything else is allowed to proceed.

There is a caveat. Git is a distributed version control system, not a database it's eventually consistent in the sense that repositories can be forked, rebased, and force-pushed. Gittens works best when the authoritative repository is protected by branch rules, required reviews. And signed commits. Without those guardrails, the audit log loses its immutability and the pattern collapses into folklore.

Mapping the Gittens Lifecycle in CI/CD

A gittens lifecycle has four phases: creation, attestation, promotion. And retirement. Creation is the commit. Attestation is the evidence collected about that commit: tests, static analysis, dependency scans,, and and build outputsPromotion is the decision to move the commit through environments. Retirement is the deprecation of the artifact, ideally with a final signed tag or tombstone commit. Each phase produces metadata that references the original commit hash.

We implemented this in a Go monorepo using GitHub Actions and Sigstore. Every pull request triggered a workflow that built the binary, ran go test -race, scanned with govulncheck. And produced an in-toto attestation signed with Cosign. The attestation included the commit SHA as a subject. When the image reached production, our admission controller verified the attestation before allowing the pod to start. The key design decision was that the commit, not the container tag, became the primary identifier. Container tags are mutable; commit hashes are not internal link: guide to CI/CD pipeline security

This approach changes how you think about rollbacks. In a gittens system, a rollback isn't "deploy the previous Docker tag. " it's "check out the previous commit and promote it through the same attestation path. " That extra step feels like overhead until you need to prove to a regulator exactly what ran before and after the change. Then the overhead becomes the feature. The SLSA framework describes similar provenance requirements, and gittens can be a lightweight on-ramp to SLSA Level 2 or 3 compliance.

Securing the Gittens Boundary with Signatures

Immutability is useless if anyone can impersonate the author. Gittens relies on commit signing to bind identity to the hash. Git supports GPG, SSH, and X. And 509 signingGitHub and GitLab both surface signature status in their APIs. For automation, you can use Sigstore keyless signing with identity federation. The important part is that every transition in the lifecycle-commit, merge, tag, attestation, promotion-is signed by an identifiable actor or service account.

We learned this the hard way on a client project. The team had beautiful commit messages and a strict branch protection rule. But they allowed unsigned merge commits from the CI bot. An attacker who compromised the bot token could have introduced arbitrary code without a traceable signature. We fixed it by requiring SSH signatures for human commits and Sigstore Fulcio-issued certificates for CI attestations. The verification policy lived in a . And gittens-policyyaml file at the repo root, consumed by both the CI linter and the admission controller.

Signing also enables timestamping, and a signed commit proves identity and content,But not when the signature was created. For long-term auditability, consider adding RFC 3161 timestamps to your tags and attestations. This matters when certificates expire or keys are rotated. A verifier can still say, "Yes, this signature was valid at the time the commit was made. " that's the difference between a useful gittens record and a cryptographic dead end.

Building Observability Around Commit Events

Most observability systems identify workloads by deployment name, image tag, or pod label. Those labels lie. Images get retagged, and config maps changeLabels are overwritten. And a gittens-native observability setup uses the commit hash as a stable dimension. Every log line, metric, and trace carries a commit_sha attribute. When an alert fires, the first question is no longer "What version is running? " because the answer is in every event.

We instrumented a Python service with OpenTelemetry and added a resource attribute populated from an environment variable injected at build time. The build process wrote COMMIT_SHA into the image during the CI stage. In Grafana, we could split latency and error rate graphs by commit. When a canary deployment showed elevated p99 latency, we correlated it directly with the diff between the baseline commit and the canary commit. The mean time to identify the offending change dropped from roughly forty minutes to under five internal link: OpenTelemetry instrumentation patterns

The technique scales best when your observability backend supports high-cardinality groupings. Some older metrics systems choke on thousands of unique commit hashes. In those cases, keep the commit hash in logs and traces. And use a shorter release identifier in metrics. The gittens principle isn't "put the hash everywhere. " it's "make the hash discoverable from every signal. "

Compliance Automation Through Commit Metadata

Regulatory frameworks like SOC 2, ISO 27001, and FedRAMP all ask the same uncomfortable question: can you show what changed, who approved it, and whether it was tested? Gittens makes that question answerable by design. Commit messages, pull request metadata - CI results. And deployment events all share a common key. A compliance query becomes a join across tables indexed by commit SHA.

We built a small internal tool called gittens-audit that walks the commit graph and emits a JSON report for any date range. It collects signed commit data from the Git server, workflow run results from the CI API, attestation records from Rekor. And deployment events from the cluster. The report includes a row per commit with fields for author, reviewer - test status, vulnerability scan summary, and production promotion time. Auditors loved it because they could verify the raw data themselves instead of trusting a screenshot.

The policy layer is where this gets interesting. You can encode rules such as "a commit may not reach production unless it has two approving reviews, a passing CI run, and no critical vulnerabilities. " Those rules are enforced in CI, in admission control. And in the audit query itself. If a commit violates policy, the report flags it. There is no separate compliance database to maintain because the commit graph is the database. This reduces drift between "what we say we do" and "what the system actually enforces. "

Scaling Gittens Across Distributed Repositories

Large organizations rarely have one repository. They have dozens or hundreds. Each repo may use different CI systems, different registries,, and and different deployment platformsGittens scales by federation: each repository maintains its own commit graph and attestations. While a central catalog indexes commit hashes to organizational metadata such as service owner, data classification. And deployment environment.

We used a simple approach, and every repo pushed a signed provenancejson artifact to an S3 bucket organized by commit prefix. A scheduled Lambda read the artifacts and upserted rows into a PostgreSQL catalog. The catalog did not store source code or build outputs, and it only stored referencesThis kept the central system small and left each team in control of its own Git history. Queries across services were fast because the index was flat and the heavy data stayed in object storage.

Federation introduces trust boundaries. A rogue repository could push fake provenance records if the catalog accepts them blindly. We solved this by requiring each provenance artifact to be signed by a known CI workload identity. The catalog verified the signature and matched the issuer against a registry of approved repositories. This is similar to how package ecosystems verify publisher identity. Without that verification step, gittens becomes a gossip protocol.

Common Anti-Patterns That Break the Model

Gittens fails when teams treat it as a naming convention rather than a system. One anti-pattern is the "hash in the tag" approach: myapp:v1, and 23-abc1234. The tag is mutable. A malicious actor can retag a different image with the same string. The commit hash becomes decoration instead of evidence. Gittens requires verification at the point of use, not just decoration at build time.

Another anti-pattern is rebasing history after merge. Rebasing is fine for feature branches. But once a commit has been attested or deployed, rewriting it destroys the chain of evidence. We saw a team run git rebase on their main branch to "clean up history," which invalidated every production attestation from the previous quarter. The lesson: protect your default branch from force pushes and treat deployed commits as immutable.

A third anti-pattern is overloading the commit message. Gittens doesn't mean "put every ticket number, JIRA link, and compliance note in the commit message. " That makes history unreadable and encourages developers to game the format. Keep commit messages concise. Put structured metadata in attestation files, Git notes. Or a separate provenance store. The commit message is for humans; the attestation is for machines.

Implementing Gittens in Existing Toolchains

You don't need a greenfield project to use gittens. Start with one repository and one pipeline. Enable branch protection, require signed commits. And add a CI step that emits a provenance artifact referencing the commit SHA, and store the artifact somewhere durableThen add a single verification step at deploy time. And that's the minimum viable gittens implementation

From there, expand the surface area. Add OpenTelemetry resource attributes, since connect the commit hash to incident management tickets, and export audit reports for complianceEach increment adds value without requiring a big-bang migration. We found that teams adopt the pattern fastest when it reduces their existing pain-usually incident investigation or audit preparation-rather than when it's framed as a security initiative.

Tooling matters but shouldn't become the goal. Git, GitHub or GitLab, any CI system, Cosign or GPG. And a simple object store are enough to start. Avoid proprietary "gittens platforms" unless they solve a specific integration problem you can't solve with open standards. The strength of the pattern is its portability. Lock yourself into a vendor and you trade one audit headache for another.

Frequently Asked Questions

What exactly does "gittens" mean?

Gittens is a pattern, not a standard specification, that treats Git commits as immutable audit events for the software supply chain. It uses commit hashes as the canonical identifier linking code changes, build attestations, deployments. And compliance records.

Is gittens compatible with rebasing workflows,

Rebasing is fine on feature branches,But gittens requires that deployed or attested commits remain immutable. Once a commit has entered the attestation or promotion phase, rewriting history invalidates the chain of evidence. Protect your default branch accordingly.

Do I need Sigstore to add gittens?

No. Sigstore and keyless signing are convenient, but you can use GPG, SSH, or X, and 509 certificatesThe requirement is that transitions in the lifecycle are signed by identifiable actors or workload identities. And that signatures are verifiable at the point of use.

How does gittens help with compliance audits?

Gittens makes compliance queries joinable by commit SHA. Author, reviewer, test results, vulnerability scans. And deployment events all share the same key. This eliminates manual reconciliation and gives auditors a verifiable trail back to the original change.

Can gittens scale to hundreds of repositories?

Yes, through federation. Each repository maintains its own commit graph and attestations. While a central catalog indexes commit hashes to organizational metadata. The key is verifying the identity of each repository's CI system before accepting its provenance records.

Conclusion: Start With One Immutable Commit

Gittens isn't about adding process for its own sake it's about making the work you already do-commits, reviews, builds, deployments-more trustworthy and more queryable. The commit graph is one of the most underused assets in modern software engineering. When you treat it as a ledger instead of a convenience, incident investigation, compliance,, and and supply chain security all get easier

The best way to start is small. Pick a service, protect its main branch, sign its commits, and attach one provenance artifact to its next deployment. Verify that artifact before the container starts. That single loop is the core of gittens. And everything else is optimization

If you're building mobile, cloud. Or platform engineering systems and want help designing a gittens-style supply chain for your team, reach out to our engineering group. We have implemented these patterns across fintech, healthcare, and media stacks. And we can help you avoid the anti-patterns that derail early adopters.

What do you think?

Would you trust a deployment pipeline that verifies every running artifact against a signed commit hash, or do you think the overhead outweighs the security benefit for most teams?

How should organizations balance the immutability requirements of gittens with developer-friendly practices like interactive rebase and squash merges?

What would it take for gittens-style provenance to become a default expectation in open-source package ecosystems, similar to how checksums are expected today?