Presenters

Source

🛡️ Beyond the Green Checkmark: Securing Source Code with git-tough

Source code serves as the foundation of our digital world, yet it remains an ideal target for attackers. We often trust the platforms where we host our code, but what happens when that trust is misplaced? At a recent tech talk, Justin Cappos (creator of TUF and in-toto) and Yongjae Chung (Master’s student and contributor) introduced git-tough, an incubating project under the OpenSSF designed to bring industrial-grade security directly into your Git workflow.

🔓 The Vulnerability of the Status Quo

Justin kicks things off with a sobering reality check: source code is far more vulnerable than most developers realize. While we rely on “forges” like GitHub or GitLab to protect our repositories, these platforms represent a single point of failure.

The Limits of Standard Git 💾

Git provides some built-in security, such as SHA-1 or SHA-256 Merkle trees to ensure file integrity. However, Justin points out significant gaps:

  • Key Distribution: While you can sign commits, Git has no native way to tell a client which keys it should trust.
  • Forge Dependency: Users currently rely on the forge to verify signatures and enforce policies (like “two-person review”). If an attacker bypasses the forge’s security, everyone downstream unknowingly pulls malicious code.
  • Historical Precedents: From the NSA allegedly backdooring Juniper VPN software to the Codecov and Trivia attacks, history shows that repository manipulation is a favorite tactic for high-level adversaries.

🚀 Introducing git-tough: Security That Travels With Your Code

git-tough acts as a decentralized security layer that lives inside your repository. Instead of trusting a central server to validate changes, every developer’s client can verify the repository’s state independently. 🌐

How It Works 🛠️

Yongjae explains that git-tough distributes metadata alongside your code. This metadata includes:

  1. Root Metadata: Signed by core owners, this establishes the root of trust for the entire project.
  2. Primary Rule File: This contains the access control rules. It defines exactly who can write to specific branches, tags, or even individual folders.
  3. Reference State Log (RSL): An append-only hash chain that records every change, push, and approval. Because every developer has a copy of the RSL, any tampering becomes immediately visible during synchronization.

🏗️ The Architecture of Trust

The power of git-tough lies in its flexible and granular policy engine. 🦾

Thresholds and Delegations 🎯

  • Thresholding: You can require a minimum number of signatures (e.g., n=2) before a change is considered valid. This prevents a single rogue maintainer or a compromised account from wreaking havoc.
  • Delegations: Maintainers can delegate trust for specific namespaces. For example, the core team can grant the Cryptography Team exclusive rights to the /signatures package. Alice can delegate her permissions to Bob, but she cannot grant Bob more access than she personally holds.

Identity Integration 🆔

Git-tough doesn’t just rely on SSH keys. It supports modern identity solutions like Sigstore and OIDC providers, allowing teams to link repository permissions to verified organizational identities.

💻 git-tough in Action: A Hello World Demo

Yongjae demonstrated how seamless the tool is for daily use. By using a custom Git remote helper (the git-tough transport), the security checks happen automatically in the background.

  • Setup: A simple initialization command sets the maintainer as the root of trust and defines the initial branch protection rules.
  • Validation: When a developer pushes a commit with an authorized key, git-tough records the entry in the RSL and marks it as successful.
  • Detection: In the demo, Yongjae simulated an attack by switching to an unauthorized signing key. When he attempted to verify the state, git-tough immediately flagged a policy violation, stopping the malicious change in its tracks. ❌

❓ Deep Dive: Questions and Answers

During the session, the audience raised several critical points about implementation and edge cases:

Q: Where exactly are these policies stored? Justin: We store them in the git refs area of the repository. This is a common technique where the data is “invisible” to standard Git users but accessible to git-tough clients. It gets pushed to the forge just like any other data, but it stays out of your main file tree.

Q: What stops an attacker from simply pushing malicious data to those hidden refs? Justin: Any git-tough client that has already been set up will notice the discrepancy. If an attacker tries to overwrite the RSL or the policy files, the client will detect the tampering and can even revert the state to the last known good version.

Q: How do you safely onboard a new repository owner if you only have one currently? Justin: Bootstrapping is a fundamental security challenge. In git-tough, the initial push establishes the root. While the “first trust” is always a hurdle in any system (like pre-loaded CAs in an OS), git-tough ensures that once trust is established, it cannot be unilaterally broken.

🌟 Conclusion: Join the Movement

Git-tough is currently an incubating project with contributors from 4 to 5 different organizations. It is designed to be compatible with all major forges and works seamlessly alongside developers who may not have the tool installed yet.

By moving security checks from the forge to the client, git-tough ensures that integrity and policy compliance are baked into the code itself, not just the platform hosting it.

Ready to make your repository “tough”? Check out the project on GitHub and start securing your source code today! 👾💾📡

Appendix