ci(gitleaks): add pre-commit hook, config with sealed-secrets allowlist, and tests

[wajidzahoor-dls]

Summary

• Enable gitleaks as a pre-commit hook to help prevent committing secrets.
• Add an allowlist for sealed-secrets (long Ag… patterns), scoped to *.yml / *.yaml.
• To extend the allowlist all files repo-wide, comment the entire paths line in .gitleaks.toml file.

---

How to test

I verified this change with:

pre-commit run --all-files

This should include output from gitleaks, scanning for potential hardcoded secrets.

For local testing, I used:

python3 -m venv .venv
source .venv/bin/activate
pip install pre-commit
pre-commit install --hook-type pre-commit
pre-commit run --all-files

Depending on your environment, testing may happen differently:

• Devcontainer: pre-commit hooks (including gitleaks) bootstrapped automatically
• CI: pre-commit hooks run as part of the lint stage (e.g., tox -e pre-commit)

---

Manual spot checks

1. Secret detection

   • Try committing a file with a fake API key/private key → commit should be blocked by gitleaks.

2. Allowlist works (YAML only)

   • Place a sealed-secret-like long Ag… token in a .yaml/.yml file → should be allowlisted.
   • Place the same token in a non-YAML file → should be flagged.

The allowlist is regex-based and may occasionally cause false positives or false negatives, but it provides better protection than having no scanning in place.

---

Notes

• gitleaks may produce false positives (flagging non-secrets) or false negatives (missing real secrets)
• To extend the allowlist beyond YAML, comment out the entire paths line in .gitleaks.toml
• For more information, including configuration options for customizing detection rules, refer to the official documentation:
  https://github.com/gitleaks/gitleaks

[coretl]

Please can we also have a test in tests that inserts a secret into the code base, runs tox -e pre-commit and checks the output?

A bit like this but for pre-commit:

python-copier-template/tests/test_example.py

Lines 226 to 238 in 9d544a5

	def test_pep8_naming(tmp_path: Path):
	code = """
	myVariable = "foo"
	"""
	copy_project(tmp_path)
	run = make_venv(tmp_path)
	src_file = tmp_path / "src" / "python_copier_template_example" / "bad_example.py"
	with src_file.open("w") as stream:
	stream.write(code)
	with pytest.raises(AssertionError, match=r"N816 .*"):
	run("ruff check")

[wajidzahoor-dls]

@coretl

Following is what I have done in the latest commit and have pushed it to this branch.

• Added tests/test_gitleaks_precommit.py:

  • 3 “stable leak” tests (GitHub PAT, Slack webhook, Stripe key) → flagged.
  • SealedSecret-like Ag... blob in .yaml/.yml → allowlisted → pre-commit passes.
  • Same blob in non-YAML (.py) → correctly flagged → pre-commit fails.

• Made template/.gitleaks.toml a symlink to the root config:

  ln -s ../.gitleaks.toml template/.gitleaks.toml
  

  (Note: symlink handling can vary on different platforms)

• Attached screenshot(s):

  • Passing run: pytest -k gitleaks -vv and tox -e pre-commit green.

[DominicOram]

Is the decision to only do this in YAML documented somewhere? I think we'll potentially miss things doing this?

[callumforrester]

Devcontainer: pre-commit hooks (including gitleaks) bootstrapped automatically

@wajidzahoor-dls @coretl is it possible to do the bootstapping at devcontainer build time instead of on first run of pre-commit? In my experience it takes a little while which can be an annoying interruption to the commit workflow.

[GDYendell]

Is the decision to only do this in YAML documented somewhere? I think we'll potentially miss things doing this?

This is a good point. Probably the most egregious cases are going to have the secret in source code. But, this could increase false positives by quite a bit.

[wajidzahoor-dls]

Is the decision to only do this in YAML documented somewhere? I think we'll potentially miss things doing this?

This is a good point. Probably the most egregious cases are going to have the secret in source code. But, this could increase false positives by quite a bit.

Many of the false positives are usually SealedSecrets. The allow-list is scoped to YAML/YML to keep the initial change small and avoid deviating too much from gitleaks’ defaults. All of gitleaks’ built-in rules still run (useDefault = true); only the very specific long Ag… SealedSecret-style blobs in YAML/YML manifests are allow-listed. This cuts down a major source of noise without suppressing real leaks in code or elsewhere.

At the template level this can server as default, but on a per-repo basis we can expand the allow-list beyond YAML by commenting out the paths line in .gitleaks.toml. And if we later decide as a team that the default shouldn’t be YAML-only, it’s a one-line change in the template’s .gitleaks.toml (with tests updated as needed).

Worth noting: the allow-list is regex-based and may occasionally cause false positives or false negatives, but overall it reduces SealedSecrets noise while keeping baseline coverage intact.

[DominicOram]

The allow-list is scoped to YAML/YML to keep the initial change small and avoid deviating too much from gitleaks’ defaults. All of gitleaks’ built-in rules still run

My bad, this was a misunderstanding on my part. I think I read the comment:

# Limit to YAML only for now. Comment this out if you want it to apply everywhere.

To imply that all rules are only applied to YAML rather than just the sealed secret part. Could you update that comment to be clearer?

[wajidzahoor-dls]

Devcontainer: pre-commit hooks (including gitleaks) bootstrapped automatically

@wajidzahoor-dls @coretl is it possible to do the bootstapping at devcontainer build time instead of on first run of pre-commit? In my experience it takes a little while which can be an annoying interruption to the commit workflow.

I think this should be doable. Maybe we could look at using copier.yml tasks to install pre-commit hooks right after the template is applied (if the repo is already initialized), or lean on .devcontainer so the bootstrap happens automatically when the dev environment is first created. We can create separate branch to explore this further as needed.

[wajidzahoor-dls]

# Limit to YAML only for now. Comment this out if you want it to apply everywhere.

To imply that all rules are only applied to YAML rather than just the sealed secret part. Could you update that comment to be clearer?

Thank you for the suggestion. I’ve updated the comments in .gitleaks.toml for clarity.

[coretl]

https://pre-commit.com/#pre-commit-install suggests pre-commit install --install-hooks will install the hook environments, so please can you put that in devcontainer.json (in the template dir and in the root) and test it pre-populates the environments as we expect

[coretl]

https://pre-commit.com/#pre-commit-install suggests pre-commit install --install-hooks will install the hook environments, so please can you put that in devcontainer.json (in the template dir and in the root) and test it pre-populates the environments as we expect

Tested locally, and pre-commit install --install-hooks does the right thing