gitleaks ist feature-frozen (letztes Release 03/2026, nur noch Security-Patches); die Maintainer inkl. Original-Autor entwickeln betterleaks weiter (MIT, aktive Releases, Secret-Validierung). - besserleaks-Standardregeln via [extend] useDefault - [allowlist]: Beispiele (*.example/*.sample/*.template), i18n-JSON, node_modules/vendor/dist/Lockfiles, Fixtures -> kein Alarm - .env/.env.prod, docker-compose, Code und echte Configs bleiben hart - pro Repo: .betterleaks.toml hat Vorrang, .betterleaksignore fuer akzeptierte Altlasten (Fingerprint je Zeile) - USAGE.md: Abschnitt zum Wechsel + Filterrichtlinie Verifiziert an den 5 auffaelligen Repos: gitleaks 34 Treffer -> betterleaks 58, nach Filterrichtlinie 35 (Rauschen entfernt, echte Funde bleiben).
2.9 KiB
ci-templates — org-weites Quality-Gate
Reusable Workflow fuer alle Orgs. Scans (betterleaks/semgrep/trivy/actionlint) laufen per
Default; Sprach-Linter (python/node/php) sind opt-in. Report-only per Default,
blocking: true macht SAST/Vuln/Lint zum harten Gate. Secrets (betterleaks) sind IMMER hart.
Secret-Scan: betterleaks statt gitleaks (seit 2026-09-11)
gitleaks ist feature-frozen (letztes Release 03/2026, nur noch Security-Patches);
die Maintainer inkl. Original-Autor entwickeln betterleaks weiter (v1.8.1, MIT,
aktive Releases). betterleaks findet in denselben Repos deutlich mehr als gitleaks
(Bsp.: 34 -> 58 Treffer), kann Secrets per validate auf "noch aktiv?" pruefen und
filtert Rauschen per Expr-Regeln.
Zentrale Richtlinie liegt inline im Job secret-scan ([extend] useDefault = true
[allowlist]): Beispiel-Dateien (.env.example,*.sample,*.template), Uebersetzungen (i18n/*.json), Abhaengigkeiten/Build (node_modules,vendor,dist, Lockfiles) und Fixtures werden nicht gemeldet. Nicht ausgeschlossen:.env/.env.prod,docker-compose*, Code und echte Config-Dateien - dort laesst ein Fund den Gate fehlschlagen.
Pro Repo:
.betterleaks.tomlim Repo-Root ersetzt die zentrale Richtlinie (Vorrang)..betterleaksignoreim Repo-Root nimmt einzeln akzeptierte Altlasten auf; Format =Fingerprintaus dem JSON-Report:<commit>:<pfad>:<regel>:<zeile>. Details zum Fund liefert der Job-Log; Fingerprints lokal perbetterleaks git . --report-format json --report-path r.json.- Inline-Ausnahme direkt im Code: Kommentar
betterleaks:allowin der Zeile.
WICHTIG — Sichtbarkeit (Gitea-Limitation, verifiziert 2026-08-25)
Private reusable Workflows koennen von anderen Repos NICHT gelesen werden ("no permission to read reusable workflow"). Zwei Adoptions-Modi:
A) ci-templates PUBLIC (empfohlen fuer org-weit)
Pro Repo .gitea/workflows/quality.yml:
name: quality
on: [push, pull_request]
jobs:
quality:
uses: digiflo/ci-templates/.gitea/workflows/quality.yml@main
with:
python: true # node: true / php: true je nach Repo
# blocking: true # spaeter: hartes Gate
B) ci-templates PRIVAT -> lokale Kopie pro Repo
Komplette quality.yml ins Ziel-Repo kopieren, lokal referenzieren
(uses: ./.gitea/workflows/quality.yml). Nachteil: Updates muessen nachgezogen werden.
Inputs
| Input | Default | Wirkung |
|---|---|---|
| skip_secret_scan / skip_sast / skip_vuln | false | Scan abschalten |
| python / node / php | false | Sprach-Linter aktivieren |
| blocking | false | SAST/Vuln/Lint hart (Secrets immer hart) |
Constraints
- Runner
ct117-docker(catthehacker, Debian/PEP668): pip mit--break-system-packages. - KEINE neuen Docker-Hub-Images im Job (unauth Pull-Limit) -> Tools via GitHub-Release/pip.
- Fuer harte Gates zusaetzlich Branch-Protection (Required status checks) auf
mainsetzen.