Cycode

offiziell

Steigern Sie die Sicherheit in Ihrem Entwicklungslebenszyklus durch SAST-, SCA-, Secrets- und IaC-Scans mit Cycode.

Was kann man mit Cycode MCP machen?

Nach Geheimnissen suchen — Bitte den Assistenten, Dateien oder Verzeichnisse mit cycode_secret_scan auf fest codierte Geheimnisse zu überprüfen.
Nach SCA-Problemen suchen — Fordere mit cycode_sca_scan eine Software-Composition-Analysis-Prüfung auf Schwachstellen und Lizenzprobleme an.
Nach IaC-Fehlkonfigurationen suchen — Bitte den Assistenten, Infrastructure as Code mit cycode_iac_scan auf Fehlkonfigurationen zu überprüfen.
Nach SAST-Problemen suchen — Führe mit cycode_sast_scan eine Static-Application-Security-Testing-Prüfung auf Probleme mit der Codequalität und Sicherheitslücken durch.
CLI-Status prüfen — Frage mit cycode_status die Version der Cycode CLI, den Authentifizierungsstatus und Konfigurationsdetails ab.

Dokumentation

Cycode CLI-Benutzerhandbuch

Die Cycode Command Line Interface (CLI) ist eine Anwendung, die Sie lokal installieren können, um Ihre Repositorys auf Geheimnisse, Fehlkonfigurationen in Infrastructure as Code, Schwachstellen in der Software Composition Analysis und Probleme beim Static Application Security Testing zu überprüfen.

Diese Anleitung führt Sie durch die Installation und Verwendung.

Inhaltsverzeichnis

Voraussetzungen
Installation
1. Cycode CLI installieren
2. Pre-Commit-Hook installieren
Cycode-CLI-Befehle
Zertifikate und Proxys
MCP-Befehl
Platform-Befehl
AI Guardrails
1. Von AI Guardrails erfasste Daten
Scan-Befehl
Report-Befehl
1. SBOM-Bericht erstellen
Import-Befehl
Scan-Protokolle
Syntaxhilfe

Voraussetzungen

Für die Cycode-CLI-Anwendung ist Python Version 3.10 oder höher erforderlich.
Verwenden Sie den Befehl cycode auth, um sich mit der CLI bei Cycode zu authentifizieren.
- Alternativ können Sie eine Cycode Client ID und einen Client Secret Key erhalten, indem Sie die Schritte auf den Seiten Service Account Token und Personal Access Token befolgen. Dort erfahren Sie, wie Sie diese Werte erhalten.

Installation

Die folgenden Installationsschritte gelten sowohl für Windows als auch für UNIX-/Linux-Betriebssysteme.

[!NOTE] Bei den folgenden Schritten wird davon ausgegangen, dass Sie für Python-bezogene Befehle python3 und pip3 verwenden. Je nach Konfiguration Ihrer Python-Umgebung können manche Systeme stattdessen die Befehle python und pip verwenden.

Cycode CLI installieren

Führen Sie die folgenden Schritte aus, um die Cycode-CLI-Anwendung auf Ihrem lokalen Rechner zu installieren:

Öffnen Sie Ihre Befehlszeilen- oder Terminalanwendung.
Führen Sie einen der folgenden Befehle aus:
- So installieren Sie das Paket von PyPI:
```
pip3 install cycode
```
- So installieren Sie das Paket von Homebrew:
```
brew install cycode
```
- Navigieren Sie für die Installation von GitHub Releases dorthin und laden Sie die ausführbare Datei für Ihr Betriebssystem und Ihre Architektur herunter. Führen Sie anschließend den folgenden Befehl aus:
```
cd /path/to/downloaded/cycode-cli
chmod +x cycode
./cycode
```
Authentifizieren Sie abschließend die CLI. Es gibt drei Möglichkeiten, die Cycode-Client-ID und die Anmeldedaten (Client Secret oder OIDC-ID-Token) festzulegen:
- cycode auth (Empfohlen)
- cycode configure
- Fügen Sie sie Ihren Umgebungsvariablen hinzu.

Mit dem Auth-Befehl

[!NOTE] Dies ist die empfohlene Methode, um Ihren lokalen Rechner für die Authentifizierung bei der Cycode CLI einzurichten.

Geben Sie den folgenden Befehl in Ihr Terminal- bzw. Befehlszeilenfenster ein:

cycode auth
Ein Browserfenster wird geöffnet und fordert Sie auf, sich bei Cycode anzumelden (siehe unten):
Geben Sie auf dieser Seite Ihre Anmeldedaten ein und melden Sie sich an.
Anschließend gelangen Sie zur unten gezeigten Seite, auf der Sie die Business Group auswählen, für die Sie Cycode autorisieren möchten (falls zutreffend):

[!NOTE] Diese Methode wird standardmäßig für die Authentifizierung mit der Cycode CLI verwendet.
Klicken Sie auf Allow, um die Cycode CLI für die ausgewählte Business Group zu autorisieren.
Nach erfolgreichem Abschluss wird der folgende Bildschirm angezeigt:
Im Terminal- bzw. Befehlszeilenfenster wird beim Schließen des Browserfensters Folgendes angezeigt:

Successfully logged into cycode

Mit dem Configure-Befehl

[!NOTE] Wenn Sie Ihre Cycode Client ID und Ihr Client Secret bereits über die Linux- oder Windows-Umgebungsvariablen eingerichtet haben, haben diese Anmeldedaten Vorrang vor dieser Methode.

Geben Sie den folgenden Befehl in Ihr Terminal- bzw. Befehlszeilenfenster ein:
```
cycode configure
```
Geben Sie den Wert Ihrer Cycode API URL ein (Sie können das Feld leer lassen, um den Standardwert zu verwenden).

Cycode API URL [https://api.cycode.com]: https://api.onpremise.com
Geben Sie den Wert Ihrer Cycode APP URL ein (Sie können das Feld leer lassen, um den Standardwert zu verwenden).

Cycode APP URL [https://app.cycode.com]: https://app.onpremise.com
Geben Sie den Wert Ihrer Cycode Client ID ein.

Cycode Client ID []: 7fe5346b-xxxx-xxxx-xxxx-55157625c72d
Geben Sie den Wert Ihres Cycode Client Secret ein (überspringen Sie diesen Schritt, wenn Sie ein OIDC-ID-Token verwenden möchten).

Cycode Client Secret []: c1e24929-xxxx-xxxx-xxxx-8b08c1839a2e
Geben Sie den Wert Ihres Cycode OIDC ID Token ein (optional).

Cycode ID Token []: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Wenn die Werte erfolgreich eingegeben wurden, wird die folgende Meldung angezeigt:

Successfully configured CLI credentials!

oder/und

Successfully configured Cycode URLs!

Wenn Sie den Ordner .cycode in Ihrem Benutzerordner öffnen, finden Sie die erstellten Anmeldedaten in der Datei credentials.yaml in diesem Ordner. Die URLs wurden in der Datei config.yaml in diesem Ordner gespeichert.

Zu den Umgebungsvariablen hinzufügen

Unter Unix/Linux:

export CYCODE_CLIENT_ID={your Cycode ID}

und

export CYCODE_CLIENT_SECRET={your Cycode Secret Key}

Wenn Ihre Organisation OIDC-Authentifizierung verwendet, können Sie stattdessen (oder zusätzlich) das ID-Token angeben:

export CYCODE_ID_TOKEN={your Cycode OIDC ID token}

Unter Windows

Navigieren Sie in der Systemsteuerung zum Menü „System“:
Klicken Sie anschließend auf „Erweiterte Systemeinstellungen“:
Klicken Sie im geöffneten Fenster „Systemeigenschaften“ auf die Schaltfläche „Umgebungsvariablen“:
Erstellen Sie die Variablen CYCODE_CLIENT_ID und CYCODE_CLIENT_SECRET mit den Werten Ihrer ID bzw. Ihres Secret Keys. Wenn Sie sich über OIDC authentifizieren, fügen Sie außerdem CYCODE_ID_TOKEN mit dem Wert Ihres OIDC-ID-Tokens hinzu:
Fügen Sie cycode.exe zum Pfad hinzu, um die Installation abzuschließen.

Pre-Commit-Hook installieren

Die Pre-Commit- und Pre-Push-Hooks von Cycode können in Ihrem lokalen Repository eingerichtet werden. Dadurch erkennt die Cycode-CLI-Anwendung automatisch Probleme in Ihrem Code, bevor Sie ihn committen oder in Ihre Codebasis pushen.

[!NOTE] Pre-Commit- und Pre-Push-Hooks sind für IaC-Scans nicht verfügbar.

Führen Sie die folgenden Schritte aus, um den Pre-Commit-Hook zu installieren:

Pre-Commit-Hook installieren

Installieren Sie das Pre-Commit-Framework (Python 3.10 oder höher muss installiert sein):
```
pip3 install pre-commit
```
Navigieren Sie zum Stammverzeichnis des lokalen Git-Repositorys, das Sie konfigurieren möchten.
Erstellen Sie im Stammverzeichnis des Repositorys eine neue YAML-Datei mit dem Namen .pre-commit-config.yaml (einschließlich des vorangestellten .), die Folgendes enthält:
```
repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode
        stages: [pre-commit]
```
Passen Sie die erstellte Datei an Ihre Anforderungen an. Verwenden Sie die Hook-ID cycode, um den Scan auf Secrets zu aktivieren. Verwenden Sie die Hook-ID cycode-sca, um den SCA-Scan zu aktivieren. Verwenden Sie die Hook-ID cycode-sast, um den SAST-Scan zu aktivieren. Wenn Sie alle Scan-Typen aktivieren möchten, verwenden Sie diese Konfiguration:
```
repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode
        stages: [pre-commit]
      - id: cycode-sca
        stages: [pre-commit]
      - id: cycode-sast
        stages: [pre-commit]
```
Installieren Sie den Hook von Cycode:
```
pre-commit install
```
Bei erfolgreicher Installation des Hooks wird die Meldung Pre-commit installed at .git/hooks/pre-commit angezeigt.
Halten Sie den Pre-Commit-Hook auf dem neuesten Stand:
```
pre-commit autoupdate
```
Dadurch wird rev in .pre-commit-config.yaml automatisch auf die neueste verfügbare Version der Cycode CLI aktualisiert.

[!NOTE] Der Hook wird beim Befehl git commit ausgelöst. Der Hook wird nur für Dateien ausgelöst, die für den Commit bereitgestellt wurden.

Pre-Push-Hook installieren

So installieren Sie zusätzlich zum oder anstelle des Pre-Commit-Hooks den Pre-Push-Hook:

Fügen Sie die Pre-Push-Hooks zu Ihrer Datei .pre-commit-config.yaml hinzu:

repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode-pre-push
        stages: [pre-push]

Installieren Sie den Pre-Push-Hook:

pre-commit install --hook-type pre-push

Verwenden Sie für Pre-Commit- und Pre-Push-Hooks Folgendes:

pre-commit install
pre-commit install --hook-type pre-push

[!NOTE] Pre-Push-Hooks werden beim Befehl git push ausgelöst und scannen nur die Commits, die gepusht werden sollen.

Cycode-CLI-Befehle

Im Folgenden finden Sie die verfügbaren Optionen und Befehle der Cycode-CLI-Anwendung:

Option	Beschreibung
`-v`, `--verbose`	Detaillierte Protokolle anzeigen.
`--no-progress-meter`	Fortschrittsanzeige nicht anzeigen.
`--no-update-notifier`	Nicht nach CLI-Updates suchen.
`-o`, `--output [rich\|text\|json\|table]`	Ausgabetyp angeben. Der Standardwert ist `rich`.
`--client-id TEXT`	Eine Cycode-Client-ID für diese spezifische Scan-Ausführung angeben.
`--client-secret TEXT`	Ein Cycode-Client-Secret für diese spezifische Scan-Ausführung angeben.
`--id-token TEXT`	Ein Cycode-OIDC-ID-Token für diese spezifische Scan-Ausführung angeben.
`--install-completion`	Vervollständigung für die aktuelle Shell installieren.
`--show-completion [bash\|zsh\|fish\|powershell\|pwsh]`	Vervollständigung für die angegebene Shell anzeigen, damit sie kopiert oder die Installation angepasst werden kann.
`-h`, `--help`	Optionen für den angegebenen Befehl anzeigen.
Befehl	Beschreibung
-------------------------------------------	----------------------------------------------------------------------------------------------------------------------------------------------
auth	Authentifiziert Ihren Computer, um die CLI mit Ihrem Cycode-Konto zu verknüpfen.
configure	Erster Befehl zum Konfigurieren der Authentifizierung Ihres CLI-Clients.
ignore	Ignoriert einen bestimmten Wert, Pfad oder eine Regel-ID.
mcp	Startet den Model Context Protocol (MCP)-Server, um die KI-Integration mit den Scan-Funktionen von Cycode zu ermöglichen.
scan	Scannt den Inhalt auf Verstöße gegen Secrets/IaC/SCA/SAST. Sie müssen angeben, welcher Scantyp ausgeführt werden soll: commit-history/path/repository/etc.
report	Erstellt einen Bericht. Sie müssen angeben, welcher Berichtstyp erstellt werden soll, z. B. SBOM.
status	Zeigt den CLI-Status an und beendet das Programm.

Zertifikate und Proxys

Standardmäßig überprüft die Cycode CLI HTTPS-Verbindungen anhand des mit der CLI ausgelieferten CA-Bundles.

Wenn Ihre Organisation einen Proxy verwendet, der HTTPS-Datenverkehr untersucht, oder eine lokale Installation mit einer eigenen CA, haben Sie zwei Möglichkeiten.

Option 1 — die bereits auf dem Computer installierten Zertifikate verwenden. Wenn sich Ihre CA im Zertifikatspeicher des Computers befindet (wie es bei verwalteten Geräten normalerweise der Fall ist), aktivieren Sie diese Option:

export CYCODE_CLI_ENABLE_TRUSTSTORE=1

Die CLI überprüft dann anhand des Windows-Zertifikatspeichers, des macOS-Schlüsselbunds oder des System-CA-Verzeichnisses unter Linux. Zertifikatspfade müssen nicht konfiguriert werden.

[!IMPORTANT] Diese Option muss bewusst aktiviert werden. Dem Zertifikatspeicher des Computers zu vertrauen bedeutet, jedem dort vorhandenen Stammzertifikat zu vertrauen, einschließlich aller Zertifikate, die ein Administrator oder schädliche Software installiert hat. Aktivieren Sie diese Option nur, wenn Sie dem Zertifikatspeicher Ihres Computers vertrauen.

Option 2 — die CLI auf eine CA-Bundle-Datei verweisen lassen. Funktioniert ohne Aktivierung:

Umgebungsvariable	Beschreibung
`REQUESTS_CA_BUNDLE`	Pfad zu einer CA-Bundle-Datei (`.pem` oder `.crt`), der vertraut werden soll.
`CURL_CA_BUNDLE`	Alias für `REQUESTS_CA_BUNDLE`, wird verwendet, wenn Letzteres nicht gesetzt ist.

Die beiden Optionen lassen sich kombinieren: Mit CYCODE_CLI_ENABLE_TRUSTSTORE=1 werden Zertifikate aus REQUESTS_CA_BUNDLE zusätzlich zum Zertifikatspeicher des Computers vertraut, nicht an dessen Stelle.

[!TIP] Führen Sie einen beliebigen Befehl mit -v aus, um zu sehen, welche Vertrauensquelle verwendet wird, zum Beispiel cycode -v status.

Hinweise:

Unter Windows hat die CLI schon immer auf den Systemzertifikatspeicher zurückgegriffen, wenn weder REQUESTS_CA_BUNDLE noch CURL_CA_BUNDLE gesetzt ist. Dieses Verhalten bleibt unverändert.
Proxys selbst werden mit den standardmäßigen Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY konfiguriert.

MCP-Befehl [EXPERIMENT]

Mit dem Model Context Protocol (MCP)-Befehl können Sie einen MCP-Server starten, der die Scan-Funktionen von Cycode für KI-Systeme und Anwendungen bereitstellt. Dadurch können KI-Modelle über ein standardisiertes Protokoll mit den Cycode-CLI-Tools interagieren.

[!TIP] Für eine optimale Nutzung installieren Sie die Cycode CLI global auf Ihrem System mit pip install cycode oder brew install cycode und authentifizieren Sie sich anschließend einmalig mit cycode auth. Nach der globalen Installation und Authentifizierung müssen Sie die Umgebungsvariablen CYCODE_CLIENT_ID und CYCODE_CLIENT_SECRET nicht mehr in Ihren MCP-Konfigurationsdateien einrichten.

MCP-Server starten

Starten Sie den MCP-Server mit folgendem Befehl:

cycode mcp

Standardmäßig wird der Server mit dem Transport stdio gestartet. Dieser eignet sich für lokale Integrationen und KI-Anwendungen, die Unterprozesse starten können.

Verfügbare Optionen

Option	Beschreibung
`-t, --transport`	Transporttyp für den MCP-Server: `stdio`, `sse` oder `streamable-http` (Standard: `stdio`)
`-H, --host`	Hostadresse, an die der Server gebunden wird (nur bei Nicht-stdio-Transport verwendet) (Standard: `127.0.0.1`)
`-p, --port`	Portnummer, an die der Server gebunden wird (nur bei Nicht-stdio-Transport verwendet) (Standard: `8000`)
`--help`	Hilfemeldung und verfügbare Optionen anzeigen

MCP-Tools

Der MCP-Server stellt die folgenden Tools bereit, die KI-Systeme verwenden können:

Toolname	Beschreibung
`cycode_secret_scan`	Nach fest codierten Secrets suchen
`cycode_sca_scan`	Software Composition Analysis (SCA) ausführen – Schwachstellen und Lizenzprobleme suchen
`cycode_iac_scan`	Infrastructure-as-Code-Fehlkonfigurationen (IaC) suchen
`cycode_sast_scan`	Static Application Security Testing (SAST) ausführen – Codequalitäts- und Sicherheitsmängel suchen
`cycode_status`	Cycode-CLI-Version, Authentifizierungsstatus und Konfigurationsinformationen abrufen

Jedes Scan-Tool akzeptiert zwei sich gegenseitig ausschließende Eingabemodi:

paths (bevorzugt) — ein oder mehrere Datei- oder Verzeichnispfade, die auf dem Datenträger vorhanden sind. Verzeichnisse werden rekursiv gescannt. Die Cycode-Engine übernimmt die Dateisuche und Filterung, genau wie cycode scan -t <type> path ./src über die CLI.
files (Ausweichoption) — ein Wörterbuch, das Dateipfade ihren vollständigen Inhalten als Zeichenfolgen zuordnet. Verwenden Sie diese Option nur, wenn die Dateien nicht auf dem Datenträger verfügbar sind (z. B. noch nicht gespeicherte Änderungen im Arbeitsspeicher).

[!TIP] Verwenden Sie nach Möglichkeit paths. Die Übergabe großer Dateien (wie package-lock.json) als Inline-Inhalt kann Token-Limits überschreiten und den KI-Client verlangsamen. Mit paths liest die Cycode-Engine Dateien direkt vom Datenträger.

Alle Scan-Tools geben ein JSON-Objekt zurück, das zusätzlich zum vollständigen Array "detections" ein Feld "summary" mit einer für Menschen lesbaren Anzahl von Verstößen enthält (z. B. "Cycode found 3 violations: 1 CRITICAL, 2 HIGH.").

Anwendungsbeispiele

Grundlegende Befehlsbeispiele

MCP-Server mit Standardeinstellungen starten (stdio-Transport):

cycode mcp

MCP-Server mit explizitem stdio-Transport starten:

cycode mcp -t stdio

MCP-Server mit Server-Sent-Events-Transport (SSE) starten:

cycode mcp -t sse -p 8080

MCP-Server mit streamable HTTP-Transport auf einem benutzerdefinierten Host und Port starten:

cycode mcp -t streamable-http -H 0.0.0.0 -p 9000

Weitere Informationen zu MCP-Transporttypen finden Sie in der MCP-Protokollspezifikation – Transports.

Konfigurationsbeispiele

MCP mit Cursor/VS Code/Claude Desktop usw. verwenden (mcp.json)

[!NOTE] Achten Sie bei EU-Cycode-Umgebungen darauf, die passenden Werte für CYCODE_API_URL und CYCODE_APP_URL in den Umgebungsvariablen festzulegen (z. B. https://api.eu.cycode.com und https://app.eu.cycode.com).

Folgen Sie dieser Anleitung, um den MCP-Server in VS Code/GitHub Copilot zu konfigurieren. Beachten Sie, dass settings.json ein Objekt mcp mit einem verschachtelten Unterobjekt servers enthält und nicht ein eigenständiges Objekt mcpServers.

Für stdio-Transport (direkte Ausführung):

{
  "mcpServers": {
    "cycode": {
      "command": "cycode",
      "args": ["mcp"],
      "env": {
        "CYCODE_CLIENT_ID": "your-cycode-id",
        "CYCODE_CLIENT_SECRET": "your-cycode-secret-key",
        "CYCODE_API_URL": "https://api.cycode.com",
        "CYCODE_APP_URL": "https://app.cycode.com"
      }
    }
  }
}

Für stdio-Transport mit pipx-Installation:

{
  "mcpServers": {
    "cycode": {
      "command": "pipx",
      "args": ["run", "cycode", "mcp"],
      "env": {
        "CYCODE_CLIENT_ID": "your-cycode-id",
        "CYCODE_CLIENT_SECRET": "your-cycode-secret-key",
        "CYCODE_API_URL": "https://api.cycode.com",
        "CYCODE_APP_URL": "https://app.cycode.com"
      }
    }
  }
}

Für stdio-Transport mit uvx-Installation:

{
  "mcpServers": {
    "cycode": {
      "command": "uvx",
      "args": ["cycode", "mcp"],
      "env": {
        "CYCODE_CLIENT_ID": "your-cycode-id",
        "CYCODE_CLIENT_SECRET": "your-cycode-secret-key",
        "CYCODE_API_URL": "https://api.cycode.com",
        "CYCODE_APP_URL": "https://app.cycode.com"
      }
    }
  }
}

Für SSE-Transport (Server-Sent-Events):

{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8000/sse"
    }
  }
}

Für SSE-Transport auf einem benutzerdefinierten Port:

{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8080/sse"
    }
  }
}

Für streamable HTTP-Transport:

{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8000/mcp"
    }
  }
}

MCP-Server im Hintergrund ausführen

Für SSE-Transport (zuerst den Server starten, dann den Client konfigurieren):

# Start the MCP server in the background
cycode mcp -t sse -p 8000 &

# Configure in mcp.json
{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.1:8000/sse"
    }
  }
}

Für streamable HTTP-Transport:

# Start the MCP server in the background
cycode mcp -t streamable-http -H 127.0.0.2 -p 9000 &

# Configure in mcp.json
{
  "mcpServers": {
    "cycode": {
      "url": "http://127.0.0.2:9000/mcp"
    }
  }
}

Erweiterte Konfiguration

Timeouts und benutzerdefinierte Zertifikate (Proxy-Umgebungen)

Wenn Ihr MCP-Client lang laufende Scans vorzeitig abbricht, erhöhen Sie das Timeout für Tool-Aufrufe.

Umgebungsvariable	Beschreibung
`MCP_TOOL_TIMEOUT`	Timeout (in Sekunden), das MCP-Clients wie Claude und GitHub Copilot auf den Abschluss eines Tool-Aufrufs warten. Erhöhen Sie diesen Wert, wenn lang laufende Scans vor ihrem Abschluss abgebrochen werden.

Hinter einem Unternehmensproxy legen Sie die Zertifikatsvariablen im Block env des MCP-Servers fest. Unter Zertifikate und Proxys finden Sie die Optionen: entweder CYCODE_CLI_ENABLE_TRUSTSTORE=1, um die bereits auf dem Computer vorhandenen Zertifikate zu verwenden, oder REQUESTS_CA_BUNDLE, um auf eine CA-Bundle-Datei zu verweisen.

Beispiel für eine mcp.json-Konfiguration mit einem benutzerdefinierten CA-Bundle und einem längeren Timeout:

{
  "mcpServers": {
    "cycode": {
      "command": "cycode",
      "args": ["mcp"],
      "env": {
        "REQUESTS_CA_BUNDLE": "/path/to/your/corporate-ca-bundle.pem",
        "MCP_TOOL_TIMEOUT": "1800"
      }
    }
  }
}

[!NOTE] Für den MCP-Server ist eine ordnungsgemäße Authentifizierung der Cycode CLI erforderlich. Stellen Sie sicher, dass Sie sich mit cycode auth authentifiziert oder Ihre Anmeldedaten konfiguriert haben, bevor Sie den MCP-Server starten.

Tools für Subagenten vorab autorisieren (Claude Code)

Wenn Claude Code Aufgaben an Hintergrund-Subagenten delegiert (z. B. um Scans parallel auszuführen), können diese Subagenten keine interaktiven Berechtigungsabfragen anzeigen. Wenn die Cycode-Tools nicht vorab genehmigt wurden, schlagen Scans im Kontext von Subagenten unbemerkt fehl.

Um die Cycode-MCP-Tools vorab zu autorisieren, damit sie in allen Kontexten einschließlich Subagenten funktionieren, fügen Sie sie der Liste allowedTools in Ihren Claude-Code-Einstellungen (~/.claude/settings.json) hinzu:

{
  "allowedTools": [
    "mcp__cycode__cycode_secret_scan",
    "mcp__cycode__cycode_sca_scan",
    "mcp__cycode__cycode_iac_scan",
    "mcp__cycode__cycode_sast_scan",
    "mcp__cycode__cycode_status"
  ]
}

Nach dem Hinzufügen fragt Claude Code bei Aufrufen dieser Tools nicht mehr nach einer Genehmigung. Sie funktionieren dann auch in Subagenten korrekt.

MCP-Fehlerbehebung

Wenn Probleme mit dem MCP-Server auftreten, können Sie die Debug-Protokollierung aktivieren, um detailliertere Informationen zu den Vorgängen zu erhalten. Dafür gibt es zwei Möglichkeiten:

Mit dem Flag -v oder --verbose:

cycode -v mcp

Mit der Umgebungsvariable CYCODE_CLI_VERBOSE:

CYCODE_CLI_VERBOSE=1 cycode mcp

Die Debug-Protokolle enthalten detaillierte Informationen zu:

Serverstart und Konfiguration
Verbindungsversuchen und Status
Tool-Ausführung und Ergebnissen
Auftretenden Fehlern oder Warnungen

Diese Informationen können hilfreich sein, um:

Verbindungsprobleme zu diagnostizieren
Zu verstehen, warum bestimmte Tools nicht funktionieren
Authentifizierungsprobleme zu erkennen
Transportbezogene Probleme zu beheben

MCP-Konfiguration

Platform-Befehl [BETA]

[!WARNING] Der Befehl platform befindet sich in der Beta-Phase. Befehle, Argumente und Ausgabeformate werden dynamisch anhand der Cycode-API-Spezifikation generiert und können sich zwischen Releases ohne Vorankündigung ändern. Verlassen Sie sich daher noch nicht in Produktionsautomatisierungen darauf.

Der Befehl cycode platform stellt die Lese-APIs der Cycode-Plattform als CLI-Befehle bereit. Er gruppiert Endpunkte nach Ressource (z. B. projects, violations, workflows) und wandelt die Parameter jedes Endpunkts in typisierte CLI-Argumente und --option-Flags um.

cycode platform projects list --page-size 50
cycode platform violations count
cycode platform workflows view <workflow-id>

Die OpenAPI-Spezifikation wird bei der ersten Verwendung von der Cycode-API abgerufen und 24 Stunden lang unter ~/.cycode/openapi-spec.json zwischengespeichert. Nicht zugehörige Befehle (cycode scan, cycode status usw.) lösen keinen Abruf aus.

[!NOTE] Sie müssen authentifiziert sein (cycode auth oder die Umgebungsvariablen CYCODE_CLIENT_ID / CYCODE_CLIENT_SECRET), damit cycode platform Befehle erkennen und ausführen kann. Andere Cycode CLI-Befehle funktionieren ohne Authentifizierung.

Befehle erkennen

Da Befehle aus der Spezifikation generiert werden, ist --help die maßgebliche Quelle für verfügbare Befehle:

cycode platform --help                  # list all resource groups
cycode platform projects --help         # list actions on a resource
cycode platform projects list --help    # list options/arguments for an action

Plattformbeispiele

# List projects with pagination
cycode platform projects list --page-size 25

# View a single project by ID
cycode platform projects view <project-id>

# Count violations across the tenant
cycode platform violations count

# Filter using query parameters (see `--help` for what each endpoint supports)
cycode platform violations list --severity CRITICAL

Die Ausgabe erfolgt standardmäßig im JSON-Format — leiten Sie sie zur Ad-hoc-Filterung durch jq:

cycode platform projects list --page-size 100 | jq '.items[].name'

Hinweise und Einschränkungen zur Plattform

Derzeit schreibgeschützt. In dieser Betaversion werden nur GET-Endpunkte bereitgestellt.
Spezifikationsgesteuert. Wird der API ein neuer Endpunkt hinzugefügt, ist er automatisch verfügbar, sobald der Cache das nächste Mal aktualisiert wird.
Keine gebündelte Spezifikation. Beim ersten Aufruf von cycode platform nach der Installation (oder nach Ablauf des 24-Stunden-Cache) wird die Spezifikation aus dem Netzwerk abgerufen. Bei langsamen Verbindungen kann dieser erste Aufruf einige Sekunden dauern; nachfolgende Aufrufe erfolgen bis zum Ablauf des Cache nahezu sofort.
Cache-TTL überschreiben mit CYCODE_SPEC_CACHE_TTL=<seconds>.

AI Guardrails [BETA]

AI Guardrails installiert Hooks in unterstützten KI-Coding-Agenten (Claude Code, Cursor, Copilot, Codex), damit Prompts, vom Agenten gelesene Dateien und MCP-Tool-Argumente auf Geheimnisse überprüft werden, bevor sie das Modell erreichen.

Von AI Guardrails erfasste Daten

Die Überprüfung erfolgt serverseitig, daher verlassen die überprüften Inhalte den Rechner: Der Prompt-Text, die Inhalte der vom Agenten gelesenen Dateien und die MCP-Tool-Argumente werden zur Überprüfung auf Geheimnisse an Ihren Cycode-Mandanten gesendet.

Jedes Ereignis wird außerdem mit Kontext zum Entwickler und Rechner gemeldet, sodass ein Fund dem Gerät und Benutzer zugeordnet werden kann, von denen er stammt. Einige dieser Daten sind personenbezogen:

Gerätekennungen — der Hostname und die Hardware-Seriennummer des Rechners.
Benutzerkennungen — die E-Mail-Adresse des Benutzers, der beim KI-Coding-Agenten angemeldet ist, sowie der lokale Betriebssystem-Benutzername.
Umgebungsdetails — Betriebssystem und Version, der KI-Agent, seine Version und das verwendete Modell, die Inhalte der MCP-Konfigurationsdateien des Agenten sowie seine aktivierten Plugins.

Die Hardware-Seriennummer wird in einer lokalen temporären Datei gespeichert, die nur für den Benutzer lesbar ist, der den Befehl ausgeführt hat. Dadurch wird verhindert, dass sie bei wiederholten Hook-Aufrufen erneut abgefragt wird.

Wenn die Erfassung dieser Daten in Ihrer Umgebung nicht akzeptabel ist, installieren Sie die Guardrails-Hooks nicht (cycode ai-guardrails uninstall entfernt bereits installierte Hooks).

Scan-Befehl

Einen Scan ausführen

Die Cycode CLI-Anwendung bietet verschiedene Scan-Typen, damit Sie die für Ihren Anwendungsfall passende Option auswählen können. Folgende Optionen und Befehle sind derzeit verfügbar:

Option	Beschreibung
`-t, --scan-type [secret\|iac\|sca\|sast]`	Geben Sie den auszuführenden Scan an (`secret`/`iac`/`sca`/`sast`); standardmäßig wird `secret` verwendet.
`--show-secret BOOLEAN`	Geheimnisse im Klartext anzeigen. Weitere Informationen finden Sie im Abschnitt Geheimnisse anzeigen/ausblenden.
`--soft-fail BOOLEAN`	Scan ausführen, ohne ihn fehlschlagen zu lassen; immer einen Statuscode ohne Fehler zurückgeben. Weitere Informationen finden Sie im Abschnitt Soft Fail.
`--severity-threshold [INFO\|LOW\|MEDIUM\|HIGH\|CRITICAL]`	Nur Verstöße mit dem angegebenen Schweregrad oder höher anzeigen.
`--sca-scan`	Geben Sie den auszuführenden SCA-Scan an (`package-vulnerabilities`/`license-compliance`/`unmaintained-packages`/`malicious-packages`). Standardmäßig werden alle ausgeführt.
`--monitor`	Wenn angegeben, werden die Scan-Ergebnisse in Cycode gespeichert.
`--cycode-report`	Einen Link zum Scan-Bericht auf der Cycode-Plattform in der Konsolenausgabe anzeigen.
`--no-restore`	Wenn angegeben, führt Cycode den Restore-Befehl nicht aus. Dadurch werden NUR direkte Abhängigkeiten gescannt!
`--stop-on-error`	Scan abbrechen, wenn beim Erfassen von Dateien oder beim Wiederherstellen von Abhängigkeiten ein Fehler auftritt, anstatt die fehlerhafte Datei zu überspringen und fortzufahren.
`--gradle-all-sub-projects`	Den Gradle-Restore-Befehl für alle Unterprojekte ausführen. Dies sollte von folgendem Verzeichnis aus erfolgen:
`--maven-settings-file`	Nur für Maven: Ermöglicht die Verwendung einer benutzerdefinierten Datei settings.xml beim Scannen von Abhängigkeiten
`--help`	Optionen für den angegebenen Befehl anzeigen.

Befehl	Beschreibung
commit-history	Commit-Verlauf scannen oder einen Diff-Scan zwischen bestimmten Commits durchführen
path	Die im Befehl angegebene Pfadangabe scannen
pre-commit	Noch nicht committete Inhalte scannen; unterstützt außerdem lokale Diff-Scans über Flags (IDE-freundlich)
repository	Git-Repository einschließlich Verlauf scannen

Optionen

Schweregradoption

Um die Scan-Ergebnisse auf einen bestimmten Schweregrad zu begrenzen, kann das Argument --severity-threshold zum Scan-Befehl hinzugefügt werden.

Der folgende Befehl scannt beispielsweise das Repository auf Richtlinienverstöße mit dem Schweregrad „Mittel“ oder höher:

cycode scan --severity-threshold MEDIUM repository ~/home/git/codebase

Monitor-Option

[!NOTE] Diese Option ist nur für SCA-Scans verfügbar.

Um Scan-Ergebnisse zu den in einem SCA-Scan gefundenen SCA-Richtlinien an Cycode zu senden, fügen Sie das Argument --monitor zum Scan-Befehl hinzu.

Der folgende Befehl scannt beispielsweise das Repository auf Verstöße gegen SCA-Richtlinien und sendet sie an die Cycode-Plattform:

cycode scan -t sca --monitor repository ~/home/git/codebase

Cycode-Berichtsoption

Für jeden mit der Cycode CLI ausgeführten Scan wird automatisch ein Bericht erstellt und die Ergebnisse werden an Cycode gesendet. Diese Ergebnisse sind den entsprechenden Richtlinien auf der Cycode-Plattform zugeordnet (z. B. den SCA-Richtlinien für Repository-Scans).

Damit die direkte URL zu diesem Cycode-Bericht nach Abschluss des Scans in der CLI-Ausgabe angezeigt wird, fügen Sie das Argument --cycode-report zum Scan-Befehl hinzu.

cycode scan --cycode-report repository ~/home/git/codebase

Alle Scan-Ergebnisse der CLI werden im Abschnitt „CLI Logs“ von Cycode angezeigt. Wenn Sie das Flag --cycode-report in Ihren Befehl aufgenommen haben, wird nach den Scan-Ergebnissen ein direkter Link zum jeweiligen Bericht in Ihrem Terminal angezeigt.

[!WARNING] Sie benötigen in Cycode die Rolle owner oder admin, um diese Seite aufzurufen.

cli-report

Die Berichtsseite sieht ungefähr wie folgt aus:

Option für Paket-Schwachstellen

[!NOTE] Diese Option ist nur für SCA-Scans verfügbar.

Um eine bestimmte Paket-Schwachstelle in Ihrem lokalen Repository zu scannen, fügen Sie das Argument --sca-scan package-vulnerabilities nach der Option -t sca oder --scan-type sca hinzu.

Wenn Sie im vorherigen Beispiel nur einen SCA-Scan auf Paket-Schwachstellen ausführen wollten, könnten Sie folgenden Befehl ausführen:

cycode scan -t sca --sca-scan package-vulnerabilities repository ~/home/git/codebase

Option für Lizenzkonformität

[!NOTE] Diese Option ist nur für SCA-Scans verfügbar.

Um einen bestimmten Branch Ihres lokalen Repositorys zu scannen, fügen Sie das Argument --sca-scan license-compliance gefolgt vom Namen des zu scannenden Branches hinzu.

Wenn Sie im vorherigen Beispiel nur einen Branch namens dev scannen wollten, könnten Sie folgenden Befehl ausführen:

cycode scan -t sca --sca-scan license-compliance repository ~/home/git/codebase -b dev

Option für nicht mehr gepflegte Pakete

[!NOTE] Diese Option ist nur für SCA-Scans verfügbar.

Um nur nach nicht mehr gepflegten Paketen zu suchen (Pakete, deren Prüfung Maintained im OpenSSF Scorecard niedrig ausfällt, was auf wenige oder keine aktuellen Commit- und Issue-Aktivitäten hindeutet), fügen Sie das Argument --sca-scan unmaintained-packages nach der Option -t sca oder --scan-type sca hinzu.

[!NOTE] Ob nicht mehr gepflegte Pakete überhaupt gemeldet werden, wird durch die Richtlinie Ihrer Organisation festgelegt. Mit dieser Option wird der Umfang der Scan-Ergebnisse eingeschränkt; sie kann keine für Ihren Mandanten deaktivierte Richtlinie aktivieren.

Wenn Sie im vorherigen Beispiel nur einen SCA-Scan auf nicht mehr gepflegte Pakete ausführen wollten, könnten Sie folgenden Befehl ausführen:

cycode scan -t sca --sca-scan unmaintained-packages repository ~/home/git/codebase

Option für schädliche Pakete

[!NOTE] Diese Option ist nur für SCA-Scans verfügbar.

Um nur nach schädlichen Paketen zu suchen (Abhängigkeiten, die in einem Sicherheitshinweis als Malware und nicht lediglich als anfällig eingestuft wurden), fügen Sie das Argument --sca-scan malicious-packages nach der Option -t sca oder --scan-type sca hinzu.

Verstöße aufgrund schädlicher Pakete werden immer als Critical gemeldet und haben weder einen CVSS-Wert noch eine Version mit Fehlerbehebung: Die einzige Abhilfemaßnahme besteht darin, die Abhängigkeit zu entfernen.

[!NOTE] Ob schädliche Pakete überhaupt gemeldet werden, wird durch die Richtlinie Ihrer Organisation festgelegt. Mit dieser Option wird der Umfang der Scan-Ergebnisse eingeschränkt; sie kann keine für Ihren Mandanten deaktivierte Richtlinie aktivieren.

Wenn Sie im vorherigen Beispiel nur einen SCA-Scan auf schädliche Pakete ausführen wollten, könnten Sie folgenden Befehl ausführen:

cycode scan -t sca --sca-scan malicious-packages repository ~/home/git/codebase

Option zum Wiederherstellen von Sperrdateien

[!NOTE] Diese Option ist nur für SCA-Scans verfügbar.

Bei einem SCA-Scan versucht die Cycode CLI automatisch, für jede unterstützte Manifestdatei eine Abhängigkeitssperrdatei wiederherzustellen (zu generieren). Dadurch können auch transitive Abhängigkeiten gescannt werden, nicht nur die direkt im Manifest aufgeführten. Um diesen Schritt zu überspringen und nur direkte Abhängigkeiten zu scannen, verwenden Sie das Flag --no-restore.

Die folgenden Ökosysteme unterstützen die automatische Wiederherstellung von Sperrdateien:

Ökosystem	Manifestdatei	Generierte Sperrdatei	Aufgerufenes Tool (wenn keine Sperrdatei vorhanden ist)
npm	`package.json`	`package-lock.json`	`npm install --package-lock-only --ignore-scripts --no-audit`
Yarn	`package.json`	`yarn.lock`	`yarn install --ignore-scripts`
pnpm	`package.json`	`pnpm-lock.yaml`	`pnpm install --ignore-scripts`
Deno	`deno.json` / `deno.jsonc`	`deno.lock`	(liest nur vorhandene Sperrdateien)
Go	`go.mod`	`go.mod.graph`	`go list -m -json all` + `go mod graph`
Maven	`pom.xml`	`bcde.mvndeps`	`mvn dependency:tree`
Gradle	`build.gradle` / `build.gradle.kts`	`gradle-dependencies-generated.txt`	`gradle dependencies -q --console plain`
SBT	`build.sbt`	`build.sbt.lock`	`sbt dependencyLockWrite`
NuGet	`*.csproj`	`packages.lock.json`	`dotnet restore --use-lock-file`
Ruby	`Gemfile`	`Gemfile.lock`	`bundle --quiet`
Poetry	`pyproject.toml`	`poetry.lock`	`poetry lock`
pip	`pyproject.toml` / `requirements.txt`	`pylock.toml`	`pip lock .` / `pip lock -r requirements.txt -o pylock.toml`
Pipenv	`Pipfile`	`Pipfile.lock`	`pipenv lock`
PHP Composer	`composer.json`	`composer.lock`	`composer update --no-cache --no-install --no-scripts --ignore-platform-reqs`

Wenn neben dem Manifest bereits eine Sperrdatei vorhanden ist, liest Cycode sie direkt ein, ohne einen Installationsbefehl auszuführen. SBT-Voraussetzung: Das Plugin sbt-dependency-lock muss installiert sein. Füge die folgende Zeile zu project/plugins.sbt hinzu:

addSbtPlugin("software.purpledragon" % "sbt-dependency-lock" % "1.5.1")

Option „Bei Fehler abbrechen“

Standardmäßig setzt Cycode den Scan fort, auch wenn eine Datei nicht gelesen werden kann (z. B. aufgrund eines Berechtigungsfehlers) oder während eines SCA-Scans keine Abhängigkeits-Lockdatei generiert werden kann. Das fehlgeschlagene Element wird mit einer Warnung übersprungen, und der Scan wird mit den übrigen Dateien fortgesetzt.

Verwende --stop-on-error, um dieses Verhalten zu ändern: Der Scan wird beim ersten derartigen Fehler sofort abgebrochen und der Fehler gemeldet.

cycode scan -t sca --stop-on-error path ~/home/git/codebase

Dies ist nützlich in CI-Pipelines, in denen ein unbemerkter Fehler zu einem unvollständigen Scan-Ergebnis führen würde. Wenn --stop-on-error ausgelöst wird, kannst du entweder das zugrunde liegende Problem beheben oder – speziell bei SCA-Wiederherstellungsfehlern – --no-restore hinzufügen, um die Generierung der Lockdatei zu überspringen und nur direkte Abhängigkeiten zu scannen.

Wenn --stop-on-error verwendet wird, unterscheidet die CLI anhand der Exit-Codes zwischen Scanfehlern und Richtlinienverstößen:

Exit-Code	Bedeutung
`0`	Scan ohne Verstöße abgeschlossen
`1`	Scan abgeschlossen; Verstöße wurden gefunden
`2`	Scan aufgrund eines Fehlers abgebrochen (nur wenn `--stop-on-error` gesetzt ist)

Repository-Scan

Ein Repository-Scan untersucht ein gesamtes lokales Repository auf offengelegte Geheimnisse oder unsichere Fehlkonfigurationen. Dieser umfassendere Scan-Typ prüft alles: den aktuellen Zustand deines Repositorys und dessen Commit-Verlauf. Dabei wird nicht nur nach Geheimnissen gesucht, die derzeit im Repository offengelegt sind, sondern auch nach zuvor gelöschten Geheimnissen.

Führe für einen vollständigen Repository-Scan Folgendes aus:

cycode scan repository {{path}}

Wenn du beispielsweise ein unter ~/home/git/codebase gespeichertes Repository scannen möchtest, kannst du Folgendes ausführen:

cycode scan repository ~/home/git/codebase

Für diesen Befehl ist die folgende Option verfügbar:

Option	Beschreibung
`-b, --branch TEXT`	Zu scannender Branch; ist die Option nicht gesetzt, wird der Standard-Branch gescannt

Branch-Option

Um einen bestimmten Branch deines lokalen Repositorys zu scannen, füge das Argument -b (alternativ --branch) hinzu, gefolgt vom Namen des Branches, den du scannen möchtest.

Wenn du, wie im vorherigen Beispiel, nur einen Branch namens dev scannen möchtest, kannst du Folgendes ausführen:

cycode scan repository ~/home/git/codebase -b dev

Pfad-Scan

Ein Pfad-Scan untersucht ein bestimmtes lokales Verzeichnis und alle darin enthaltenen Dateien, anstatt sich ausschließlich auf ein GIT-Repository zu konzentrieren.

Führe für einen Verzeichnis-Scan Folgendes aus:

cycode scan path {{path}}

Angenommen, du möchtest das Verzeichnis unter ~/home/git/codebase scannen. Dann kannst du Folgendes ausführen:

cycode scan path ~/home/git/codebase

Terraform-Plan-Scan

Cycode CLI unterstützt das Scannen von Terraform-Plänen (Terraform 0.12 und höher werden unterstützt).

Die Terraform-Plan-Datei muss im JSON-Format vorliegen (mit der Erweiterung .json).

Wenn du nur eine Konfigurationsdatei hast, kannst du wie folgt einen Plan erstellen:

Initialisiere ein Arbeitsverzeichnis, das eine Terraform-Konfigurationsdatei enthält:

terraform init
Erstelle einen Terraform-Ausführungsplan und speichere die binäre Ausgabe:

terraform plan -out={tfplan_output}
Wandle die Binärdatei in lesbares JSON um:

terraform show -json {tfplan_output} > {tfplan}.json
Scanne deinen {tfplan}.json mit Cycode CLI:

cycode scan -t iac path ~/PATH/TO/YOUR/{tfplan}.json

Scan des Commit-Verlaufs

[!NOTE] Der Scan des Commit-Verlaufs ist für IaC-Scans nicht verfügbar.

Der Befehl zum Scannen des Commit-Verlaufs bietet zwei Hauptfunktionen:

Vollständiger Verlaufsscan: Analysiert alle Commits im Repository-Verlauf
Diff-Scan: Scannt nur die Änderungen zwischen bestimmten Commits

Beim Scannen nach Geheimnissen können alle Commits im Repository-Verlauf analysiert werden, da Geheimnisse, die eingeführt und später entfernt wurden, dennoch offengelegt worden sein können. Bei SCA- und SAST-Scans konzentriert sich der Befehl zum Scannen des Commit-Verlaufs auf die Unterschiede bzw. Änderungen zwischen Commits. Dadurch eignet er sich ideal für Pull-Request-Prüfungen und inkrementelle Scans.

Ein Scan des Commit-Verlaufs untersucht den Commit-Verlauf deines Git-Repositorys und kann sowohl für umfassende historische Analysen als auch für gezielte Diff-Scans bestimmter Änderungen verwendet werden.

Führe für einen Scan des Commit-Verlaufs Folgendes aus:

cycode scan commit-history {{path}}

Angenommen, du möchtest den Commit-Verlauf eines unter ~/home/git/codebase gespeicherten Repositorys scannen. Dann kannst du Folgendes ausführen:

cycode scan commit-history ~/home/git/codebase

Für diesen Befehl sind die folgenden Optionen verfügbar:

Option	Beschreibung
`-r, --commit-range TEXT`	Einen Commit-Bereich in diesem Git-Repository scannen. Standardmäßig scannt cycode den gesamten Commit-Verlauf (Beispiel: HEAD~1)

Commit-Bereich-Option (Diff-Scan)

Die Commit-Bereich-Option ermöglicht Diff-Scans – dabei werden nur die Änderungen zwischen bestimmten Commits gescannt, statt des gesamten Repository-Verlaufs. Dies ist besonders nützlich für:

Pull-Request-Validierung: Nur die in einem PR eingeführten Änderungen scannen
Inkrementelle CI/CD-Scans: Neuere Änderungen statt der gesamten Codebasis prüfen
Prüfung von Feature-Branches: Änderungen mit dem main-/master-Branch vergleichen
Leistungsoptimierung: Schnellere Scans durch Beschränkung auf relevante Änderungen

Syntax für Commit-Bereiche

Die Option --commit-range (-r) unterstützt die standardmäßige Git-Revisionssyntax:

Syntax	Beschreibung	Beispiel
`commit1..commit2`	Änderungen von commit1 bis commit2	`abc123..def456`
`commit1...commit2`	Änderungen in commit2, die nicht in commit1 enthalten sind	`main...feature-branch`
`commit`	Änderungen von einem Commit bis HEAD	`HEAD~1`
`branch1..branch2`	Änderungen von branch1 bis branch2	`main..feature-branch`

Beispiele für Diff-Scans

Änderungen im letzten Commit scannen:

cycode scan commit-history -r HEAD~1 ~/home/git/codebase

Änderungen zwischen zwei bestimmten Commits scannen:

cycode scan commit-history -r abc123..def456 ~/home/git/codebase

Änderungen in deinem Feature-Branch im Vergleich zu main scannen:

cycode scan commit-history -r main..HEAD ~/home/git/codebase

Änderungen zwischen main und einem Feature-Branch scannen:

cycode scan commit-history -r main..feature-branch ~/home/git/codebase

Alle Änderungen der letzten 3 Commits scannen:

cycode scan commit-history -r HEAD~3..HEAD ~/home/git/codebase

[!TIP] Für CI/CD-Pipelines kannst du Umgebungsvariablen wie ${{ github.event.pull_request.base.sha }}..${{ github.sha }} (GitHub Actions) oder $CI_MERGE_REQUEST_TARGET_BRANCH_SHA..$CI_COMMIT_SHA (GitLab CI) verwenden, um nur PR-/MR-Änderungen zu scannen.

Pre-Commit-Scan

Ein Pre-Commit-Scan erkennt automatisch Probleme, bevor du Änderungen an deinem Repository committest. Du musst diesen Scan nicht manuell ausführen. Richte stattdessen den Pre-Commit-Hook wie im Abschnitt „Installation“ dieser Anleitung beschrieben ein.

Nach der Installation des Pre-Commit-Hooks möchtest du den Scan möglicherweise bei einem bestimmten Commit überspringen. Füge dazu Folgendes zu deinem git-Befehl hinzu, um den Scan für einen einzelnen Commit zu überspringen:

SKIP=cycode git commit -m <your commit message>`

Für diesen Befehl sind die folgenden Optionen verfügbar:

Option	Beschreibung
`-b, --base-ref TEXT`	Git-Referenz (Commit, Branch oder Tag), mit der verglichen werden soll; standardmäßig `HEAD`, entsprechend dem Verhalten des Pre-Commit-Hooks
`--include-unstaged`	Auch nicht gestagte Änderungen an nachverfolgten Dateien scannen, nicht nur die gestagten; standardmäßig deaktiviert
`--path PATH`	Optionale Pfade, auf die der Diff-Scan beschränkt werden soll; mehrfach verwendbar; standardmäßig das gesamte Arbeitsverzeichnis

Lokale Diff-Scans (IDE-Integrationen)

--base-ref und --include-unstaged machen aus pre-commit einen universellen lokalen Diff-Scan: Dabei wird ein beliebiger Commit (standardmäßig HEAD) mit deinem aktuellen Arbeitsverzeichnis verglichen – einschließlich noch nicht gestagter Änderungen. Dies ist für IDE-Plugins und andere Tools gedacht, die während der Arbeit kontinuierlich Feedback in Echtzeit benötigen, statt des Git-Hook-Ablaufs. In Kombination mit --include-unstaged ermöglicht --path einer IDE, den Scan auf die aktuell im Editor geöffnete Datei zu beschränken.

[!NOTE] Lokale Diff-Scans (über diese Flags) sind für IaC-Scans nicht verfügbar.

Alle derzeit geänderten Dateien (gestagte und nicht gestagte) mit dem letzten Commit vergleichen:

cycode scan pre-commit --include-unstaged

Änderungen mit einem bestimmten Commit oder Branch vergleichen:

cycode scan pre-commit --include-unstaged --base-ref main

Nur eine bestimmte Datei scannen (z. B. die aktuell in deiner IDE geöffnete Datei):

cycode scan pre-commit --include-unstaged --path src/app.py

Pre-Push-Scan

Ein Pre-Push-Scan erkennt automatisch Probleme, bevor du Änderungen an das Remote-Repository pushst. Dieser Hook wird clientseitig ausgeführt und scannt nur die Commits, die gepusht werden sollen. So lassen sich Probleme effizient erkennen, bevor sie das Remote-Repository erreichen.

[!NOTE] Der Pre-Push-Hook ist für IaC-Scans nicht verfügbar.

Der Pre-Push-Hook ist in das Pre-Commit-Framework integriert und kann so konfiguriert werden, dass er vor jedem Vorgang vom Typ git push ausgeführt wird.

Pre-Push-Hook installieren

So richtest du den Pre-Push-Hook mit dem Pre-Commit-Framework ein:

Installiere das Pre-Commit-Framework (falls es noch nicht installiert ist):
```
pip3 install pre-commit
```

Erstelle oder aktualisiere deine Datei .pre-commit-config.yaml, um die Pre-Push-Hooks aufzunehmen:

repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode-pre-push
        stages: [pre-push]

Verwende für mehrere Scan-Typen diese Konfiguration:

repos:
  - repo: https://github.com/cycodehq/cycode-cli
    rev: v3.25.0
    hooks:
      - id: cycode-pre-push          # Secrets scan
        stages: [pre-push]
      - id: cycode-sca-pre-push      # SCA scan
        stages: [pre-push]
      - id: cycode-sast-pre-push     # SAST scan
        stages: [pre-push]

Installiere den Pre-Push-Hook:
```
pre-commit install --hook-type pre-push
```
Bei erfolgreicher Installation wird die Meldung Pre-push installed at .git/hooks/pre-push angezeigt.
Halte den Pre-Push-Hook auf dem neuesten Stand:
```
pre-commit autoupdate
```

Funktionsweise des Pre-Push-Scans

Der Hook scannt jeden gepushten Commit einzeln. Dadurch wird ein Geheimnis auch dann erkannt, wenn es in einem Commit hinzugefügt und in einem späteren wieder entfernt wird. Bei der Installation über das Pre-Commit-Framework wird der zu pushende Bereich vom Framework übernommen: Bei bestehenden Branches sind dies neue Commits seit dem Remote-Branch, bei neuen Branches die Commits, die noch nicht auf dem Remote vorhanden sind (beim Push auf ein leeres Remote alle Commits). Wird der Hook aus einer selbst geschriebenen .git/hooks/pre-push ausgeführt, wird der Bereich aus der Hook-Eingabe von Git gelesen. Neue Branches werden ab ihrem Merge-Base mit dem Standard-Branch gescannt (siehe unten).

Pushes, bei denen nichts zu scannen ist, etwa Tags, das Löschen von Branches und Pushes ohne neue Änderungen, werden ohne Scan zugelassen. Kann der Hook nicht ermitteln, was gepusht wird, schlägt er fehl und blockiert den Push, statt ihn unbemerkt durchzulassen.

Die Cycode-Pre-Push-Hooks setzen always_run: true und pass_filenames: false, da der Scan die gepushten Commits statt einer Dateiliste umfasst. Ohne always_run überspringt das Pre-Commit-Framework den Hook, wenn die gepussten Commits insgesamt keine geänderten Dateien ergeben, etwa wenn ein Geheimnis in einem Commit hinzugefügt und im nächsten gelöscht wird. Ohne pass_filenames: false übergibt das Framework geänderte Dateinamen, die der Scan nicht verwendet. Bei großen Pushes teilt es diese außerdem in Stapel auf und führt den vollständigen Scan einmal pro Stapel aus. Wenn du den Hook selbst definierst (zum Beispiel als repo: local-Hook), setze beide Optionen.

Automatische Erkennung des Standard-Branches

Bei Ausführung über einen selbst geschriebenen Hook erkennt der Pre-Push-Scan den Standard-Branch für die Berechnung des Merge-Base in folgender Prioritätsreihenfolge:

Umgebungsvariable: CYCODE_DEFAULT_BRANCH – ermöglicht eine manuelle Überschreibung
Git-Remote-HEAD: Verwendet git symbolic-ref refs/remotes/origin/HEAD, um den tatsächlichen Standard-Branch des Remotes zu erkennen
Git-Remote-Informationen: Greift auf git remote show origin zurück, wenn symbolic-ref fehlschlägt
Fest codierte Fallbacks: Verwendet gängige Namen für Standard-Branches (origin/main, origin/master, main, master)

Benutzerdefinierten Standard-Branch festlegen:

export CYCODE_DEFAULT_BRANCH=origin/develop

Diese intelligente Erkennung stellt sicher, dass der Pre-Push-Hook korrekt funktioniert, unabhängig davon, ob dein Repository main, master, develop oder einen anderen Standard-Branch-Namen verwendet.

Pre-Push-Scans überspringen

Um den Pre-Push-Scan für einen bestimmten Push-Vorgang zu überspringen, verwende:

SKIP=cycode-pre-push git push

Oder um alle Pre-Push-Hooks zu überspringen:

git push --no-verify

[!TIP] Der Pre-Push-Hook wird beim Befehl git push ausgelöst und scannt nur die Commits, die gerade gepusht werden sollen. Dadurch ist er effizienter als ein Scan des gesamten Repositorys.

Pfade von Scans ausschließen

Mit einer Datei .cycodeignore kannst du der Cycode CLI mitteilen, welche Dateien und Verzeichnisse von Scans ausgeschlossen werden sollen. Sie funktioniert genauso wie eine Datei .gitignore. So kannst du dich auf relevanten Code konzentrieren und verhindern, dass bestimmte Pfade lokal Verstöße auslösen.

Funktionsweise

Erstelle in deinem Arbeitsordner eine Datei mit dem Namen .cycodeignore.
Liste die Dateien und Verzeichnisse auf, die du ausschließen möchtest. Verwende dabei dieselben Muster wie in .gitignore.
Lege diese Datei in dem Verzeichnis ab, in dem du den Befehl cycode scan ausführen möchtest.

[!WARNING]

Ungültige Dateien: Wenn die Datei .cycodeignore einen Syntaxfehler enthält, schlägt der CLI-Scan fehl und gibt einen Fehler zurück.

Pfade ignorieren vs. Verstöße ignorieren: Diese Datei dient zum Ausschließen von Pfaden. Sie unterscheidet sich von der CLI-Funktion, mit der bestimmte Verstöße ignoriert werden können (zum Beispiel mithilfe des Flags --ignore-violation).

Unterstützte Scanner

SAST
IaC (demnächst verfügbar)
SCA (demnächst verfügbar)

Scan-Ergebnisse

Nach jedem Scan wird eine Meldung ausgegeben, die angibt, ob Probleme gefunden wurden.

Wenn keine Probleme gefunden werden, endet der Scan mit der folgenden Erfolgsmeldung:

Good job! No issues were found!!! 👏👏👏

Wird ein Problem gefunden, erscheint stattdessen nach Abschluss eine Verstoßkarte. Überprüfe in diesem Fall die betreffende Datei und die in der Ergebnismeldung hervorgehobene Zeile. Nimm alle erforderlichen Änderungen vor, um das Problem zu beheben, und führe den Scan anschließend erneut aus.

Geheimnisse ein-/ausblenden

In den Beispielen unten wurde in der Datei secret_test ein Geheimnis gefunden, die sich im Unterordner cli befindet. Der zweite Teil der Meldung zeigt die genaue Zeile, in der das Geheimnis vorkommt. In diesem Fall ist es ein Wert, der googleApiKey zugewiesen wurde.

Beachte, dass im Beispiel der tatsächliche Geheimniswert unkenntlich gemacht und größtenteils durch Sternchen ersetzt wird. Scans blenden Geheimnisse standardmäßig aus. Du kannst diese Funktion jedoch optional deaktivieren, um das vollständige Geheimnis anzuzeigen (sofern der Rechner, auf dem du das Scan-Ergebnis ansiehst, ausreichend vor neugierigen Blicken geschützt ist).

Um das Ausblenden von Geheimnissen zu deaktivieren, füge das Argument --show-secret zu einem beliebigen Scan-Typ hinzu.

Im folgenden Beispiel wird ein Path Scan für das Unterverzeichnis cli ausgeführt. Dabei ist die Option aktiviert, alle gefundenen Geheimnisse vollständig anzuzeigen:

cycode scan --show-secret path ./cli

Das Ergebnis wird dann nicht unkenntlich gemacht.

Soft Fail

Im Normalbetrieb gibt die CLI den Exit-Code 1 zurück, wenn in den Scan-Ergebnissen Probleme gefunden werden. Je nach deiner CI/CD-Konfiguration führt dies in der Regel zu einem Fehlschlag des gesamten Vorgangs. Wenn du das verhindern möchtest, kannst du die Soft-Fail-Funktion verwenden.

Wenn du die Option --soft-fail zu einem beliebigen Scan-Typ hinzufügst, wird der Exit-Code unabhängig davon, ob Ergebnisse gefunden werden, auf 0 gesetzt.

Beispiele für Scan-Ergebnisse

Beispiel für ein Secrets-Ergebnis

╭─────────────────────────────────────────────────────────────── Hardcoded generic-password is used ───────────────────────────────────────────────────────────────╮
│                                                                                                                                               Violation 12 of 12 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity    🟠 MEDIUM                             │ │   34 };                                                                                               │ │
│ │  In file     /Users/cycodemacuser/NodeGoat/test/s  │ │   35                                                                                                  │ │
│ │              ecurity/profile-test.js               │ │   36 var sutUserName = "user1";                                                                       │ │
│ │  Secret SHA  b4ea3116d868b7c982ee6812cce61727856b  │ │ ❱ 37 var sutUserPassword = "Us*****23";                                                               │ │
│ │              802b3063cd5aebe7d796988552e0          │ │   38                                                                                                  │ │
│ │  Rule ID     68b6a876-4890-4e62-9531-0e687223579f  │ │   39 chrome.setDefaultService(service);                                                               │ │
│ ╰────────────────────────────────────────────────────╯ │   40                                                                                                  │ │
│                                                        ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ A generic secret or password is an authentication token used to access a computer or application and is assigned to a password variable.                     │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Beispiel für ein IaC-Ergebnis

╭──────────── Enable Content Encoding through the attribute 'MinimumCompressionSize'. This value should be greater than -1 and smaller than 10485760. ─────────────╮
│                                                                                                                                              Violation 45 of 110 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity      🟠 MEDIUM                           │ │   20 BinaryMediaTypes:                                                                                │ │
│ │  In file       ...ads-copy/iac/cft/api-gateway/ap  │ │   21   - !Ref binaryMediaType1                                                                        │ │
│ │                i-gateway-rest-api/deploy.yml       │ │   22   - !Ref binaryMediaType2                                                                        │ │
│ │  IaC Provider  CloudFormation                      │ │ ❱ 23 MinimumCompressionSize: -1                                                                       │ │
│ │  Rule ID       33c4b90c-3270-4337-a075-d3109c141b  │ │   24 EndpointConfiguration:                                                                           │ │
│ │                53                                  │ │   25   Types:                                                                                         │ │
│ ╰────────────────────────────────────────────────────╯ │   26     - EDGE                                                                                       │ │
│                                                        ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ This policy validates the proper configuration of content encoding in AWS API Gateway. Specifically, the policy checks for the attribute                     │ │
│ │ 'minimum_compression_size' in API Gateway REST APIs. Correct configuration of this attribute is important for enabling content encoding of API responses for │ │
│ │ improved API performance and reduced payload sizes.                                                                                                          │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Beispiel für ein SCA-Ergebnis

╭─────────────────────────────────────────────────────── [CVE-2019-10795] Prototype Pollution in undefsafe ────────────────────────────────────────────────────────╮
│                                                                                                                                             Violation 172 of 195 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity               🟠 MEDIUM                  │ │   26758   "integrity": "sha1-5z3T17DXxe2G+6xrCufYxqadUPo=",                                           │ │
│ │  In file                /Users/cycodemacuser/Node  │ │   26759   "dev": true                                                                                 │ │
│ │                         Goat/package-lock.json     │ │   26760 },                                                                                            │ │
│ │  CVEs                   CVE-2019-10795             │ │ ❱ 26761 "undefsafe": {                                                                                │ │
│ │  Package                undefsafe                  │ │   26762   "version": "2.0.2",                                                                         │ │
│ │  Version                2.0.2                      │ │   26763   "resolved": "https://registry.npmjs.org/undefsafe/-/undefsafe-2.0.2.tgz",                   │ │
│ │  First patched version  Not fixed                  │ │   26764   "integrity": "sha1-Il9rngM3Zj4Njnz9aG/Cg2zKznY=",                                           │ │
│ │  Dependency path        nodemon 1.19.1 ->          │ ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ │                         undefsafe 2.0.2            │                                                                                                           │
│ │  Rule ID                9c6a8911-e071-4616-86db-4  │                                                                                                           │
│ │                         943f2e1df81                │                                                                                                           │
│ ╰────────────────────────────────────────────────────╯                                                                                                           │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ undefsafe before 2.0.3 is vulnerable to Prototype Pollution. The 'a' function could be tricked into adding or modifying properties of Object.prototype using │ │
│ │ a __proto__ payload.                                                                                                                                         │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Beispiel für ein SAST-Ergebnis

╭───────────────────────────────────────────── [CWE-208: Observable Timing Discrepancy] Observable Timing Discrepancy ─────────────────────────────────────────────╮
│                                                                                                                                               Violation 24 of 49 │
│ ╭─ 🔍 Details ───────────────────────────────────────╮ ╭─ 💻 Code Snippet ─────────────────────────────────────────────────────────────────────────────────────╮ │
│ │  Severity       🟠 MEDIUM                          │ │   173         " including numbers, lowercase and uppercase letters.";                                 │ │
│ │  In file        /Users/cycodemacuser/NodeGoat/app  │ │   174     return false;                                                                               │ │
│ │                 /routes/session.js                 │ │   175 }                                                                                               │ │
│ │  CWE            CWE-208                            │ │ ❱ 176 if (password !== verify) {                                                                      │ │
│ │  Subcategory    Security                           │ │   177     errors.verifyError = "Password must match";                                                 │ │
│ │  Language       js                                 │ │   178     return false;                                                                               │ │
│ │  Security Tool  Bearer (Powered by Cycode)         │ │   179 }                                                                                               │ │
│ │  Rule ID        19fbca07-a8e7-4fa6-92ac-a36d15509  │ ╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ │                 fa9                                │                                                                                                           │
│ ╰────────────────────────────────────────────────────╯                                                                                                           │
│ ╭─ 📝 Summary ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
│ │ Observable Timing Discrepancy occurs when the time it takes for certain operations to complete can be measured and observed by attackers. This vulnerability │ │
│ │ is particularly concerning when operations involve sensitive information, such as password checks or secret comparisons. If attackers can analyze how long   │ │
│ │ these operations take, they might be able to deduce confidential details, putting your data at risk.                                                         │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Benutzerdefinierte Behebungsrichtlinien des Unternehmens

Wenn dein Unternehmen im Cycode-Portal benutzerdefinierte Behebungsrichtlinien in der entsprechenden Richtlinie festgelegt hat, wird ein Feld „Company Guidelines“ mit den von dir hinzugefügten Behebungsrichtlinien angezeigt. Wenn du keine Unternehmensrichtlinien hinzugefügt hast, wird dieses Feld im CLI-Tool nicht angezeigt.

Scan-Ergebnisse ignorieren

Mit Ignorierregeln lassen sich bestimmte Geheimniswerte, SHA512-Werte, Pfade sowie bestimmte Cycode-Regel-IDs für Secrets und IaC ignorieren. Dadurch werden für diese Werte keine Warnungen ausgegeben. Die Ignorierregeln werden lokal in der Datei ./.cycode/config.yaml gespeichert.

[!WARNING] Werte sollten nur nach sorgfältiger Prüfung der Werte, Pfade und Richtlinien zum Ignorieren hinzugefügt werden, damit die Scans echte positive Ergebnisse erkennen.

Für den Befehl cycode ignore stehen folgende Optionen zur Verfügung:

Option	Beschreibung
`--by-value TEXT`	Einen bestimmten Wert beim Scannen nach Geheimnissen ignorieren. Weitere Informationen findest du unter Einen Geheimniswert ignorieren.
`--by-sha TEXT`	Eine bestimmte SHA512-Darstellung einer Zeichenfolge beim Scannen nach Geheimnissen ignorieren. Weitere Informationen findest du unter Einen Geheimnis-SHA-Wert ignorieren.
`--by-path TEXT`	Einen bestimmten Pfad nicht scannen. Der Scan-Typ muss angegeben werden. Weitere Informationen findest du unter Einen Pfad ignorieren.
`--by-rule TEXT`	Eine bestimmte Regel-ID für Secrets, IaC oder SCA beim Scannen ignorieren. Weitere Informationen findest du unter Eine Secret- oder IaC-Regel ignorieren.
`--by-package TEXT`	Beim Ausführen eines SCA-Scans eine bestimmte Paketversion ignorieren. Erwartetes Muster: `name@version`. Weitere Informationen findest du unter Ein Paket ignorieren.
`--by-cve TEXT`	Beim Ausführen eines SCA-Scans eine bestimmte CVE ignorieren. Erwartetes Muster: CVE-YYYY-NNN.
`-t, --scan-type [secret\|iac\|sca\|sast]`	Den auszuführenden Scan angeben (`secret`/`iac`/`sca`/`sast`). Der Standardwert ist `secret`.
`-g, --global`	Eine Ignorierregel hinzufügen und in der globalen Konfigurationsdatei `.cycode` aktualisieren.

Einen Geheimniswert ignorieren

Um einen bestimmten Geheimniswert zu ignorieren, musst du das Flag --by-value verwenden. Dadurch wird der angegebene Geheimniswert bei allen zukünftigen Scans ignoriert. Verwende den folgenden Befehl, um einen Geheimniswert zur Ignorierliste hinzuzufügen:

cycode ignore --by-value {{secret-value}}

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren eines bestimmten Geheimniswerts:

cycode ignore --by-value h3110w0r1d!@#$350

Ersetze im obigen Beispiel den Wert h3110w0r1d!@#$350 durch deinen nicht maskierten Geheimniswert. Informationen dazu, wie du Geheimniswerte in den Scan-Ergebnissen anzeigen kannst, findest du in den Cycode-Scanoptionen.

Einen Geheimnis-SHA-Wert ignorieren

Um einen bestimmten Geheimnis-SHA-Wert zu ignorieren, musst du das Flag --by-sha verwenden. Dadurch wird der angegebene Geheimnis-SHA-Wert bei allen zukünftigen Scans ignoriert. Verwende den folgenden Befehl, um einen Geheimnis-SHA-Wert zur Ignorierliste hinzuzufügen:

cycode ignore --by-sha {{secret-sha-value}}

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren eines bestimmten Geheimnis-SHA-Werts:

cycode ignore --by-sha a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0

Ersetze im obigen Beispiel den Wert a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0 durch deinen Geheimnis-SHA-Wert.

Einen Pfad ignorieren

Um einen bestimmten Pfad bei Secrets-, IaC- oder SCA-Scans zu ignorieren, musst du das Flag --by-path zusammen mit dem Flag -t, --scan-type verwenden (der Scan-Typ muss angegeben werden). Dadurch wird der angegebene Pfad bei allen zukünftigen Scans des jeweiligen Typs ignoriert. Verwende den folgenden Befehl, um einen Pfad zur Ignorierliste hinzuzufügen:

cycode ignore -t {{scan-type}} --by-path {{path}}

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren eines bestimmten Pfads bei einem Secrets-Scan:

cycode ignore -t secret --by-path ~/home/my-repo/config

Ersetze im obigen Beispiel den Wert ~/home/my-repo/config durch deinen Pfad.

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren eines bestimmten Pfads bei IaC-Scans:

cycode ignore -t iac --by-path ~/home/my-repo/config

Ersetze im obigen Beispiel den Wert ~/home/my-repo/config durch deinen Pfad.

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren eines bestimmten Pfads bei SCA-Scans:

cycode ignore -t sca --by-path ~/home/my-repo/config

Ersetze im obigen Beispiel den Wert ~/home/my-repo/config durch deinen Pfad.

Eine Secrets-, IaC-, SCA- oder SAST-Regel ignorieren

Um eine bestimmte Secrets-, IaC-, SCA- oder SAST-Regel zu ignorieren, musst du das Flag --by-rule zusammen mit dem Flag -t, --scan-type verwenden (der Scan-Typ muss angegeben werden). Dadurch wird die angegebene Regel-ID bei allen zukünftigen Scans ignoriert. Verwende den folgenden Befehl, um eine Regel-ID zur Ignorierliste hinzuzufügen:

cycode ignore -t {{scan-type}} --by-rule {{rule-ID}}

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren einer bestimmten Secrets-Regel-ID:

cycode ignore -t secret --by-rule ce3a4de0-9dfc-448b-a004-c538cf8b4710

Ersetze im obigen Beispiel den Wert ce3a4de0-9dfc-448b-a004-c538cf8b4710 durch die Regel-ID, die du ignorieren möchtest.

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren einer bestimmten IaC-Regel-ID:

cycode ignore -t iac --by-rule bdaa88e2-5e7c-46ff-ac2a-29721418c59c

Ersetze im obigen Beispiel den Wert bdaa88e2-5e7c-46ff-ac2a-29721418c59c durch die Regel-ID, die du ignorieren möchtest.

Im Beispiel am Anfang dieses Abschnitts lautet der Befehl zum Ignorieren einer bestimmten SCA-Regel-ID:

cycode ignore -t sca --by-rule dc21bc6b-9f4f-46fb-9f92-e4327ea03f6b

Ersetze im obigen Beispiel den Wert dc21bc6b-9f4f-46fb-9f92-e4327ea03f6b durch die Regel-ID, die du ignorieren möchtest.

Ein Paket ignorieren

[!NOTE] Diese Option ist nur für SCA-Scans verfügbar.

Um ein bestimmtes Paket bei SCA-Scans zu ignorieren, musst du das Flag --by-package zusammen mit dem Flag -t, --scan-type verwenden (der Scan-Typ sca muss angegeben werden). Dadurch wird das angegebene Paket im Format {{package_name}}@{{package_version}} bei allen zukünftigen Scans ignoriert. Verwende den folgenden Befehl, um ein Paket und eine Version zur Ignorierliste hinzuzufügen:

cycode ignore --scan-type sca --by-package {{package_name}}@{{package_version}}

ODER

cycode ignore -t sca --by-package {{package_name}}@{{package_version}}

Im folgenden Beispiel lautet der Befehl zum Ignorieren eines bestimmten SCA-Pakets:

cycode ignore --scan-type sca --by-package pyyaml@5.3.1

Ersetze im obigen Beispiel pyyaml durch den Paketnamen und 5.3.1 durch die Paketversion, die du ignorieren möchtest.

Über eine Konfigurationsdatei ignorieren

Die angewendeten Ignorierregeln werden in der Konfigurationsdatei config.yaml gespeichert. Diese Datei lässt sich problemlos mit anderen Entwicklern teilen oder sogar in ein Remote-Git-Repository committen. Diese Dateien befinden sich immer im Ordner .cycode. Der Ordnername beginnt mit einem Punkt (.), daher musst du die Anzeige versteckter Dateien aktivieren, um ihn zu sehen.

Speicherort der Konfigurationsdateien

Standardmäßig speichern alle cycode ignore-Befehle die Ignorierregel im aktuellen Verzeichnis, aus dem die CLI ausgeführt wurde.

Beispiel: Wenn du einen Ignorierbefehl der CLI aus /Users/name/projects/backend ausführst, wird config.yaml in /Users/name/projects/backend/.cycode erstellt.

➜  backend  pwd
/Users/name/projects/backend
➜  backend  cycode ignore --by-value test-value
➜  backend  tree -a
.
└── .cycode
    └── config.yaml

2 directories, 1 file

Alternativ können Ignorierregeln in den globalen Konfigurationsdateien gespeichert werden. Der Pfad zur globalen Konfiguration lautet ~/.cycode/config.yaml, wobei ~ unter macOS für users home directory, for example, /Users/name` steht.

Zum Speichern im globalen Bereich kannst du das Flag -g des Befehls cycode ignore verwenden. Zum Beispiel: cycode ignore -g --by-value test-value.

Richtiges Arbeitsverzeichnis

Es ist äußerst wichtig, den Ordner .cycode am selben Ort abzulegen, von dem aus du die CLI ausführst. Überprüfe dies besonders sorgfältig, wenn du mit verschiedenen Umgebungen wie CI/CD (GitHub Actions, Jenkins usw.) arbeitest.

Du kannst den Ordner .cycode im Stammverzeichnis deines Repositorys committen. In diesem Fall musst du CLI-Scans vom Stammverzeichnis des Repositorys ausführen. Wenn das nicht deinen Anforderungen entspricht, kannst du den Ordner .cycode vorübergehend an einen beliebigen Ort kopieren und den CLI-Scan von dort ausführen.

Regeln zum Ignorieren von Strukturen in der Konfiguration

Es ist wichtig zu verstehen, wie die CLI ignorierte Regeln speichert, damit Sie diese Konfigurationsdateien lesen oder sogar ohne die CLI ändern können.

Die abstrakte YAML-Struktur:

exclusions:
  {scanTypeName}:
    {ignoringType}:
    - someIgnoringValue1
    - someIgnoringValue2

Mögliche Werte für scanTypeName: iac, sca, sast, secret.

Mögliche Werte für ignoringType: paths, values, rules, packages, shas, cves.

[!WARNING] Werte für „Ignorieren nach Wert“ werden nicht als Klartext gespeichert! Die CLI speichert stattdessen sha256-Hashes der Werte. Wenn Sie die Konfigurationsdatei manuell ändern, sollten Sie Hashes der Zeichenfolge eintragen.

Beispiel für ein echtes config.yaml:

exclusions:
  iac:
    rules:
    - bdaa88e2-5e7c-46ff-ac2a-29721418c59c
  sca:
    packages:
    - pyyaml@5.3.1
  secret:
    paths:
    - /Users/name/projects/build
    rules:
    - ce3a4de0-9dfc-448b-a004-c538cf8b4710
    shas:
    - a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0
    values:
    - a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3
    - 60303ae22b998861bce3b28f33eec1be758a213c86c93c076dbe9f558c11c752

Report-Befehl

SBOM-Bericht erstellen

Eine Software-Stückliste (SBOM) ist eine Bestandsaufnahme aller Komponenten und Softwareabhängigkeiten, die an der Entwicklung und Bereitstellung einer Anwendung beteiligt sind. Mit diesem Befehl können Sie einen SBOM-Bericht für Ihr lokales Projekt oder die URI Ihres Repositorys erstellen.

Für diesen Befehl stehen die folgenden Optionen zur Verfügung:

Option	Beschreibung	Erforderlich	Standard
`-f, --format [spdx-2.2\|spdx-2.3\|cyclonedx-1.4]`	SBOM-Format	Ja
`-o, --output-format [JSON]`	Ausgabeformat der Datei angeben	Nein	json
`--output-file PATH`	Ausgabedatei	Nein	automatisch generierter Dateiname im aktuellen Verzeichnis
`--include-vulnerabilities`	Sicherheitslücken einschließen	Nein	False
`--include-dev-dependencies`	Entwicklungsabhängigkeiten einschließen	Nein	False

Für diesen Befehl stehen die folgenden Befehle zur Verfügung:

Befehl	Beschreibung
`path`	SBOM-Bericht für den im Befehl angegebenen Pfad erstellen
`repository-url`	SBOM-Bericht für die im Befehl angegebene Repository-URI erstellen

Repository

So erstellen Sie einen SBOM-Bericht für eine Repository-URI:
cycode report sbom --format <sbom format> --include-vulnerabilities --include-dev-dependencies --output-file </path/to/file> repository_url <repository url>

Beispiel:
cycode report sbom --format spdx-2.3 --include-vulnerabilities --include-dev-dependencies repository_url https://github.com/cycodehq/cycode-cli.git

Lokales Projekt

So erstellen Sie einen SBOM-Bericht für einen Pfad:
cycode report sbom --format <sbom format> --include-vulnerabilities --include-dev-dependencies --output-file </path/to/file> path </path/to/project>

Beispiel:
cycode report sbom --format spdx-2.3 --include-vulnerabilities --include-dev-dependencies path /path/to/local/project

Der Unterbefehl path unterstützt die folgenden zusätzlichen Optionen:

Option	Beschreibung
`--no-restore`	Sperrdatei-Wiederherstellung überspringen und nur direkte Abhängigkeiten scannen. Weitere Informationen finden Sie unter Option zur Sperrdatei-Wiederherstellung.
`--gradle-all-sub-projects`	Den Gradle-Wiederherstellungsbefehl für alle Unterprojekte ausführen (vom Stammverzeichnis eines Gradle-Multi-Projekt-Builds aus verwenden).
`--maven-settings-file`	Nur für Maven: Ermöglicht die Verwendung einer benutzerdefinierten Datei settings.xml beim Erstellen des Abhängigkeitsbaums.

Import-Befehl

SBOM importieren

Eine Software-Stückliste (SBOM) ist eine Bestandsaufnahme aller Komponenten und Softwareabhängigkeiten, die an der Entwicklung und Bereitstellung einer Anwendung beteiligt sind. Mit diesem Befehl können Sie eine SBOM-Datei aus Ihrem Dateisystem in Cycode importieren.

Für diesen Befehl stehen die folgenden Optionen zur Verfügung:

Option	Beschreibung	Erforderlich	Standard
`-n, --name TEXT`	Anzeigename der SBOM	Ja
`-v, --vendor TEXT`	Name der Entität, die die SBOM bereitgestellt hat	Ja
`-l, --label TEXT`	Label an die SBOM anhängen	Nein
`-o, --owner TEXT`	E-Mail-Adresse des Cycode-Benutzers, der als Kontaktperson für diese SBOM dient	Nein
`-b, --business-impact [High \| Medium \| Low]`	Geschäftliche Auswirkung	Nein	Medium

Beispiel:
cycode import sbom --name example-sbom --vendor cycode -label tag1 -label tag2 --owner example@cycode.com /path/to/local/project

Scan-Protokolle

Alle CLI-Scans werden in Cycode protokolliert. Die Protokolle finden Sie unter Settings > CLI Logs.

Syntaxhilfe

Sie können jederzeit das Argument --help zu einem beliebigen Befehl hinzufügen, um eine Hilfemeldung mit den verfügbaren Optionen und ihrer Syntax anzuzeigen.

Geben Sie den folgenden Befehl ein, um die allgemeine Hilfe anzuzeigen:

cycode --help

Geben Sie Folgendes ein, um die Scan-Optionen anzuzeigen:

cycode scan --help

Geben Sie Folgendes ein, um die für einen bestimmten Scantyp verfügbaren Optionen anzuzeigen:

cycode scan {{option}} --help

Um beispielsweise die für einen Pfadscan verfügbaren Optionen anzuzeigen, geben Sie Folgendes ein:

cycode scan path --help

Verwenden Sie diesen Befehl, um die für die Funktion zum Ignorieren von Scans verfügbaren Optionen anzuzeigen:

cycode ignore --help

Verwenden Sie diesen Befehl, um die für einen Bericht verfügbaren Optionen anzuzeigen:

cycode report --help

Geben Sie Folgendes ein, um die für einen bestimmten Berichtstyp verfügbaren Optionen anzuzeigen:

cycode scan {{option}} --help