nosecrets: Secrets aus Git-Commits fernhalten

nosecrets ist ein schneller, offline Secret-Scanner für Git Pre-Commit Hooks. Das Tool erkennt API-Keys, Tokens, Zugangsdaten und auch auffällige High-Entropy-Strings, bevor sie im Commit landen.

Der Punkt ist nicht Security-Theater. Der Punkt ist, dass kleine Fehler in Git sehr teuer werden können: ein versehentlich committeter Datenbank-String, ein Stripe Secret Key in einer Demo, ein Cloudflare Token in einer .env-Datei. Wer so etwas erst nach dem Push bemerkt, ist schon im Schadensbegrenzungsmodus.

Der eigentliche Schaden beginnt nicht beim Commit

Ein Secret in Git ist nicht nur “kurz peinlich”. Es zieht eine Kette an Problemen nach sich:

Zugangsdaten müssen rotiert werden
Deployments und lokale Setups brechen
Die Git-History bleibt verunreinigt
Öffentliche Forks oder Mirrors können den Leak bereits enthalten
Vertrauen beim Kunden oder im Team sinkt sofort

In der Praxis passiert das nicht, weil Entwickler fahrlässig sind. Es passiert, weil moderne Projekte voll mit Tokens, lokalen .env-Dateien, Test-Zugängen und schnellen Workarounds sind. Genau deshalb ist die beste Stelle für einen Check nicht später in CI, sondern direkt vor dem Commit.

Was nosecrets lösen soll

nosecrets ist bewusst kein großes Security-Framework. Es versucht nicht, die komplette Git-History zu analysieren oder einen Cloud-Dienst zur Verifikation anzubinden. Es löst ein engeres, aber sehr häufiges Problem:

“Stoppe mich in dem Moment, in dem ich gerade dabei bin, ein Secret zu committen.”

Daraus ergeben sich ein paar klare Designentscheidungen:

Pre-commit statt History-Scan: Fokus auf staged Dateien
Offline statt API-Check: keine Daten verlassen die Maschine
Schnell statt schwergewichtig: wenig Reibung im Alltag
Konfigurierbar statt magisch: Ignores, Allowlists und Regeln sind nachvollziehbar

Das ist kein Ersatz für weitergehende Security-Maßnahmen. Es ist die pragmatische erste Verteidigungslinie dort, wo Fehler tatsächlich entstehen.

Warum es das Tool überhaupt gibt

Es gibt bereits etablierte Secret-Scanner. Der Grund für nosecrets war deshalb nicht “der Markt braucht noch ein Tool”, sondern eine konkretere Kombination:

ein reales Problem, das im Alltag ständig auftreten kann
ein sinnvolles Rust-Projekt mit klarer Grenze
ein Tool, das sich leicht in den eigenen Workflow einbauen lässt

Das Ergebnis ist kein generischer Sicherheitsbaukasten, sondern ein bewusst zugeschnittenes Werkzeug für den lokalen Entwicklungsfluss.

Was im Alltag interessant ist

Wer so ein Tool benutzt, interessiert sich im Alltag für vier Dinge:

1. Es muss schnell genug sein, dass man es nicht ausschaltet

Pre-Commit-Hooks verlieren sofort ihren Wert, wenn sie den Arbeitsfluss dauernd bremsen. nosecrets scannt staged Dateien, nutzt eingebaute Regeln, Validierung und Prefiltering und bleibt dadurch auf den kurzen Weg optimiert.

2. Es muss offline funktionieren

Secrets an einen externen Dienst zu schicken, um zu prüfen, ob sie Secrets sind, ist für viele Teams schon konzeptionell der falsche Weg. nosecrets arbeitet lokal und ohne API-Calls. Das macht den Einsatz in sensibleren Umgebungen deutlich einfacher.

3. Es muss auch unbekannte Tokens erwischen

Signaturbasierte Regeln sind wichtig, aber sie reichen nicht immer. Deshalb gibt es zusätzlich eine Entropy-Erkennung für auffällige, unbekannte oder proprietäre Tokens. Gerade interne Systeme und selbst definierte Zugriffsschlüssel fallen sonst schnell durch das Raster.

4. Es muss False Positives kontrollierbar machen

Ein Scanner, der ständig legitime Testdaten blockiert, wird umgangen. Darum gibt es .nosecrets.toml, .nosecretsignore, Inline-Ignores und Allowlists. Das Ziel ist nicht absolute Reinheit, sondern ein Tool, das im Alltag benutzbar bleibt.

Wofür nosecrets gedacht ist und wofür nicht

Gut geeignet ist das Tool für:

lokale Git-Hooks in Einzelprojekten
kleine Teams, die ohne viel Security-Infrastruktur arbeiten
Agenturen und Freelancer mit vielen Kundenprojekten
Open-Source-Repositories, in denen versehentliche Leaks besonders unangenehm sind
CI/CD-Checks für Verzeichnisse oder geänderte Dateien

Weniger geeignet ist es als alleinige Maßnahme für:

vollständige historische Incident-Analysen
forensische Git-History-Untersuchungen
komplexe Verifikations-Workflows mit externen Providern

Das ist Absicht. Ein Tool wird besser, wenn es seine Grenze kennt.

Was der aktuelle Stand liefert

Der aktuelle Projektstand ist für den Alltag bereits brauchbar:

Scans für staged Dateien oder Verzeichnisse
JSON-Output für Automation
interaktiver Modus zum direkten Ignorieren von Findings
über 100 eingebaute Regeln für gängige Dienste
High-Entropy-Erkennung für unbekannte Secrets
Fingerprint-basierte Ignores

Installation und technische Details sind auf der Landingpage sauberer aufgehoben als hier:

Warum mich solche Tools mehr interessieren als große Plattformversprechen

Ein kleines Tool wie dieses wirkt unspektakulär. Genau deshalb ist es interessant.

Es löst kein abstraktes “Developer Experience”-Problem, sondern ein konkretes Risiko im Alltag. Es spart keine Millionen, aber es verhindert die Art Fehler, die man am liebsten gar nicht erst erklären möchte. Und es zeigt einen Grundsatz, der oft unterschätzt wird:

Die besten Entwicklerwerkzeuge sind häufig nicht die größten. Sie sitzen an der Stelle, an der Reibung, Risiko und Routine aufeinandertreffen.

Einordnung

nosecrets ist ein pragmatisches Werkzeug für einen engen, aber wichtigen Moment im Entwicklungsprozess. Nicht später in der Pipeline, nicht als Enterprise-Schicht oben drauf, sondern genau dort, wo ein Leak meistens beginnt: im lokalen Commit.

Wer sich dafür interessiert, wie das Tool installiert wird, welche Regeln es mitbringt, wie die Konfiguration aussieht und wie sich der Hook in den Workflow integriert, findet den technischen Teil auf der nosecrets Landingpage, auf der casoon.de Produktseite und im Projekt auf GitHub.