In a gittan pipeline, everything has a pin

GitHub Actions has a marketplace with thousands of community-built actions. Need to deploy to AWS? There is an action. Need to send a Slack notification? There is an action. This is convenient. It is also a supply chain risk that most teams underestimate, and that we refuse to normalize.

The supply chain problem

When you add uses: some-org/some-action@v3 to your workflow, you are running code written by someone you do not know, with full access to your repository's secrets, source code, and CI environment. The action can read your deploy keys, exfiltrate environment variables, and modify the code being built.

This is not theoretical. In early 2024, a widely-used GitHub Action was compromised, leaking CI/CD secrets from repositories that used it. The attack surface is every third-party action in every workflow in every repository.

Relocating the risk is not removing it

gittan pipelines use containerized modules instead of marketplace actions. The module ecosystem has public community registries. Trusting them wholesale is the marketplace risk relocated, not removed. A team that pulls arbitrary community modules into their pipeline has the same supply chain exposure as a team using unaudited GitHub Actions.

We are honest about this because a security page that says "marketplace = needless supply-chain risk" while pulling arbitrary community modules on the other side is not a security page. It is marketing. We apply our own thesis consistently.

Three layers of control

The same principle that drives the no :latest gate applies to modules: in a gittan pipeline, everything has a pin.

• ‣ Pin by digest, not tag. Every module reference must be content-addressed — commit SHA or digest, never a floating ref. A module pulled at @main can change under you. A pinned one cannot. This is content-addressing applied to supply chain — the most on-brand control we have.
• ‣ Vendor what you trust. Mirror a curated set of approved modules into a gittan-controlled namespace. Paved-road pipelines pull only from the vetted mirror, not the open registry. This is the platform-as-enabler pattern: the platform team curates, the teams consume.
• ‣ First-party as default, third-party as explicit off-road. Base pipelines use only gittan- or team-authored modules. Pulling an external module is possible but is a deliberate, logged act — the team's responsibility, not a silent default.

Reuse without risk

Teams still share CI logic. The mechanism is team templates — a set of pipeline steps that apply to every repo in a team. If your backend team uses the same lint, test, and build steps across 20 repos, that is one template, not 20 copy-pasted configs.

The difference is that the template is owned by your team, stored in your org, and governed by your policies. It is not a third-party dependency you hope stays maintained and uncompromised.

What it costs

No marketplace means no one-click integrations. If you need a CI step that sends a Slack notification, you write a module or use one from the curated set. There is no community-maintained action that does it for you with zero effort. The trade-off is explicit: less convenience, more control, no supply chain surprises. For CI — where your secrets are present and your artifacts are produced — we believe control matters more.