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.
- Konfigurationsschlüssel prüfen
- Referenzierten Code prüfen
- 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.