In June 2025, gittuf was promoted from OpenSSF Sandbox to Incubating status under the Supply Chain Integrity Working Group. The graduation moved gittuf from a research-grade prototype to a project the OpenSSF formally backs for cross-industry adoption, which matters because gittuf occupies a unique architectural niche: it is a Git security layer that does not depend on a specific forge — GitHub, GitLab, Bitbucket, Gitea — to enforce or verify its security policy. That property is what makes gittuf a credible path to SLSA Source Level 3, which (as of SLSA v1.2 in November 2025) requires continuous enforcement of declared technical controls that the verifier can validate without trusting the source platform.
What problem is gittuf actually solving?
Traditional Git security relies on the forge as the single point of trust. When a maintainer enables "require code review" and "require signed commits" on a GitHub branch, the enforcement and the audit trail live entirely inside GitHub. If GitHub is compromised, misconfigured, or coerced — and the supply chain attack literature is full of all three — the security claim collapses. A consumer of the repository has no way to independently verify that the declared policy was enforced for every commit in the history they are pulling. gittuf addresses this by lifting policy declaration and enforcement records into the Git repository itself, in a structure that travels with every clone and that any third party can verify without contacting the forge.
What is the Reference State Log?
The Reference State Log (RSL) is gittuf's central data structure. It is a sequence of signed entries — stored in a dedicated refs/gittuf/reference-state-log Git reference — that records every change to every protected branch and tag in the repository, together with the keys authorized to make those changes. An RSL entry looks like:
RSL Entry: 7c4f1...
Reference: refs/heads/main
Target: a9c3d... (commit hash)
Number: 4821
Signed-by: gpg:ABC123DEF456...
Timestamp: 2025-07-08T12:14:00Z
When a developer pushes a new commit to main, gittuf creates a new RSL entry that binds the branch reference to the new commit hash and is signed by an authorized key. The chain of RSL entries forms an append-only audit log that a verifier can replay to confirm that every transition on a protected branch was authorized. Critically, because the RSL is itself a Git reference, it is fetched along with the rest of the repository — a consumer who clones a gittuf-protected repo automatically has the audit log.
How is policy expressed?
gittuf adopts the role-and-delegation model from The Update Framework (TUF), the upstream project that gives gittuf its naming inheritance. The repository has a root role whose public keys are baked into the initial policy; root delegates to targets roles that declare which keys are authorized to sign for which protected refs. A minimal policy might say:
[roles.root]
keyids = ["abc123...", "def456..."]
threshold = 2
[roles."targets/main"]
keyids = ["dev1pub...", "dev2pub...", "dev3pub..."]
threshold = 2
paths = ["refs/heads/main"]
[roles."targets/releases"]
keyids = ["release-eng-pub..."]
threshold = 1
paths = ["refs/tags/v*"]
The threshold parameter requires a configurable minimum number of signatures from authorized keys. A threshold = 2 on the main role means two distinct maintainers must sign off on every commit to main, enforced cryptographically rather than by forge-side branch protection. The policy is itself stored in the repository and rotated through standard TUF role-rotation procedures.
How does this integrate with SLSA v1.2?
SLSA v1.2's Source Track Level 3 requires that declared technical controls be continuously enforced and that enforcement be attested in a way a third-party verifier can check without trusting the source platform. gittuf is the cleanest path to that requirement for OSS projects, because the RSL is the technical enforcement record and a verifier can read it directly from the cloned repository. Building a Source VSA from gittuf state is mechanical:
gittuf verify-ref refs/tags/v1.4.0
# Verifies the RSL chain to the commit pointed to by v1.4.0
# Returns OK with the policy version and signatures observed
# Emit a SLSA Source VSA
gittuf attest source-vsa --tag v1.4.0 --level SLSA_SOURCE_LEVEL_3 \
--output vsa.json
The emitted VSA carries the same https://slsa.dev/verification_summary/v1 predicate type as a build VSA and can be ingested by any SLSA-aware verifier.
What about non-OSS workflows?
gittuf is forge-agnostic, but it is also workflow-agnostic. A regulated enterprise that mirrors public OSS into an internal Bitbucket and applies its own review policy can layer gittuf on top of the internal mirror, generating an independent RSL whose root keys are held by the enterprise security team. The same gittuf verification flow works against an internal repository, producing the same Source VSA. This is the architectural property that makes gittuf attractive to FedRAMP and EU CRA programs: the verification does not depend on a forge that may be outside the program's accreditation boundary.
What is the current production-readiness?
As of mid-2025, gittuf is in beta. The CLI is functional, the RSL semantics are stable, and several reference deployments — primarily inside CNCF projects and academic research projects — are publishing RSL data continuously. The main rough edges are tooling integration: most CI providers do not yet have native gittuf signing actions, and GUI clients do not visualize the RSL. The OpenSSF Incubating graduation comes with an expectation of 1.0 stability work through 2025 and into 2026, with explicit production-readiness milestones tracked in the project's roadmap.
How Safeguard Helps
Safeguard ingests gittuf RSL data and Source VSAs as first-class evidence in the supply chain graph. Customers using gittuf to reach SLSA Source L3 can publish their RSL entries to Safeguard, which links them to the build attestations and downstream SBOMs that consumed the source revision — giving consumers a single, queryable view from source policy to deployed artifact. Policy gates can require a valid gittuf Source VSA at a specific level on any component crossing a regulated tier; FedRAMP-aligned products can block ingestion of source revisions whose RSL is missing or whose signature threshold is below the policy minimum. Griffin AI answers natural-language questions like "show me every protected branch in our org that fell out of RSL coverage in the last week" so security teams catch coverage gaps before they become audit findings.