Rulesets and security

Default branch protection

New repositories protect main by default: merges require one approved Finluth pull request, and force pushes and branch deletion are rejected. Repository admins can create branch and tag rulesets with exact names or wildcard patterns from Access & branch rules.

Rulesets can block branch/tag creation, force updates, and deletion; require pull requests, approvals, status checks, signed commits, or linear history; and let selected repository writer or admin roles bypass that ruleset. Overlapping rules apply together unless the pusher has a bypass role for each applicable ruleset.

Tag rules support creation, update, and deletion controls; review, status, signature, and linear-history requirements apply to branches. Git push enforcement runs in the bare repository's pre-receive hook.

Signed-commit rules use git verify-commit: configure the server Git GPG keyring, or for SSH signatures set gpg.format=ssh, gpg.ssh.allowedSignersFile, and the signing key. Finluth signs generated merge commits with the server's configured signer. Linear-history pull requests are merged as single-parent squash commits; direct pushes containing merge commits are rejected.

Secret scanning

Open a repository's Security tab and choose Scan repository history to inspect all reachable branches and tags. Finluth also scans incoming Git objects in its pre-receive hook and rejects pushes containing supported GitHub, AWS, Google, Slack, Stripe, OpenAI, SendGrid, or Twilio credentials, and private-key headers.

Findings show the pattern, file, line, and commit without exposing the credential. Rejected credentials must be removed from the pushed history and revoked or rotated with their provider.

The scanner currently inspects blobs up to 16 MiB and up to 512 MiB of content per scan; push protection rejects pushes containing larger blobs it cannot inspect, while a history scan reports those blobs for separate review. Patterns are heuristic and do not replace provider-side credential monitoring.