Detector-BibliothekRepository-Konfigurations-Ausführung

Repository-Konfigurations-Ausführung

Das Checkout benennt ein Programm.

Ausführbare Konfiguration finden, die ein normaler Tool-Aufruf verbergen kann.

Das Problem erkennen. Den Befund verstehen.

Englische Kommentierung mit Untertiteln.

Wie es übersehen wird

Der Agent führt einen gewöhnlichen Entwicklungsbefehl aus. Aber die Repository-Konfiguration verweist auf eigenen Code. Allein den sichtbaren Tool-Namen zu prüfen kann die Konfiguration übersehen, die das eigentliche Geschehen beeinflusst.

Ein Checkout kann Git auf Hooks im Arbeitsverzeichnis verweisen, befehlswertige Einstellungen konfigurieren oder Editor-Aufgaben einschließen, die beim Öffnen des Ordners ausgeführt werden. Diese Dateien verdienen eine Prüfung, bevor du den Arbeitsbereich als passive Quellcode-Sammlung behandelst.

Was ClawMetry erkennt

ClawMetry durchsucht unterstützte Workspace-Konfiguration nach ausführungsbezogenen Einstellungen. Es meldet den relevanten Schlüssel oder die Konfigurationsquelle und verwendet bekannte sichere Befehlsformen, um Rauschen zu reduzieren. Dieser Detektor liest das Checkout selbst, anstatt sich nur auf den Agent-Tool-Stream zu verlassen.

Der Unterschied, der den Befund verändert

Auslösendes Beispiel

hooksPath = .githooks

Kritischer Befund

Stilles Vergleichsbeispiel

Standard-.git/hooks-Pfad

Kein Befund für diesen Detector.

Das geprüfte Beispiel verweist Git-Hooks auf ein im Arbeitsverzeichnis enthaltenes Verzeichnis und erzeugt einen kritischen Befund. Ein Hooks-Pfad, der auf das Standard-Git-Hooks-Verzeichnis zeigt, bleibt still. Der Befund identifiziert Konfiguration, die Code benennt, keinen aufgezeichneten Aufruf dieses Codes.

Detector-Ergebnis prüfen
{
  "kind": "repo_config_exec",
  "severity": "critical",
  "evidence": {
    "keys": [
      "core.hookspath"
    ],
    "hits": [
      {
        "key": "core.hookspath",
        "command": ".githooks",
        "line": 2,
        "manager": null
      }
    ],
    "config": ".git/config",
    "observed": "repository_config"
  }
}
Eingaben und vollständige Ergebnisse herunterladen (JSON)
Wie das Beispiel geprüft wurde

Diese Beispiele werten den veröffentlichten Detector mit selbst erstellten Ereignisdaten oder einmalig verwendeten Konfigurationsdateien aus. Die Videos veranschaulichen dieses Verhalten. Es sind keine Aufzeichnungen von Live-Agents oder der Produktoberfläche. Kein Befehl in den Beispielen wurde ausgeführt.

Das Ergebnis beschreibt das Verhalten für diese Eingaben. Es belegt weder Laufzeit-Ingestion, Prävention noch einen echten Kompromittierungsfall. Festgelegten Quellvertrag prüfen.

Was als nächstes zu prüfen ist

Prüfe die Einstellung, die referenzierten Dateien und den Ursprung des Checkouts. Entscheide, ob diese Programme erwartet werden, bevor du gewöhnliche Entwicklungsoperationen zulässt. Wenn ein Tool bereits ausgeführt wurde, untersuche seine Auswirkungen separat anhand der auf dem Rechner verfügbaren Beweise.

  1. Konfigurationsschlüssel prüfen
  2. Referenzierten Code prüfen
  3. Ursprung des Repositorys prüfen

Was dieses Signal belegt

Der Scanner meldet Konfiguration, keine Ausführung. Er beweist nicht, dass ein konfiguriertes Programm ausgeführt wurde oder dass der Autor Schaden beabsichtigte.

Die wichtigen Momente sichtbar halten.

Agent-Aktivität verfolgen, Befunde prüfen und entscheiden, was Ihre Aufmerksamkeit erfordert.