Konfiguration von Sourcegraph Cody Kontextfiltern zum Ausschluss sensibler Repositories aus dem KI-Kontext

Bei der unternehmensweiten Einführung des KI-gestützten Programmierassistenten Sourcegraph Cody stehen Engineering-Leiter sowie Sicherheits- und Compliance-Verantwortliche vor einer zentralen Governance-Frage: Wie lässt sich verlässlich verhindern, dass geschützte Algorithmen, Geschäftsgeheimnisse oder regulatorisch streng überwachte Repositories (etwa im Rahmen von PCI-DSS, HIPAA oder ITAR) als Kontext verpackt und an externe Large Language Models (LLMs) übertragen werden?

Sourcegraph Cody bietet hierfür einen zentralen, serverseitig erzwungenen Schutzmechanismus: die Cody Kontextfilter (cody.contextFilters). Dieses Feature wird direkt in der Sourcegraph Site-Konfiguration verwaltet und ermöglicht Administratoren die Definition präziser Einschluss- und Ausschlussregeln auf Basis von RE2-Regulären Ausdrücken. Dadurch wird auf Repository-Ebene festgelegt, auf welchen Code Cody für Autovervollständigungen, Chat-Antworten und Inline-Edits zugreifen darf.

Dieser Leitfaden führt Schritt für Schritt durch die Konfiguration von cody.contextFilters, erläutert die Auswertungslogik sowie die RE2-Syntax und zeigt Best Practices für ein mehrschichtiges Sicherheitskonzept im Unternehmen auf.

Voraussetzungen und Client-Kompatibilität

Bevor Kontextfilter konfiguriert werden, müssen Infrastruktur und Entwickler-Clients folgende Voraussetzungen erfüllen:

• Sourcegraph-Instanz: Sourcegraph Enterprise Version 5.4.0 oder höher mit einer gültigen Cody Enterprise-Lizenz.
• Feature Flag: Das Feature Flag cody-context-filters-enabled muss auf true gesetzt sein.
• Unterstützte Client-Versionen:
  • VS Code Extension: Version >= 1.20.0
  • JetBrains Plugin: Version >= 6.0.0
  • Sourcegraph Web-Client

Client-Kompatibilitätsmatrix und Richtliniendurchsetzung

Um zu verhindern, dass Entwickler durch veraltete IDE-Plugins Unternehmensrichtlinien umgehen, erzwingt Sourcegraph serverseitig die Einhaltung der Filtervorgaben:

Auf modernen Sourcegraph-Instanzen wird älteren Clients, die Kontextfilter nicht auswerten können, der Kontextzugriff konsequent verwehrt, wodurch Sicherheitslücken zuverlässig vermieden werden.

Konfigurationsschema und RE2-Syntax

Kontextfilter werden in der JSON-Struktur der Sourcegraph Site-Konfiguration unter der Haupteigenschaft cody.contextFilters hinterlegt. Das Schema akzeptiert zwei optionale Arrays: include (Positivliste) und exclude (Sperrliste).

{
  "cody.contextFilters": {
    "include": [
      {
        "repoNamePattern": "^github\\.com\\/example-corp\\/.*"
      }
    ],
    "exclude": [
      {
        "repoNamePattern": ".*-sensitive$"
      },
      {
        "repoNamePattern": "^github\\.com\\/example-corp\\/core-payments.*"
      }
    ]
  }
}

Wesentliche Schemaregeln:

• Sobald cody.contextFilters deklariert ist, muss mindestens ein Block (include oder exclude) definiert sein.
• Jedes Element innerhalb der Listen muss das erforderliche Attribut repoNamePattern enthalten.
• repoNamePattern erfordert zwingend die RE2-Syntax für reguläre Ausdrücke (die in Go implementierte Regular-Expression-Engine).
• Innerhalb von JSON-Strings müssen Backslashes doppelt maskiert werden (\\). Ein einfacher Punkt lautet beispielsweise \\., und Schrägstriche können als \\/ oder direkt als / geschrieben werden.
• Das Muster wird gegen den vollständigen, in Sourcegraph registrierten Repository-Namen abgeglichen (z. B. github.com/organization/repo-name oder interne GitLab-Pfade).

Auswertungslogik und Priorisierung

Die Arbeitsweise von Cody richtet sich nach der Kombination von Einschluss- und Ausschlussregeln:

1. Nicht definiert (Standardverhalten)

Wird cody.contextFilters weggelassen, hat Cody uneingeschränkten Zugriff auf den Kontext aller Repositories, für die der jeweilige Benutzer in Sourcegraph Leserechte besitzt.

2. Nur include-Regeln definiert (Strikte Whitelist)

Cody darf ausschließlich Repositories als Kontext heranziehen, deren Name auf mindestens ein Muster im include-Array zutrifft. Alle anderen Repositories sind standardmäßig gesperrt.

• Ideal für Organisationen mit einer Zero-Trust-Strategie für KI, bei der nur explizit freigegebene Bibliotheken und Standarddienste für AI-Assistenten freigeschaltet werden.
• Eine einzelne Übereinstimmung im include-Array genügt zur Autorisierung.

{
  "cody.contextFilters": {
    "include": [
      {
        "repoNamePattern": "^github\\.com\\/example-corp\\/frontend-.*"
      },
      {
        "repoNamePattern": "^github\\.com\\/example-corp\\/public-docs$"
      }
    ]
  }
}

3. Nur exclude-Regeln definiert (Blacklist)

Cody darf auf den Kontext jedes Repositories zugreifen, außer auf jene, deren Name mit mindestens einem Muster in exclude übereinstimmt.

• Geeignet für Unternehmen, die Entwicklerproduktivität auf breiter Basis fördern wollen, aber ausgewählte hochsensible Repositories (wie Handelsalgorithmen, kryptografische Tresore oder Gehaltsmodule) isolieren müssen.
• Ein Platzhalter wie .* in exclude fungiert als Notabschaltung (Kill-Switch) und blockiert den Kontextzugriff instanzweit.

{
  "cody.contextFilters": {
    "exclude": [
      {
        "repoNamePattern": "^github\\.com\\/example-corp\\/crypto-vault$"
      },
      {
        "repoNamePattern": ".*payment-processing.*"
      },
      {
        "repoNamePattern": ".*-restricted$"
      }
    ]
  }
}

4. Sowohl include als auch exclude definiert (Kombinierte Filterung)

Sind beide Arrays vorhanden, muss ein Repository zwei Bedingungen gleichzeitig erfüllen:

1. Der Name muss mindestens einem Muster in include entsprechen.
2. Der Name darf keinem Muster in exclude entsprechen.

Ausschlussregeln haben stets Vorrang vor Einschlussregeln. Im folgenden Beispiel sind alle Repositories unter example-corp erlaubt, ausgenommen Repositories, die compliance im Namen tragen oder auf -secret enden:

{
  "cody.contextFilters": {
    "include": [
      {
        "repoNamePattern": "^github\\.com\\/example-corp\\/.+"
      }
    ],
    "exclude": [
      {
        "repoNamePattern": ".*compliance.*"
      },
      {
        "repoNamePattern": ".*-secret$"
      }
    ]
  }
}

Schritt-für-Schritt-Anleitung für Administratoren

Gehen Sie wie folgt vor, um Kontextfilter in Ihrer Enterprise-Instanz einzurichten und zu testen:

Schritt 1: Namenskonventionen in Sourcegraph prüfen

Cody prüft die regulären Ausdrücke gegen den vollständigen Repository-Pfad in der Sourcegraph-Datenbank.

• Navigieren Sie im Web-Dashboard zu Site Admin > Repositories.
• Prüfen Sie die Host- und Organisations-Präfixe (z. B. github.com/meine-org/... oder interne GitLab-Domains).
• Erstellen Sie ein Verzeichnis aller schützenswerten Repositories und erarbeiten Sie die passenden RE2-Ausdrücke.

Schritt 2: Site-Konfiguration öffnen

1. Melden Sie sich mit Site-Admin-Rechten in Sourcegraph an.
2. Klicken Sie oben rechts auf Ihr Profil-Icon und wählen Sie Site Admin.
3. Klicken Sie im linken Navigationsmenü auf Configuration (unter /site-admin/configuration).

Schritt 3: cody.contextFilters einfügen

Ergänzen Sie das JSON-Objekt um den Schalter und die Filterkonfiguration:

{
  // ... weitere Instanzeinstellungen ...
  "cody-context-filters-enabled": true,
  "cody.contextFilters": {
    "include": [
      {
        "repoNamePattern": "^github\\.com\\/meine-org\\/.*"
      }
    ],
    "exclude": [
      {
        "repoNamePattern": "^github\\.com\\/meine-org\\/finanz-core$"
      },
      {
        "repoNamePattern": ".*proprietary.*"
      },
      {
        "repoNamePattern": ".*sec-tools.*"
      }
    ]
  }
}

Schritt 4: Änderungen speichern und anwenden

Klicken Sie unten auf Save changes. Sourcegraph übernimmt die Einstellungen im laufenden Betrieb, ohne dass ein Neustart der Serverdienste erforderlich ist.

Schritt 5: Funktionsprüfung auf Entwicklerrechnern

Testen Sie die Richtlinienwirksamkeit in einer IDE-Umgebung:

1. Öffnen Sie in VS Code oder JetBrains ein Projekt aus einem ausgeschlossenen Repository.
2. Starten Sie einen Inline-Edit oder einen Code-Generierungsbefehl. Die Erweiterung bricht die Ausführung ab und meldet:

   Edit failed to run: file is ignored (due to cody.contextFilters Enterprise configuration setting)
   

3. Versuchen Sie im Cody Chat, Dateien oder Symbole aus dem gesperrten Repository mittels @-mention einzubinden. Diese tauchen nicht in den Vorschlägen auf und Cody übermittelt keine Code-Auszüge an das Sprachmodell.

Entwickler-Workflows und Funktionseinschränkungen

Ein klares Verständnis über das Verhalten in gesperrten Repositories erleichtert die Kommunikation mit den Entwicklungsteams:

• Allgemeiner Chat bleibt aktiv: Auch innerhalb eines ausgeschlossenen Projekts können Entwickler Cody Chat für allgemeine Syntaxfragen, Algorithmen oder öffentliche Frameworks nutzen. Der lokale Code wird dabei schlicht nicht in den Prompt-Kontext eingebettet.
• Kontextbasierte Prompt-Templates eingeschränkt: Vordefinierte Prompts, die zwingend projektweiten Kontext erfordern, schlagen in gesperrten Repositories fehl oder werden deaktiviert.
• Autovervollständigung (Autocomplete) gestoppt: Befindet sich der Cursor in einer Datei eines gesperrten Repositories, wird kein umgebender Code an die Inferenz-Server gesendet.

Mehrschichtige Governance: Kontrollmechanismen im Vergleich

Ein wirksamer Schutz vor Quellcode-Abfluss setzt auf Defense-in-Depth. Die folgende Übersicht verdeutlicht das Zusammenspiel der Mechanismen:

Durch die zentrale Durchsetzung von cody.contextFilters in Kombination mit .cody/ignore für lokale Geheimnisse und den vertraglichen Garantien von Cody Gateway schaffen Unternehmen einen verlässlichen Schutzraum, um Entwicklerteams produktiv mit generativer KI arbeiten zu lassen, ohne sensible Assets zu gefährden.

Referenzen

• Manage Cody Context - Sourcegraph docs
• Cody Enterprise features - Sourcegraph docs
• Cody FAQs - Sourcegraph docs