Skip to main content
Private preview. fremforge is in private preview — invited customers only. Content is still subject to change. Request access →
Security
Push protection

Push protection

Every push to a fremforge repo runs through a Gitleaks pre-receive hook on the Forgejo server. If the scanner finds a credential, the push is rejected and the developer sees the matched rule (no value, no commit SHA leaked back to a third party).

This is distinct from SAST findings and container-image scanning: push protection runs at git-push time, before the commits are stored anywhere fremforge has to defend. The other scanners run later on the stored result.

What gets matched

Gitleaks’ default rule set plus fremforge additions:

  • Cloud provider keys (AWS, GCP service account JSON, Azure SAS tokens, T Cloud AK/SK)
  • Common SaaS API keys (Stripe, Mollie, SendGrid, Twilio, Lettermint, OpenAI)
  • Generic high-entropy patterns (PEM private keys, JWT, SSH private keys)
  • fremforge-specific: api tokens (fft_*), runner OIDC private keys, OBS bucket bootstrap creds, ack-signing HMAC secrets
  • A custom regex set per tenant, configurable in tenant admin, Security, Push protection, Custom patterns

The Gitleaks signature pack is pinned, reviewed when bumped, and shipped via the same SWR mirror as our other dev-tooling. We don’t pull from GitHub’s content registry at push time.

What the developer sees

When a push hits a matched secret, the developer sees:

remote: Push rejected by fremforge push-protection.
remote:
remote: Matched rule: aws_access_key_id
remote: Path:         apps/api/src/services/uploader.ts:42
remote: Commit:       <commit-sha>
remote:
remote: If this is a false positive, ask an org owner to add an
remote: override at frem.sh/<your-org>/_admin/push-protection.
remote: Override IDs are auditable and time-boxed.

No credential value is logged or echoed. The developer has the source open already; they can find the false positive themselves.

Overrides

Tenant admins can add overrides for cases the scanner gets wrong (test fixtures, sample SDK snippets, documentation that intentionally shows a key shape).

  1. Tenant admin, Security, Push protection, Overrides, Add override.
  2. Pick: by-rule (e.g. allow aws_access_key_id matches in apps/sample/), by-path (e.g. allow everything in test/fixtures/), or by exact match (paste the matched string).
  3. Set a scope: this repo, or all repos in the org.
  4. Expiry: 90 days default, max 1 year.
  5. Justification (audited).

Operators review cross-tenant overrides quarterly. Anything flagged as expiring lands in the operator console under /_app/_admin/overrides-expiring.

Bypass for already-leaked credentials

A push-protection block is not the same as the credential being safe. By the time you hit the block, you have a credential sitting in a commit on your laptop. Rotate the credential before doing anything else. Once rotated, you can rebase the commit out of the branch or push with an override; either path works once the credential is dead.

What it doesn’t do

  • It does not scan history backwards. If a credential was committed before push protection was enabled, it stays committed. Use a history-rewrite tool (the migration guide walks through this).
  • It does not catch every possible credential shape. Custom rules per tenant cover the gaps that matter for your stack.
  • It does not run on git push --force of a branch that’s already known to fremforge (the pre-receive hook still runs, but the comparison is against the new tip; a force-push that overwrites a leaked commit with a clean one is allowed).