Secret Scanning ist für viele Entwickler und Tech Leads der direkte Einstieg in die Frage, was ein Repository über Sicherheitsrisiken verrät. Wer nach „secret scanning“ sucht, will meist drei Dinge wissen: was dabei geprüft wird, was typischerweise gefunden wird und wo die Grenzen liegen.
Gemeint sind damit zwei Blickwinkel:
- Entwickler, die ihr Repository als Arbeitsprobe zeigen und vorab verstehen wollen, welche Funde relevant werden können
- Tech Leads, die ein Repository einschätzen möchten, ohne sich nur auf Selbstaussagen oder einen CV zu stützen
Bei Acquispect wird nicht der Lebenslauf auditiert, sondern das Git-Repository als reale Arbeitsprobe. Secret Scanning ist dort Teil von Stage B der Proof Engine, dem Safety Check neben bekannten Schwachstellen in Abhängigkeiten, Test Coverage und Tech Stack. Mehr zur gesamten Prüfmethodik der Proof Engine.
Was Secret Scanning eigentlich prüft
Secret Scanning prüft, ob sensible Zugangsdaten oder andere geheime Werte versehentlich in einem Repository gelandet sind. Gemeint sind also Einträge, die nicht öffentlich im Code, in Dateien oder in der Historie stehen sollten, weil sie Zugriff auf Systeme, Dienste oder Konten ermöglichen können.
Wichtig ist dabei: Relevant ist nicht nur der sichtbar genutzte Anwendungscode. Auch andere Inhalte können solche Funde enthalten, zum Beispiel:
- API-Keys
- Tokens
- Passwörter
- private Schlüssel
- Zugangsdaten in Konfigurationsdateien
Solche Werte tauchen oft nicht nur in Quelltexten auf, sondern auch in Commit-Inhalten, Beispielkonfigurationen, Testcode oder lokalen Hilfsdateien. Gerade für Entwickler, die ein Repository als Arbeitsprobe zeigen, ist das wichtig: Ein problematischer Eintrag sitzt nicht zwingend in der Hauptanwendung, sondern manchmal in Dateien, die im Alltag schnell übersehen werden.
Für Tech Leads ist Secret Scanning vor allem ein klar umrissener Sicherheitscheck. Es beantwortet nicht die gesamte Frage nach der Qualität eines Projekts, sondern einen konkreten Teil davon: ob geleakte Secrets auffallen. Ein Fund ist deshalb zunächst ein Signal für Risiko und für den Umgang mit Sicherheitsdisziplin, nicht automatisch ein Gesamturteil über die Person hinter dem Repository.
Bei Acquispect gehört dieser Check zu Stage B des Audits, dem Safety Check. Dort wird auf geleakte Secrets gescannt, zusätzlich zu bekannten Schwachstellen in Abhängigkeiten, Test Coverage und Tech Stack. Wer Acquispect als Arbeitsprobe nutzt, findet mehr dazu auf der Seite für Entwickler mit dem kostenlosen Repo-Audit. Für prüfende Teams gibt es die Seite für Unternehmen mit der Verifikation von Credentials.
Was Secret Scanning typischerweise findet
Typische Funde sind meist keine exotischen Sonderfälle, sondern bekannte Muster, die im Entwicklungsalltag leicht entstehen. Dazu gehören vor allem:
- hartcodierte Tokens direkt im Quellcode
- Zugangsdaten in
.env-ähnlichen Dateien - private Schlüssel
- versehentlich eingecheckte Konfigurationsdateien
Solche Einträge landen oft nicht mit Absicht im Repository. Häufig entstehen sie aus Bequemlichkeit bei lokalen Tests, aus Debugging-Situationen oder weil Beispielwerte kopiert und später nicht wieder ersetzt wurden. Gerade in Momenten, in denen schnell etwas zum Laufen gebracht werden soll, rutschen sensible Werte eher in Dateien, die anschließend mit eingecheckt werden.
Wichtig ist außerdem die Historie: Auch alte Commits können relevant sein, wenn dort sensible Werte einmal enthalten waren. Selbst wenn der aktuelle Stand sauber wirkt, bleibt ein früherer Eintrag für die Bewertung interessant. Deshalb fallen besonders Commits auf, in denen Konfigurationen geändert wurden oder in denen Build-Skripte und Deployment-Dateien angepasst wurden. Wer sich für angrenzende Abläufe interessiert, findet dazu auch im Beitrag zum Release Management nützlichen Kontext.
Secret Scanning erkennt dabei Muster und verdächtige Zeichenfolgen. Trotzdem bleibt der Kontext entscheidend. Nicht jeder Treffer bedeutet dasselbe: Ein Demo-Wert ist anders zu bewerten als ein echter produktiver Schlüssel.
Für Entwickler ist genau das oft die Überraschung: Das Problem sitzt nicht in der Hauptanwendung, sondern in Hilfsdateien, Beispielen oder in der Commit-Historie. Für Tech Leads kann die Art eines Fundes Hinweise darauf geben, wie Reviews ablaufen, wie sorgfältig mit Konfiguration umgegangen wird und wie eingeübt Sicherheitsroutine ist. Wer Arbeitsproben generell einordnen will, kann ergänzend den Artikel zum Prüfen von Arbeitszeugnissen lesen. Einen Überblick über die Preise gibt es ebenfalls separat.
Was ein Fund bedeutet – und was nicht
Ein Treffer im Secret Scanning ist ein wichtiges Signal, aber kein Urteil, das für sich allein stehen sollte. Er zeigt, dass in einem Repository sensible Werte auffallen können. Mehr sagt er zunächst nicht.
Vor allem ersetzt ein einzelner Fund keine vollständige Sicherheitsanalyse eines Systems. Ob ein Repository an einer Stelle ein Secret enthält, beantwortet nicht automatisch Fragen zu Architektur, Laufzeitverhalten, Berechtigungen oder zum tatsächlichen Einsatzkontext.
Genauso wichtig ist die andere Richtung: Wenn kein Fund auftaucht, ist damit nicht bewiesen, dass keinerlei Risiko besteht. Secret Scanning prüft einen klar abgegrenzten Sicherheitsaspekt. Es ist kein Beleg dafür, dass ein Projekt insgesamt frei von Problemen ist.
Für eine brauchbare Einordnung zählt deshalb der Gesamtkontext. Dazu gehören unter anderem:
- die Struktur des Repositorys
- die Commit-Historie
- bekannte Schwachstellen in Dependencies
- die Testabdeckung
- der verwendete Tech Stack
Bei Acquispect ist Secret Scanning deshalb nur ein Teil von Stage B, dem Safety Check. Dort wird zusätzlich auf bekannte Schwachstellen in Abhängigkeiten, Test Coverage und Tech Stack geschaut.
Daneben untersucht Stage A die .git-Historie forensisch: Autorschaft, mögliches Code-Dumping in Bulk und einen Impact Score. Diese Trennung ist hilfreich, weil Sicherheitsfunde etwas anderes aussagen als Arbeitsweise, Herkunft von Code oder tatsächliche Entwicklungsbeiträge.
Gerade wenn Arbeitsproben bewertet werden, lohnt sich diese Unterscheidung stärker als der Blick auf formale Nachweise allein. Wer diesen Unterschied weiterdenken will, findet das auch im Beitrag Arbeitszeugnis prüfen: was es leisten kann.
Wie Entwickler sich auf Secret Scanning vorbereiten können
Wer ein Repository als Arbeitsprobe teilen will, sollte Secret Scanning nicht erst als nachgelagerten Check sehen. Sinnvoller ist es, vorher bewusst nach sensiblen Werten, Beispielkonfigurationen und alten problematischen Einträgen zu schauen.
Dazu gehört vor allem eine einfache Grundregel: Secrets gehören nicht ins Repository, sondern getrennt verwaltet. Beispielwerte sollten klar als Platzhalter erkennbar sein, damit sie nicht wie echte Zugangsdaten wirken.
Wichtig ist außerdem der Blick über den aktuellen Stand des Branches hinaus. Nicht nur der sichtbare Code zählt, sondern auch die Commit-Historie. Gerade dort können Altlasten liegen, die im Tagesgeschäft längst vergessen wurden.
Besondere Aufmerksamkeit verdienen deshalb nicht nur Anwendungsdateien, sondern auch:
- Hilfsdateien
- Skripte
- Konfigurationsdateien
- Test- und Beispielcode
Für Entwickler lohnt sich diese Vorbereitung doppelt. Zum einen reduziert sie vermeidbare Funde. Zum anderen wird damit etwas sichtbar, das in Bewerbungen oft nur behauptet wird: ein sorgfältiger Umgang mit Sicherheit im echten Arbeitskontext.
Dabei sollte man Secret Scanning nicht isoliert denken. Im selben Safety Check werden auch bekannte Schwachstellen in Abhängigkeiten, Test Coverage und der Tech Stack betrachtet. Wer sein Repository zeigt, zeigt also immer auch, wie sauber diese benachbarten Aspekte gepflegt sind.
Bei Acquispect können Entwickler ihr Repository kostenlos auditieren lassen.
Wie Tech Leads die Ergebnisse lesen sollten
Tech Leads müssen für eine belastbare Einordnung nicht zwingend die Rohdaten eines Repositorys selbst durchforsten. Wichtiger ist ein Ergebnis, das die relevanten Signale geordnet zusammenführt und nachvollziehbar macht.
Bei Acquispect entsteht dieses Ergebnis nach drei Stages. Am Ende steht ein Konsensurteil eines Panels aus fünf AI-Expert-Personas:
- Tech Lead
- Security
- Performance
- Architect
- Craftsman
Dieses Verdict ist bewusst kein sicherer Wahrheitsanspruch. Es ist eine zusammengefasste Bewertung mit Confidence Score. Für die Praxis heißt das: Das Ergebnis liefert ein strukturiertes Signal, aber keine absolute Gewissheit.
Versiegelt wird es als W3C Verifiable Credential via did:web im Wallet des Entwicklers. Das Credential gehört dem Entwickler selbst. Wenn ein Unternehmen es verifiziert, sieht es nicht die Rohdaten aus dem Repository, sondern das Verdict. Zusätzlich kann der vollständige Audit Log gelesen werden, um die Einordnung nachzuvollziehen.
Für Tech Leads ist genau das im Auswahlprozess nützlich. Sicherheits- und Arbeitsqualität eines Repositorys lassen sich so geordneter lesen als über Selbstaussagen allein. Statt nur auf Aussagen im CV oder in Gesprächen zu reagieren, liegt ein prüfbares Ergebnis aus echter Arbeit vor — mit Begründung und mit Confidence Score.
Häufige Fragen zu Secret Scanning
Findet Secret Scanning nur aktuelle Secrets oder auch solche aus älteren Commits?
Nicht nur den aktuellen Stand. Für die Einordnung kann auch relevant sein, ob sensible Werte in früheren Commits einmal im Repository enthalten waren. Genau das ist für Entwickler oft wichtig: Ein Branch wirkt heute sauber, während in der Historie noch problematische Einträge liegen können.
Für Tech Leads heißt das: Ein Blick nur auf den letzten Stand reicht für eine Sicherheitsfrage oft nicht aus. Gerade ältere Konfigurationsänderungen, Hilfsdateien oder Build-bezogene Anpassungen können Funde erklären.
Bedeutet ein Treffer beim Secret Scanning automatisch, dass ein Repository unsicher ist?
Nein. Ein Treffer ist ein Risikosignal, aber noch kein vollständiges Urteil. Der Kontext entscheidet mit:
- Handelt es sich um einen echten sensiblen Wert oder um einen Demo-Wert?
- Liegt der Fund im Kern des Projekts oder in einer Hilfsdatei?
- Ist es ein einzelner Vorfall oder Teil eines wiederkehrenden Musters?
Für die Bewertung zählt also nicht nur, dass etwas gefunden wurde, sondern auch was genau gefunden wurde und in welchem Zusammenhang.
Reicht Secret Scanning aus, um ein Repository vollständig zu bewerten?
Ebenfalls nein. Secret Scanning beantwortet eine klar begrenzte Sicherheitsfrage. Es ersetzt weder die Prüfung bekannter Schwachstellen in Dependencies noch den Blick auf Test Coverage, Tech Stack oder die Arbeitsweise in der Git-Historie.
Darum ist es bei Acquispect nur ein Teil von Stage B des Safety Checks. Daneben gibt es Stage A für die forensische Analyse der .git-Historie und Stage C, in der fünf AI-Expert-Personas zu einem Konsensurteil mit Confidence Score kommen.
Was sehen Unternehmen bei einer Verifikation eigentlich: Rohdaten aus dem Repository oder nur das Ergebnis?
Unternehmen sehen bei der Verifikation das Verdict, nicht die Rohdaten aus dem Repository. Zusätzlich können sie den vollständigen Audit Log lesen, um die Einordnung nachzuvollziehen.
Das Ergebnis ist als W3C Verifiable Credential via did:web im Wallet des Entwicklers versiegelt. Der Entwickler besitzt dieses Credential selbst.
Was kostet die Prüfung für Entwickler und wie bezahlen Unternehmen die Verifikation?
Für Entwickler ist das Audit kostenlos. Unternehmen zahlen pro Verifikation, ohne Subscription. Dabei bezahlt der Verifier.
Fazit: Secret Scanning ist ein klares Signal, kein Alleinurteil
Secret Scanning beantwortet eine konkrete Frage: ob in einem Repository sensible Werte auffallen, die dort nicht hingehören. Genau deshalb suchen viele nach „secret scanning“: Sie wollen verstehen, was geprüft wird, was gefunden werden kann und wie ein Fund zu lesen ist.
Für die Praxis hilft vor allem diese Trennung:
- Ein Fund zeigt ein Sicherheitsrisiko.
- Kein Fund ist kein Beweis für vollständige Sicherheit.
- Die Bedeutung entsteht erst im Zusammenhang mit dem restlichen Repository.
Bei Acquispect ist Secret Scanning daher nicht das Endergebnis, sondern ein Teil von Stage B des Safety Checks. Daneben fließen bekannte Schwachstellen in Dependencies, Test Coverage und Tech Stack ein. Danach kommt Stage C: fünf AI-Expert-Personas bilden ein gemeinsames Verdict mit Confidence Score.
So wird aus einem einzelnen Sicherheitscheck kein vorschnelles Urteil, sondern ein eingeordnetes Signal aus realer Arbeit.