Gekappte Geheimnisse

Ein Zugangsdatum, das in einen gepushten Commit gelangt ist, gilt bereits als gekappt – selbst wenn ein späterer Commit es entfernt. Sicherheit erkennt Zugangsdaten in Ihren Änderungen und im Verlauf, speichert keine davon und behandelt jedes als offen, bis jemand bestätigt, dass es geändert oder widerrufen wurde.

Was wird gescannt?#

• Jede Änderung: die Änderungen jedes pull request, als Teil des Coroid Security Checks sowie die Änderungen der eigenen Agenten von Coroid vor dem Commit.
• Der Standardbranch: bei jedem Push und einmal im gesamten Verlauf. Die Verlaufsprüfung startet, sobald ein Repository verbunden wird oder die Funktion Gekappte Geheimnisse aktiviert wird.
• Pull-Request-Branches: Ein Zugangsdatum, das in einen Branch von pull request gepusht wird, führt ebenfalls zu einer Erkennung, da es bereits im Repository vorhanden ist.

Ein Branch, der ohne pull request gepusht wird, wird nicht gescannt.

Die Verlaufsprüfung liest jeden erreichbaren Commit von neuest nach ältest, wobei jede Dateiversion nur einmal gelesen wird. Sie arbeitet in Abschnitten und setzt dort fort, wo sie aufgehört hat. Jedes Repository hat Grenzen für den umfassten Verlauf (Commits, Bytes, Zeit und Dateigröße); ein Repository, das diese überschreitet, weist eine unvollständige Abdeckung auf.

Was wird erkannt?#

Anbieter-Zugangsdaten in ihren bekannten Formaten (AWS-Zugangsschlüssel, GitHub- und GitLab-Tokens, OpenAI-Schlüssel usw.), Autorisierungstokens, Zugangsdaten, die Namen wie password oder api_keyzugewiesen sind, private Schlüssel, Zugangsdaten in URLs sowie lange Zeichenfolgen mit hoher Entropie. Zugangsdaten im Code werden nur dann erkannt, wenn der Wert ein Literal ist – nicht eine Variable oder Funktionsaufruf.

Coroid speichert den Wert niemals.#

Ein erkannter Wert gelangt direkt vom Detektor zum Credential-Broker von Coroid, der einen geschlüsselten Fingerabdruck zurückgibt und den Wert verwirft. Nur der Fingerabdruck wird gespeichert. Er ist pro Organisation geschlüsselt, sodass er nicht zwischen Organisationen verglichen oder offline erraten werden kann.

Überall dort, wo ein Geheimnis sonst angezeigt würde (Erkennungen, Checks, Review-Kommentare, Protokolle), zeigt Coroid nur die Regel, die Länge und den Ort an – zum Beispiel [redacted secret: named_credential, 40 characters]. Kein Teil des Werts wird angezeigt – nicht einmal die ersten Zeichen.

Coroid versucht niemals, ein gefundenes Zugangsdatum zu testen, ob es funktioniert.

Ein Zugangsdatum, eine Erkennung#

Ein Zugangsdatum, das in vielen Commits auftaucht, ergibt eine Erkennung mit mehreren Vorkommen. Dasselbe Zugangsdatum in zwei Repositories ergibt zwei Erkennungen – je eine pro Repository. Wenn Sie eine davon bestätigen, listet Sicherheit die anderen mit demselben Zugangsdatum auf, damit Sie sie gemeinsam bestätigen können. Sie übernimmt dies jedoch nie von sich aus.

Ein Geheimnis wird nur durch Bestätigung geschlossen#

Das Entfernen eines Zugangsdatums aus dem Code macht seine Vorkommen unsichtbar, doch die Erkennung bleibt offen: Jeder, der das Repository vorher gelesen hat, könnte es noch besitzen. Es wird erst geschlossen, wenn ein Eigentümer oder Administrator bestätigt, was getan wurde:

• Geändert oder widerrufen;
• das Datum der Maßnahme;
• eine optionale Anmerkung.

Sicherheit protokolliert, wer die Bestätigung gab und wann, und zeigt dies bei der Erkennung an: "Geändert am 28. Oktober, bestätigt von Alex am 29. Oktober". Die Erkennung wird anschließend zu Geänderte Rotation bestätigt.

Ein gekapptes Geheimnis beheben#

Die Checkliste erstellen Erstellt im Projekt eine Aufgabe mit diesen Schritten:

1. Das Zugangsdatum beim Anbieter ändern oder widerrufen.
2. Es an den Ort verschieben, an dem das Projekt seine Geheimnisse speichert.
3. Es aus dem Code entfernen.
4. Die Rotation in Sicherheit bestätigen.

Die Aufgabe wiederholt sich nicht und versucht das Zugangsdatum nicht erneut. Sie schreibt die Git-Verlaufsgeschichte nicht um: Das Entfernen eines Zugangsdatums aus dem Verlauf ist eine Entscheidung Ihres Teams – es macht ein gekapptes Zugangsdatum dadurch nicht wieder sicher.

Echtes Zugangsdatum oder kein Problem#

Bei einer Geheimnis-Erkennung beantworten Eigentümer und Administratoren War dies ein echtes Zugangsdatum?

• Echtes Zugangsdatum hält die Erkennung offen, bis sie bestätigt wird.
• Kein Problem zeichnet eine Ausnahme für Fehlalarme auf, die die Erkennung ausblendet – zum Beispiel für einen Test-Fixture. Echtes Zugangsdatum entfernt diese Ausnahme wieder.

Diese Antworten helfen auch bei der Kalibrierung der Detektoren.

Blockieren#

Gekappte Geheimnisse arbeitet standardmäßig im Beobachtungsmodus. Es blockiert erst, wenn die Detektoren kalibriert wurden und die Durchsetzung aktiviert ist. Siehe Schutzmaßnahmen und Durchsetzung.

Bei Organisationen, die die frühere Geheimnis-Scans-Funktion in ihrer Organisationsrichtlinie aktiviert hatten, bleiben diese weiterhin durch die jeweilige Detektorenversion blockiert, bis die neuen Detektoren die Kalibrierung erfolgreich absolviert haben. Da der frühere Scan keine Ergebnisse erzeugt, können weder Ausnahmen noch Attestierungen das Verhalten der Blockade aufheben.

In der Organisationsvoreinstellung Neue Geheimnisse blockieren und die größten geänderten gescannten Elemente werden unter „Leckende Geheimnisse“ angezeigt.

Benachrichtigungen#

Geheimnis-Ergebnisse senden derzeit noch keine Benachrichtigungen. Sie werden in „Sicherheit → Ergebnisse“ und in der Übersicht angezeigt.

GitHub Geheimnis-Scans#

Ist für ein Repository die Geheimnis-Scans-Funktion von GitHub aktiviert, kann die Sicherheitsfunktion seine Alarme importieren. Ein Alarm der GitHub Geheimnis-Scans-Funktion bleibt offen, bis jemand ihn auf GitHub löst – das Zusammenführen einer Korrektur schließt ihn dort also nicht. Weitere Informationen finden Sie unter GitHub Sicherheitsalarme.