For many regulated firms, contributing to open source is not simply a developer workflow challenge — it is a governance challenge. Engineering teams want to collaborate with upstream projects, while security, legal and compliance teams need confidence that sensitive information, vulnerable dependencies and unauthorised changes are not leaving the organisation unchecked.

Git Proxy helps solve that problem.

Git Proxy sits between developers and Git remote endpoints, applying configurable rules and approval workflows before code is pushed externally. It enables firms to support open source contribution while enforcing security, legal and compliance requirements.

Git Proxy is a FINOS Graduated project and is used in production by leading financial institutions including Citi, RBC, NatWest and G-Research. With Git Proxy v2.0, the project has taken a major step forward, adding support for Git-compatible hosts beyond GitHub, improved fork workflows, better performance, stronger documentation and an improved user experience.

If your organisation has not looked at Git Proxy before — or evaluated it previously and decided it was not ready — v2.0 is worth a fresh look.

How Git Proxy helps regulated firms contribute safely

Git Proxy makes it easier for firms to contribute to open source projects while meeting security, legal and compliance requirements. It gives them the power to:

• Automate compliance: Apply vulnerability, secret, licence and approval checks consistently to every push.
• Reduce developer friction: Allow engineers to contribute upstream through a governed workflow rather than blocking contributions outright.
• Control access: Define who can push, approve, and interact with specific repositories or remotes.
• Provide audit evidence: Capture intercepted Git operations and store them in your database of choice.
• Extend policy enforcement: Build plugins and processors for firm-specific legal, security or compliance requirements.

In highly regulated industries such as financial services, direct contribution to upstream projects is often restricted by default. Firms need to manage data loss prevention risks, prevent accidental secret leakage, and reduce the chance that compromised dependencies or tooling could expose sensitive infrastructure details.

On top of that, firms can implement their own policies in the form of plugins and processors to extend base Git Proxy behaviour, allowing them to cover requirements imposed by security and legal teams.

Why revisit Git Proxy now?

If your organisation looked at Git Proxy previously, v2.0 is worth another look. This release addresses several of the most common adoption blockers: support beyond GitHub, better handling of fork-based workflows, improved performance for large repositories, clearer documentation, stronger user experience, and continued investment in supply chain security.

Introducing Git Proxy v2.0

We’re thrilled to announce that Git Proxy v2.0 has shipped, with a major set of new capabilities including:

Support for hosts other than GitHub

Git Proxy started as a proxy for GitHub. Git Proxy v2 can now govern pushes to repositories hosted outside GitHub, including GitLab, Bitbucket and other Git-compatible remotes.

Support for multiple forks

In v1, forks couldn’t coexist with their upstream repository. This created friction for firms where the typical open-source workflow is to contribute to a shared internal fork or personal fork of a project rather than directly upstream. Now, multiple forks of the same repository can coexist along with the upstream repo, each with their own granular permissions.

Enhanced UX

Earlier versions of Git Proxy prioritized core governance capabilities over user experience. As adoption has grown, the maintainers have focused on making the product easier for developers, approvers and administrators to use. Today, Git Proxy v2 delivers a significantly improved user experience, and we’re working towards a comprehensive UI refresh to be released in the next few months.

Speed improvements

Users often need to contribute to large repositories, which may contain hundreds of megabytes or several gigabytes of code, artefacts, images and more. Git Proxy v1 wasn’t designed to handle these massive repositories - a git push to one of these used to take several minutes as each processor needed to pull the code, analyse the diff and perform other costly operations. In internal testing and production usage, these changes have reduced push times by approximately 50% in representative large-repository workflows.

Docs for Developers and Users

The maintainers have documented the Git Proxy architecture to help developers get started with the project and to support security assessors reviewing deployments. You can find this in the new architecture guide.

We have also written an essential user manual that adopting firms can refer users to or adapt for their own internal processes. As many participating Open Source Program Offices (OSPOs) have found, clear instructions are key to a good user experience, especially for first-time contributors who may be working with multiple Git remotes or providing a Developer Certificate of Origin (DCO) attestation for the first time.

Quality, protocol alignment and supply chain security

Git Proxy v2 also addresses a number of quality and compatibility improvements, including a full rewrite of the push parser, hardening of the MongoDB adaptor, alignment with the Git protocol by associating commits to users via email rather than Git user.name and standardised API error codes to ensure correct rendering by Git clients.

The Git Proxy maintainers have also been working on improving the project’s supply chain security and governance. At the time of writing,

Git Proxy achieves a score of 8.9 on the OpenSSF Scorecard, a popular risk assessment tool from the Open Source Security Foundation and emerging requirement for the adoption of security tooling in large enterprises. This strong score showcases the project’s commitment to meeting financial firms’ high standards for security.

What’s next

We have more major improvements planned for Git Proxy 2.1 and 2.2, including long-awaited SSH support, further performance optimisations and the UI refresh mentioned above. Together, these changes will bring Git Proxy closer to the experience developers expect from major source code management platforms.

Looking further ahead to Git Proxy v3, the maintainers are exploring ways to govern more than Git operations alone. This will allow developers to write PR descriptions, make comments and answer discussions on GitHub (or their chosen provider) while ensuring compliance with security policies and significantly simplifying the tasks of governing non-code contributions to upstream projects.

We welcome suggestions for improvements and new features for , as well as reviews of pull requests while they are still in development. We intend to start shipping these improvements over the coming months.

How to get started

Getting started with Git Proxy is as easy as:

npm install -g @finos/git-proxy

If you experience any issues onboarding Git Proxy in your organisation, check out our deployment guide. The maintainers are active in the Discussions page and are also quick to review PRs to help you hit the ground running.

You can also join our fortnightly Community Call, every other Monday @ 4pm UK /  11am ET where the community collaborates on the future of Git Proxy.

Start contributing today

We welcome pull requests from new contributors. Many open source maintainers start by contributing bug fixes and small features, and are eventually elected as maintainers as they gain the community’s trust.

Join us today in building the future of open source: check out our Good First Issues to get started!

 

Authors: Kris West, NatWest & Juan Escalada, G-Research Open Source Software