Gitleaks custom rule for sume_live_ API keys, with pre-commit

Add a gitleaks rule that matches sume_live_ keys, run it as a pre-commit hook, and know what to do within minutes if a Sume key does leak.

4 min readSume
All posts

Why a custom rule

Sume API keys start with sume_live_ and carry the scopes you picked when you created them. Generic secret scanners will not know that prefix, so a key pasted into a test file can sail through review. Gitleaks lets you add your own [[rules]] in a .gitleaks.toml: each has an id, a description, a Go regex and optional keywords that pre-filter lines before the regex runs.

The README also documents running it as a pre-commit hook, which is where the second half of this post goes.

The rule

Save this as .gitleaks.toml in the repo root. The regex requires at least eight characters after the prefix so the bare prefix in documentation does not fire. The extend block keeps gitleaks' built-in rules too.

[extend]
useDefault = true

[[rules]]
id = "sume-live-api-key"
description = "Sume API key"
regex = '''sume_live_[A-Za-z0-9_-]{8,}'''
keywords = ["sume_live_"]

Run it before commit and in CI

  • Local: add the gitleaks hook (id gitleaks) to .pre-commit-config.yaml as the README shows, then run pre-commit install so staged changes are scanned before each commit.
  • CI: run gitleaks over the full git history, which catches a key that was committed and later deleted from the tree.
  • Test the rule: put a fake key such as sume_live_abcdefgh12345678 in a scratch file, stage it, and confirm the hook blocks the commit.

If a key leaks anyway

Per the Sume authentication docs, scopes are fixed when the key is created, so a leaked key has exactly the powers you gave it. Treat any exposure as a spent key:

  • Create a replacement key with the least scopes the service needs.
  • Deploy it, then delete the old key in the dashboard.
  • Check your balance and recent jobs for requests you did not make: GET /v1/balance and GET /v1/jobs are read routes.
  • Purge the commit from history only after revoking; removing a file never un-leaks a key.

Keep keys on the server. Browsers and mobile apps should call your backend, which holds the key in an environment variable.

Sources

More in Developers

All Developers posts

Written by Sume