Skip to main content

​
Einführung

Die Corgea CLI ist ein leistungsstarkes Entwicklungstool, mit dem Sie Schwachstellen in Ihrem Code finden und beheben können. Corgea identifiziert mithilfe des KI-gestützten Scanners BLAST komplexe Sicherheitsprobleme wie Fehler in der Geschäftslogik, Authentifizierungsschwachstellen und andere schwer erkennbare Bugs. Über die CLI können Sie Ihre Codebasis scannen, Befunde untersuchen, Fixes anwenden und vieles mehr – mit einem auf Entwickler zugeschnittenen Bedienkonzept.
Erweitern Sie Ihren KI-Coding-Agenten. Die Corgea CLI bildet auch die Grundlage für unsere agentenbasierten Integrationen: Installieren Sie den Corgea Agent Skill und lassen Sie Ihren KI-Agenten (Cursor, Claude Code, Copilot und weitere) Schwachstellen für Sie scannen, priorisieren und beheben.

​
Funktionen

  • Unterstützung mehrerer Scanner: Scannen Sie mit BLAST (unserem KI-gestützten Scanner) und laden Sie Berichte von Semgrep, Snyk, Checkmarx, CodeQL, Fortify und Coverity hoch.
  • Issue-Management: Listen Sie Sicherheitsbefunde auf, untersuchen und verwalten Sie sie.
  • Fix-Integration: Zeigen Sie KI-generierte Fixes für Schwachstellen direkt in Ihrem Terminal an und wenden Sie sie an.
  • Abhängigkeitsanalyse: Erstellen Sie Offline-Abhängigkeitsinventare, prüfen Sie Abhängigkeitsdiagramme, generieren Sie SBOMs und bewerten Sie Abhängigkeitsrichtlinien mit corgea deps.
  • Container-Image-Scanning: Scannen Sie mit corgea scan --include-image vollständig gebaute Container-Images gemeinsam mit Ihrem Code.
  • Prüfung von Package Advisories: Prüfen Sie bekannte Sicherheitshinweise, bevor Sie ein npm- oder PyPI-Paket auswählen oder installieren.
  • Package Manager Install Gate: Prüfen Sie Installationen mit npm, yarn, pnpm, pip und uv auf bekanntermaßen anfällige, bösartige oder verdächtig neue Pakete, bevor diese in das Projekt gelangen – siehe Package Manager Install Gate.
  • Flexible Ausgabe: Unterstützung sowohl für menschenlesbare als auch JSON-Ausgabeformate für einfachere CI-Integrationen.
  • CI/CD-Integration: Lassen Sie Builds abhängig von Schweregraden oder benutzerdefinierten Blocking Rules fehlschlagen.
  • Scan-Verwaltung: Verfolgen Sie den Scan-Fortschritt und die Ergebnisse Ihrer Projekte.
  • Installation von Agent Skills: Installieren Sie freigegebene Agent Skills aus der Corgea Registry in unterstützten Coding-Agenten.
  • Installation des MCP-Servers: Schreiben Sie den Corgea-MCP-Server mit corgea mcp install in unterstützte Coding-Agenten.
  • Inkrementelle Scans: BLAST-Scans analysieren standardmäßig nur Dateien, die sich seit dem letzten sauberen Scan des Projekts geändert haben (CLI 1.12.0 oder neuer). Mit --disable-incremental analysieren Sie jede Datei.

​
Voraussetzungen

  • Corgea-Konto: Ein aktives Corgea-Konto.
  • Token zur Authentifizierung: Ein gültiges Corgea-API-Token oder JWT-Zugriffstoken.
Die Offline-Befehle corgea deps scan, graph, explain, diff, sbom und policy init benötigen weder ein Corgea-Konto noch ein Token, eine Konfiguration oder Netzwerkzugriff.

​
Installationsanleitung

​
Mit npm installieren

Das npm-Paket bündelt native Binärdateien für unterstützte Plattformen und wählt zur Laufzeit die richtige Binärdatei für Ihr Betriebssystem und Ihre Architektur aus.

​
Mit uv installieren

Für Python-Benutzer ist dies die bevorzugte Installationsmethode. uv tool install erstellt eine isolierte Tool-Umgebung aus dem PyPI-Paket und stellt die CLI als corgea auf Ihrem PATH bereit.
Wenn uv meldet, dass sein Tool-Verzeichnis nicht auf Ihrem PATH ist, führen Sie aus:

​
Mit pip installieren

Wenn Sie uv nicht verwenden, können Sie die Corgea-CLI mit dem Python-Paketinstaller pip installieren:
Dieser Befehl lädt das Corgea-CLI-Paket von PyPI (Python Package Index) herunter und installiert es auf Ihrem System. Weitere Details zum Paket finden Sie auf seiner PyPI-Seite: https://pypi.org/project/corgea-cli/.

​
Mit Homebrew installieren

Um das Corgea-CLI-Tool mit Homebrew zu installieren, fügen Sie zuerst den Corgea-Tap hinzu und installieren dann die CLI:

​
Manuell installieren

Laden Sie das Archiv für Ihre Plattform aus dem neuesten Release herunter, entpacken Sie es und verschieben Sie die Binärdatei corgea in ein Verzeichnis in Ihrem PATH. Die folgenden latest/download-URLs verweisen stets auf das neueste Release.
Die GNU-Linux-Builds benötigen glibc 2.17 oder neuer. Vollständig statische musl-Builds ohne libc-Abhängigkeit sind für beide Architekturen als corgea-x86_64-unknown-linux-musl.zip und corgea-aarch64-unknown-linux-musl.zip verfügbar; sie eignen sich für minimale Container und CI-Runner.

​
Authentifizierung

​
Über die CLI anmelden

Führen Sie zur Authentifizierung den folgenden Befehl aus. Sie werden zur Webanwendung weitergeleitet, um die CLI zu autorisieren:

​
Mit benutzerdefiniertem Scope anmelden (für Single-Tenant-Instanzen)

Hinweis: Der Unternehmens-Scope entspricht Ihrer Corgea-Subdomain, zum Beispiel https://your-company.corgea.app.

​
Mit Token anmelden (API-Token oder JWT)

Verwenden Sie für automatisierte Pipelines und CI/CD-Umgebungen die Token-Authentifizierung, um sich zuverlässig und nicht interaktiv anzumelden. Sie können ein Corgea-API-Token oder ein JWT-Zugriffstoken übergeben:
Sie können das Token auch in einer Umgebungsvariable setzen:

​
Auf eine Single-Tenant-Instanz verweisen

Bei einer Single-Tenant-Instanz müssen Sie die CLI mit der Option --url auf Ihre Instanz verweisen:
Sie können die URL auch in einer Umgebungsvariable setzen, und die CLI erkennt sie automatisch:

​
Verwendung

​
Befehle und Optionen

​
Package Advisories prüfen

Mit corgea advisories check prüfen Sie bekannte Sicherheitshinweise, bevor Sie ein npm- oder PyPI-Paket auswählen oder installieren. Eine Prüfung ohne Versionsangabe listet den Advisory-Verlauf des Pakets auf. Geben Sie eine exakte Version an, um eine Bewertung für dieses Release zu erhalten.
Als Ecosystem sind npm und pypi zulässig; pip wird als Alias akzeptiert. npm-Versionen müssen vollständig und exakt angegeben werden, beispielsweise 1.2.3. Versionsbereiche, Tags und Teilversionen werden nicht unterstützt. Bei PyPI können Sie package@version oder die pip-Syntax package==version verwenden. Ergebnisse ohne Versionsangabe helfen Ihnen, vor der Auswahl einer Version den Advisory-Verlauf zu prüfen. Ergebnisse für eine exakte Version enthalten bekannte Advisory-Details, gegebenenfalls Informationen zu korrigierten Versionen und eine Empfehlung für eine sichere Version, sofern alle gemeldeten Advisories einen Fix aufweisen. Der schreibgeschützte Befehl benötigt Netzwerkzugriff; die Installation wird weiterhin über das Package Manager Install Gate abgesichert. Mit --json erhalten Sie eine maschinenlesbare Antwort nach Schemaversion 1. Der Exit-Code lautet 0, wenn keine Advisories gefunden wurden, 1 bei vorhandenen Advisories und 2 bei einem Fehler. Ist ein Paket nicht in der Advisory-Datenbank vorhanden, wird ebenfalls Exit-Code 0 zurückgegeben.

​
Package Manager Install Gate

Verwenden Sie corgea npm, corgea yarn, corgea pnpm, corgea pip oder corgea uv, um unterstützte Paketmanager-Installationsbefehle über Corgea auszuführen, bevor Abhängigkeiten installiert werden.
Corgea prüft jede aufgelöste Version anhand öffentlicher Schwachstellendaten auf bekanntermaßen anfällige oder bösartige Releases – ohne Token – und blockiert ungewöhnlich neue Releases (siehe Recency Gate unten). Anfällige, bösartige oder zu neue Versionen stoppen die Installation, bevor der Paketmanager ausgeführt wird. Wrapper-Flags stehen zwischen dem Namen des Paketmanagers und dessen Befehl, beispielsweise corgea pip --force install requests. Recency Gate. Zusätzlich zu Schwachstellendaten blockiert Corgea jedes ausdrücklich angegebene Installationsziel, dessen aufgelöste Version innerhalb eines definierten Zeitfensters veröffentlicht wurde. So lassen sich kurz zuvor veröffentlichte Typosquatting-Pakete und Paketübernahmen abfangen, bevor Advisory-Feeds reagieren. Das Gate ist standardmäßig aktiviert und verwendet ein Zeitfenster von 14 Tagen. Konfigurieren Sie es in ~/.corgea/config.toml (recency_gate = false zum Deaktivieren, recency_threshold_days zum Anpassen des Zeitfensters) oder über CORGEA_RECENCY_GATE und CORGEA_RECENCY_THRESHOLD_DAYS. Pakete ohne ermittelbares Veröffentlichungsdatum lösen das Gate nicht aus. Die Bewertung als anfällig oder bösartig hat Vorrang vor dem Alter; --force umgeht das Gate für eine einzelne Installation. Abdeckung. pip install und npm install lösen die gesamte vorgesehene Installation einschließlich transitiver Abhängigkeiten auf. Dadurch blockiert auch eine anfällige transitive Abhängigkeit den Befehl. Schlägt der Dry-Run-Resolver fehl, gibt Corgea eine Warnung aus und prüft stattdessen die ausdrücklich angegebenen Pakete. npm ci wird anhand der Lockdatei des Projekts und uv sync anhand von uv.lock geprüft. Somit wird der vollständige gesperrte Abhängigkeitsbestand geprüft, obwohl die Befehle keine Paketnamen enthalten. Das uv-Gate erfasst außerdem ausdrücklich angegebene Ziele für uv add ... und uv pip install ...; uv lock wird unverändert ausgeführt, da es nichts installiert. yarn und pnpm prüfen nur ausdrücklich angegebene Ziele, weil kein sicherer Dry-Run-Resolver verfügbar ist. Installationen ohne Paketangabe. Ein einfaches npm install wird anhand der package.json des Projekts geprüft. Einfache yarn- und pnpm-Aufrufe sowie installierende uv-Befehle können nicht vorab geprüft werden. Corgea weist darauf hin und führt sie ungeprüft aus.
Öffentlicher und authentifizierter Modus. Ohne Token arbeitet das Gate im öffentlichen Modus: Anfällige und bösartige Pakete werden blockiert, nicht verifizierbare Pakete und Abfragefehler führen jedoch nur zu Warnungen und lassen die Installation zu. Wiederholte Fehler werden in einer Zusammenfassungszeile gebündelt. Mit einem Token aus CORGEA_TOKEN oder corgea login und der standardmäßigen Vulnerability API arbeitet das Gate im authentifizierten Modus nach dem Fail-Closed-Prinzip. Nicht verifizierbare Pakete, Fehler bei der Abhängigkeitsauflösung, Ausfälle der Vulnerability API und eine unvollständige Baumabdeckung bei Paketmanagern, die normalerweise den vollständigen Baum auflösen (pip, npm, uv), blockieren die Installation, sofern Sie nicht --force angeben. Benutzerdefinierte Vulnerability API. Wenn CORGEA_VULN_API_URL auf einen benutzerdefinierten Endpunkt verweist, sendet Corgea Ihr Token nicht dorthin; das Gate bleibt deshalb im öffentlichen Modus. Mit CORGEA_VULN_API_SEND_TOKEN_TO_CUSTOM_URL=1 aktivieren Sie die authentifizierte Durchsetzung für einen Endpunkt, dem Sie vertrauen. Extern verwaltetes Python. Für pip verweigert Corgea Installationen in extern verwalteten Umgebungen (PEP 668), bevor die Registry-Prüfungen durchgeführt werden. Aktivieren Sie eine virtuelle Umgebung oder übergeben Sie --force, um dies zu umgehen. Corgea führt den passenden Paketmanager von Ihrem PATH aus. Für corgea pip ... versucht es pip3, wenn pip fehlt; wenn keiner existiert, beendet die CLI 127 und nennt die fehlende Binärdatei. Befehle und Flags, die keine Installation auslösen, werden an den Paketmanager weitergegeben. Beispielsweise meldet corgea npm --version die installierte npm-Version, während corgea --version die Version der Corgea CLI ausgibt. Befunde. Wenn ein aufgelöstes Paket anfällig ist, zeigen die Befunde im Abhängigkeitsbaum dessen Herkunft:
  • (from requirements) — über eine pip-Anforderungsdatei angefordert.
  • (already in package.json) — bereits eine direkte npm-Abhängigkeit.
  • (transitive) — über eine andere Abhängigkeit eingebunden.
Ist das ausdrücklich angegebene Paket nicht anfällig, enthält der aufgelöste Baum aber bereits ein anfälliges Paket, nennt die Ablehnung den vorhandenen Baum als Quelle. Advisory-Zeilen zeigen die angegebene korrigierte Version oder weisen darauf hin, dass keine bekannt ist. Sind für alle Advisories eines Pakets Fixdaten vorhanden, gibt Corgea safe version: axios@0.21.2 aus. Bei anfälligen direkten npm-Abhängigkeiten kann zusätzlich fix with: corgea npm install package-name@version (advertised fix) erscheinen. Anzahl der Schwachstellen und Exit-Verhalten richten sich nach dem ursprünglichen Installationsziel. JSON-Ausgabe. --json gibt einen einzelnen Bericht auf stdout aus und schreibt Fortschritt zur Auflösung und Paketprüfung nach stderr, damit stdout für maschinenlesbare Ausgabe verfügbar bleibt. stdout des Paketmanagers wird ebenfalls nach stderr umgeleitet. Schemaversion 2 enthält manager, subcommand, args, recency_threshold_days (das aktive Zeitfenster oder null, wenn das Gate deaktiviert ist; zusammen mit age_seconds des jeweiligen Ergebnisses zu verwenden), eine nach named und tree aufgeteilte summary, verdict_mode, ein results-Array und bei ausgeführter Baumauflösung ein tree-Objekt. Baumeinträge haben für origin den Wert requested, pre-existing oder transitive. Bekanntermaßen bösartige Pakete verwenden den separaten status malicious, einen booleschen Wert malware pro Treffer und einen eigenen Zähler malicious in jedem Zusammenfassungsobjekt. remediation ist für sie immer null, da das Paket entfernt und nicht aktualisiert werden sollte. Bei anfälligen Paketen wird eine sichere Version weiterhin nur angegeben, wenn sie sämtliche Advisories abdeckt.

​
Agent Skills installieren

Installieren Sie einen freigegebenen Skill aus der Corgea Registry in das Skills-Verzeichnis Ihres Coding-Agenten:
Unterstützte Agenten-IDs sind cursor, claude-code, codex, github-copilot, gemini-cli, windsurf, opencode und universal. Verwenden Sie --scope project, um in das aktuelle Repository zu installieren, --scope user, um für Ihr Benutzerkonto zu installieren, oder --dir, um in ein benutzerdefiniertes Skills-Verzeichnis zu installieren. Hängen Sie eine bestimmte Version an den Skill-Namen an:
Sie können auch einen Standard-Agenten für zukünftige Installationen speichern:
Sie können den Standard auch direkt beim Installieren speichern, indem Sie --set-default hinzufügen. Damit wird der übergebene --agent-Wert dauerhaft übernommen:
Die Umgebungsvariable CORGEA_DEFAULT_AGENT überschreibt den gespeicherten Standard. Das ist in CI-Umgebungen nützlich, in denen nicht in die Konfigurationsdatei geschrieben werden soll.

​
MCP-Server installieren

Schreiben Sie den Corgea-MCP-Server mit der URL und dem Token aus corgea login in die Konfiguration eines Coding-Agenten (CLI 1.13.0 oder neuer):
Wenn die CLI nicht installiert ist, führen Sie denselben Ablauf mit npx aus. Für eine Single-Tenant-Instanz übergeben Sie --url:
In der Multi-Tenant-Cloud lassen Sie --url weg:
Unterstützte Agenten-IDs sind cursor, claude, claude-code, windsurf, vscode, gemini-cli, continue und opencode. Aliase sind unter anderem claude-desktop, vs-code, github-copilot, copilot, gemini und open-code. Verwenden Sie --scope user (Standard) oder --scope project. Claude Desktop hat keine projektbezogene MCP-Konfiguration. --dir schreibt in einen benutzerdefinierten Pfad, und --set-default speichert den --agent-Wert wie bei corgea skill install. Bei einer erneuten Installation wird der vorhandene Corgea-Eintrag ersetzt, damit URL und Token aktuell bleiben. Andere Server bleiben unverändert. Eine Installation mit --scope project schreibt das Token in die Datei — committen Sie sie nicht. Starten Sie den Agenten nach der Installation neu, damit er den neuen Server lädt. Client-spezifische Hinweise und verfügbare Tools finden Sie unter Model Context Protocol (MCP).

​
Scan-Bericht hochladen

Laden Sie einen Scan-Bericht über STDIN oder als Datei (JSON, SARIF, FPR oder Coverity XML) zu Corgea hoch:
Um den in Corgea für hochgeladene Berichte angezeigten Projektnamen zu steuern, verwenden Sie --project-name. Wenn dies weggelassen wird, verwendet die CLI standardmäßig den Namen des Git-Repositorys, wenn verfügbar, und greift andernfalls auf den aktuellen Verzeichnisnamen zurück.
Standardmäßig kehrt der Befehl nach dem Upload zurück und gibt die URL der Scan-Seite aus. Mit --wait wartet er auf den Abschluss und gibt die Ergebnisse aus:
Große Berichte lädt die CLI in Blöcken hoch. Dabei prüft sie den serverseitigen Fortschritt und beendet den Vorgang mit einem Exit-Code ungleich null, wenn der Server einen unerwarteten Offset meldet oder nach Abschluss keine Scan-ID zurückgibt.

​
Codebasis scannen

Um Ihr aktuelles Verzeichnis mit dem Standard-BLAST-Scanner zu scannen:
Die CLI meldet einen dirty Worktree nur, wenn git status das ebenfalls tut. Scans mit nicht committeten Änderungen werden vollständig ausgeführt, damit die Ergebnisse den hochgeladenen Dateien entsprechen – auch wenn sich die aktuelle Commit-SHA nicht geändert hat. Ignorierte oder inhaltlich unveränderte Dateien erzwingen keinen vollständigen Scan und setzen worktree_dirty nicht. BLAST-Scans (CLI 1.12.0 oder neuer) sind standardmäßig inkrementell. Die CLI findet den neuesten abgeschlossenen Scan eines sauberen Worktrees in diesem Projekt, vergleicht den aktuellen Commit damit und sendet die Liste der geänderten Dateien mit dem Upload. Corgea analysiert nur diese Dateien und übernimmt bestehende Befunde für alle anderen. Das gesamte Projekt wird weiterhin hochgeladen, damit unveränderte Dateien als Kontext verfügbar bleiben.
--disable-incremental erzwingt eine neue Analyse jeder Datei — zum Beispiel nach einer Änderung der Scanner-Konfiguration außerhalb von corgea.yaml. Die inkrementelle Analyse wird mit Begründung übersprungen, wenn kein Git-Repository oder Commit zum Vergleichen vorhanden ist, der Worktree dirty ist, kein früherer Scan eines sauberen Worktrees existiert oder der zuletzt gescannte Commit in einem flachen Clone fehlt. Sie wird stillschweigend übersprungen, wenn --only-uncommitted, --target oder --exclude den Upload bereits einschränken. Ein älterer Corgea-Server ignoriert die inkrementellen Felder und führt eine vollständige Analyse aus. Um einen anderen Scanner anzugeben, wie zum Beispiel Semgrep:
Sie können --fail-on (nur BLAST-Scans) mit einer oder mehreren kommagetrennten Bedingungen verwenden: CR, HI, ME, LO oder malicious. Eine Schweregradbedingung erfasst Befunde dieses oder eines höheren Schweregrads. ME erfasst beispielsweise auch Befunde mit HI und CR. malicious erfasst Abhängigkeitsbefunde, die als bösartig klassifiziert wurden. Sobald eine der angegebenen Bedingungen zutrifft, endet der Befehl mit einem Exit-Code ungleich null. Beispiele:
Beispielsweise schlägt --fail-on ME bei Befunden mit ME, HI oder CR fehl. Sind mehrere Bedingungen angegeben, schlägt der Scan fehl, sobald eine davon zutrifft. Eine anfällige Abhängigkeit, die nicht als bösartig klassifiziert ist, erfüllt die Bedingung malicious nicht. Oder lassen Sie den Befehl anhand jeder aktiven Blocking Rule in der Webanwendung fehlschlagen – unabhängig davon, ob die Regel für Pull Requests oder CI gilt:
--fail ist ab CLI 1.10.0 veraltet. Bevorzugen Sie --block-on, um die CI-Regeln zu benennen, die eine Pipeline durchsetzen soll. Um bestimmte Regeln in einer CI-Pipeline durchzusetzen, setzen Sie in der Webanwendung das Ziel Applies To jeder Regel auf CI und übergeben Sie den generierten Slug an --block-on (CLI 1.10.0 oder neuer):
Sie können mehrere Slugs als kommagetrennte Liste angeben, beispielsweise criticals,malicious-deps. Es können nur aktive CI-Regeln verwendet werden; ein unbekannter Slug, eine inaktive Regel oder eine Pull-Request-Regel führt zu einem Konfigurationsfehler. --block-on wird nur vom BLAST-Scanner unterstützt und kann nicht mit --fail oder --fail-on kombiniert werden. --fail und --fail-on können auch nicht miteinander kombiniert werden. Blockierregeln werden in der Corgea-Cloud ausgewertet, daher wartet der Befehl darauf — bis zu 35 Minuten. Läuft die Wartezeit ab, wird mit 1 beendet, statt einen nicht ausgewerteten Scan durchzulassen. Setzen Sie CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS auf die gewünschte Wartezeit in Sekunden:
Ein Scan, der eine Sperrregel auslöst, schreibt einen etwaigen --out-file-Bericht und die --sbom-Ausgabe dennoch, bevor er beendet wird. Standardmäßig scannt scan das gesamte Projekt. Um nur noch nicht committete Änderungen zu scannen, verwenden Sie --only-uncommitted.
Bei BLAST-Scans können Sie mit --target bestimmte Dateien oder Teilbereiche Ihres Projekts auswählen. Die Option akzeptiert kommagetrennte Dateipfade, Verzeichnispfade, Glob-Muster, Git-Selektoren oder stdin. Beispiele:
Sie können Dateien von BLAST-Scans mit der Option --exclude ausschließen. Diese akzeptiert durch Kommas getrennte Glob-Muster und kann mit oder ohne --target verwendet werden.
Hinweis: --only-uncommitted und --target können nicht zusammen verwendet werden. Um Dateien während eines BLAST-Scans zu überspringen, verwenden Sie --exclude mit durch Kommas getrennten Glob-Mustern. Es kann mit --target kombiniert werden, um eine Teilmenge zu scannen und gleichzeitig Übereinstimmungen innerhalb dieser auszuschließen.
Um den in Corgea angezeigten Projektnamen zu steuern, verwenden Sie --project-name. Wenn dies weggelassen wird, verwendet die CLI standardmäßig den Namen des Git-Repositorys, falls verfügbar, und fällt auf den aktuellen Verzeichnisnamen zurück.
Um einem BLAST-Scan benutzerdefinierte Metadaten hinzuzufügen, geben Sie --metadata wiederholt mit KEY=VALUE-Paaren an. Die Werte werden dem Scan beigefügt und erscheinen in der JSON-Ausgabe der Scan-Liste.
--metadata wird nur vom BLAST-Scanner unterstützt. Jeder Eintrag muss einen nicht leeren Schlüssel haben; wenn derselbe Schlüssel mehr als einmal angegeben wird, wird der letzte Wert verwendet. In der Corgea-Webanwendung erscheinen Scan-Metadaten als schreibgeschützte Labels auf der Scans-Seite, in den Scan-Details und in den Issue-Details.
Scans-Seite mit schreibgeschützten Scan-Metadaten-Chips auf jedem Scan
Scan-Details-Header mit Scan-Metadaten-Chips
Issue-Details-Seitenleiste mit Scan-Metadaten-Chips
Auf der Scans-Seite können Sie die Filter erweitern, um nach einem Metadatenschlüssel, einem exakten Schlüssel-Wert-Paar oder einem Wert über alle Metadaten hinweg zu filtern.
Filterpanel der Scans-Seite mit Feldern für Scan-Metadatenschlüssel und -wert
Die Hauptsuche akzeptiert außerdem has:key und key:value, beispielsweise has:pipeline_url oder environment:production.
Scans-Suche gefiltert mit has:version
Der reguläre BLAST-Scan umfasst mehrere Scans:
  • Blast Base AI Scan
  • PolicyIQ Scan
  • Malicious Code Detection Scan
  • Secrets Detection Scan
  • Erkennung von persönlich identifizierbaren Informationen (PII)
Standardmäßig werden alle diese Scans ausgeführt, sofern sie im Tarif Ihres Unternehmenskontos enthalten sind. Mit --scan-type können Sie den Scan auf einen oder mehrere Typen beschränken.
oder mehrere Typen
Mit --policy beschränken Sie einen PolicyIQ-Scan auf bestimmte Richtlinien. Übergeben Sie dazu eine oder mehrere Richtlinien-IDs.
--scan-type und --policy gelten nur für BLAST-Scans. Wenn Sie --policy ohne --scan-type policy übergeben, laufen die übrigen BLAST-Scantypen weiter und die CLI gibt eine Warnung aus.

​
Container-Images scannen

Standardmäßig erkennt Corgea die Images, die Ihr Projekt in Dockerfile- und Docker-Compose-Dateien referenziert. Um stattdessen ein vollständig gebautes Image zu scannen – etwa eines, das Sie gerade in der CI gebaut haben und das nie in eine Registry gepusht wurde –, übergeben Sie es mit --include-image:
Die Option kann mehrfach angegeben werden, sodass Sie mehrere Images in einem Scan berücksichtigen:
Jedes Image wird von Ihrer lokalen Container-Engine exportiert und mit Ihrem Projekt hochgeladen, sodass es genau so gescannt wird, wie es ausgeliefert wird. Wenn Sie --include-image verwenden, scannt Corgea die übergebenen Images, anstatt Ihren Quellcode nach Basis-Images zu durchsuchen. Voraussetzungen und Verhalten:
  • Container-Scanning muss für Ihr Konto aktiviert sein.
  • docker oder podman muss in Ihrem PATH verfügbar sein. Corgea verwendet das zuerst gefundene Programm; mit CORGEA_CONTAINER_ENGINE legen Sie es explizit fest.
  • Ein Image, das lokal nicht vorhanden ist, wird zuvor gepullt. Images aus einer privaten Registry funktionieren daher, solange Ihre Container-Engine dort bereits authentifiziert ist.
  • --include-image wird nur vom BLAST-Scanner unterstützt.
Wie Container-Befunde gemeldet und verfolgt werden, beschreibt Container-Image-Scanning.

​
Scan-Bericht exportieren

Mit der Corgea CLI können Sie Scan-Ergebnisse in eine Datei exportieren, beispielsweise bei der Ausführung in einer CI-Pipeline. Verwenden Sie dazu --out-format und --out-file.
Die CLI unterstützt derzeit HTML, JSON, SARIF und Markdown als Ausgabeformate.
Bei BLAST-Scans erzeugt --sbom nach Abschluss eine CycloneDX-SBOM. Standardmäßig wird bom.json verwendet; optional kann ein Pfad angegeben werden:
Berichte und SBOMs werden geschrieben, bevor --fail und --block-on ausgewertet werden. Ein Scan, der wegen einer ausgelösten Sperrregel mit einem Exit-Code ungleich null endet, hinterlässt Bericht und SBOM dennoch auf der Festplatte, sodass ein späterer CI-Schritt sie immer einlesen kann.

​
Inkrementelle Scans

BLAST-Scans werden standardmäßig inkrementell ausgeführt. Corgea lädt das gesamte Projekt hoch, analysiert aber nur Dateien, die sich seit dem letzten geeigneten Scan des Projekts geändert haben. Unveränderte Dateien behalten ihre vorhandenen Befunde, sodass das Ergebnis weiterhin das gesamte Projekt abbildet. Die CLI scannt automatisch jede Datei, wenn sie nicht sicher auf einem früheren Scan aufbauen kann, etwa wenn kein Git-Commit oder geeigneter Scan eines unveränderten Worktrees verfügbar ist, der Worktree uncommittete Änderungen enthält oder der frühere Commit in einem Shallow Clone fehlt. Inkrementelles Verhalten wird ebenfalls übersprungen, wenn --only-uncommitted, --target oder --exclude den Upload einschränkt. Mit --disable-incremental zwingen Sie BLAST, jede Datei zu analysieren, beispielsweise nach einer Änderung der Scanner-Konfiguration außerhalb von corgea.yaml:
Bei einem Dirty Worktree erlaubt --ignore-dirty-worktree einen inkrementellen Scan, indem der frühere Scan mit dem Arbeitsverzeichnis verglichen wird. Geänderte und nicht verfolgte Dateien werden dann in die Analyse einbezogen.

​
Einen aktuellen Scan desselben Commits wiederverwenden

Eine Pipeline, die für einen unveränderten Commit erneut läuft, kann den bereits vorhandenen Scan wiederverwenden, anstatt einen doppelten Scan zu bezahlen. Fügen Sie einem BLAST-Scan dazu --skip-if-commit-scanned-recently hinzu:
Wenn im Projekt bereits ein abgeschlossener Scan des aktuellen Commits innerhalb des Zeitfensters vorliegt, tritt dieser an die Stelle des neuen Scans: Die Ergebnistabelle, das --block-on-Gate samt Exit-Code und ein etwaiger --out-file-Bericht stammen dann daraus. Die Pipeline verhält sich gleich, unabhängig davon, ob tatsächlich ein Scan ausgeführt wurde. Mit --scanned-within legen Sie das Zeitfenster fest. Die Option ist nur zusammen mit --skip-if-commit-scanned-recently gültig. Zulässig sind Werte wie 90s, 30m, 24h und 7d; eine reine Zahl wird als Stunden interpretiert. Der Standardwert ist 24h, denn unveränderter Code bleibt Schwachstellenhinweisen ausgesetzt, die seit dem letzten Scan veröffentlicht wurden.
Um einen aktuellen Scan auch dann wiederzuverwenden, wenn dieser Worktree uncommittete Änderungen enthält oder der frühere Scan worktree_dirty=true gemeldet hat, übergeben Sie --ignore-dirty-worktree (CLI 1.11.1 oder höher). Ein neuer Scan meldet Corgea weiterhin den tatsächlichen Dirty-Status.
Damit ein späterer Schritt beide Fälle unterscheiden kann, gibt der Befehl CORGEA_SCAN_SKIPPED=true zusammen mit CORGEA_SCAN_ID=<id> aus, wenn ein Scan wiederverwendet wurde, und CORGEA_SCAN_SKIPPED=false, wenn ein Scan ausgeführt wurde. Diese Zeilen sind Ausgaben auf stdout, keine Umgebungsvariablen. Sie erscheinen nicht, wenn der Befehl endet, weil der aktuelle Commit nicht ermittelt werden kann. Kann die Wiederverwendungsprüfung die API nicht erreichen, warnt die CLI und führt einen neuen Scan aus. Was wiederverwendet werden kann. Corgea verwendet nur einen Scan wieder, der dieselbe Frage beantwortet – das ist strenger als eine reine Übereinstimmung des Commits. Ein Kandidat muss ein abgeschlossener BLAST-Scan des aktuellen Commits sein, auf einem Branch statt in einem Pull Request ausgeführt worden sein, aus einem unveränderten Worktree stammen und ohne gemeldete Scanner-Probleme abgeschlossen sein. In allen anderen Fällen läuft ein echter Scan: wenn im Zeitfenster nichts vorliegt, wenn der vorhandene Scan fehlgeschlagen ist oder noch läuft oder wenn der Worktree nicht zum Commit passt. --ignore-dirty-worktree überschreibt die Dirty-Worktree-Hälfte dieser Prüfung: Die Wiederverwendung erfolgt, wenn dieser Worktree dirty ist oder der frühere Scan worktree_dirty=true gemeldet hat. Ein früherer Scan, der das Flag nie gemeldet hat, wird weiterhin nicht wiederverwendet, weil sein Umfang unbekannt ist. Optionen, die sich nicht kombinieren lassen. Keine API gibt Auskunft darüber, wie ein früherer Scan zugeschnitten war. Daher lässt sich --skip-if-commit-scanned-recently nicht mit --only-uncommitted, --target, --scan-type, --policy, --include-image oder --disable-incremental kombinieren; der Befehl schlägt fehl, wenn Sie eine dieser Optionen übergeben. --exclude ist zulässig, gibt bei einer Wiederverwendung aber eine Warnung aus: Der wiederverwendete Scan deckt Dateien ab, die dieser Lauf übersprungen hätte, sodass Ergebnisse zu viel, aber nie zu wenig melden können. Wenn der aktuelle Commit nicht ermittelt werden kann – etwa weil das Verzeichnis kein Git-Repository ist oder das Repository noch keine Commits enthält –, endet der Befehl mit einem Exit-Code ungleich null, anstatt stillschweigend einen vollständigen Scan auszuführen. Wird ein Scan wiederverwendet, spiegelt --sbom weiterhin den aktuellen Workspace wider, nicht das frühere SBOM des wiederverwendeten Scans.

​
Abhängigkeitsinventar

Mit corgea deps erstellen Sie aus npm-, Python- und Java-Manifesten sowie Lockfiles ein Offline-Inventar der Abhängigkeiten. Der Befehl prüft Richtlinien zur Versionsfixierung, kann CI-Jobs anhand der Befunde fehlschlagen lassen und benötigt weder Anmeldung noch Netzwerkzugriff.
Gängige Befehle für das Abhängigkeitsinventar:
Verwenden Sie --format human, agent, json oder quiet, um die Terminalausgabe für scan, graph, explain, diff und policy init zu steuern. In erkannten Agent-Umgebungen verwendet corgea deps standardmäßig das kompakte agent-Format; übergeben Sie --format human, um die normale Terminalausgabe zu erzwingen. Für corgea deps scan verwenden Sie --out-format table, json oder sarif mit optionalem --out-file beim Exportieren eines Berichts. Kombinieren Sie --format und --out-format nicht im selben deps scan-Befehl. Um die Abhängigkeitsrichtlinie anzupassen, initialisieren Sie .corgea/deps.yml:
Die generierte Richtlinie legt fest, ob Lockfiles erforderlich sind, ob fehlende oder veraltete Lockfiles als Fehler gelten und ob direkte Abhängigkeiten mit Wildcards, latest oder Semver-Bereichen gemeldet werden. CI-Beispiele, Richtlinienkonfiguration und Hinweise zur Fehlerbehebung finden Sie unter Dependency Scanning.

​
Auf einen Scan warten

Um auf den neuesten laufenden Scan zu warten:
Oder geben Sie eine Scan-ID an, auf die gewartet werden soll:
corgea wait, corgea scan und corgea upload --wait beenden sich mit 1, wenn der Scan fehlschlägt, und geben den Grund sowie alle Scanner aus, die ein Problem gemeldet haben. Ein Scan, der ohne die Ergebnisse eines Scanners abschließt, beendet sich mit 0 und einer Warnung. Das Warten endet nach 10 Stunden, damit ein Scan ohne endgültigen Status einen CI-Job nicht unbegrenzt blockiert. Bei einem Timeout endet der Befehl mit dem Exit-Code 1. Der Scan selbst läuft in der Corgea Cloud weiter. Wenn Ihre Scans länger brauchen, setzen Sie CORGEA_SCAN_TIMEOUT_SECONDS auf die Anzahl der Sekunden, die gewartet werden soll:
Die CLI löst das Projekt normalerweise über die Remote-URL des aktuellen Repositorys auf. Mit --repo org/repo (oder einer Repository-URL) wählen Sie ein anderes Repository, mit --project-name einen exakten Corgea-Projektnamen. corgea wait SCAN_ID --project-id PROJECT_ID überspringt die Projektauflösung. corgea scan, corgea wait und corgea upload --wait enden alle mit einem Exit-Code ungleich null, wenn ein Scan fehlschlägt; dabei werden der Grund und alle Scanner genannt, bei denen Probleme aufgetreten sind. Ein Scan, der mit einem fehlenden Scanner abgeschlossen wird, endet stattdessen mit 0 und einer Warnung. Das Warten wird nach 10 Stunden abgebrochen; mit CORGEA_SCAN_TIMEOUT_SECONDS passen Sie dieses Budget an. Bei --fail oder --block-on wartet die CLI anschließend bis zu 35 Minuten auf die Auswertung der Sperrregeln; diesen Wert ändern Sie mit CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS.

​
Scans, Sicherheits-, SCA- oder Codequalitäts-Issues auflisten

Um alle Scans für ein aktuelles Verzeichnis aufzulisten (standardmäßig paginiert):
So listen Sie Issues eines bestimmten Scans auf:
Sie können auch die Paginierung steuern:
Hinweis: Die Option --json ist für Befehle wie list und inspect verfügbar, um Ergebnisse im JSON-Format auszugeben, was für Integrationen und Automatisierung nützlich ist.
Die Scan-Tabelle enthält die ersten acht Zeichen der Commit-SHA jedes Scans oder N/A, wenn keine SHA verfügbar ist. Die JSON-Ausgabe enthält den vollständigen Wert git_sha, den Wert worktree_dirty, der null sein kann, und alle von Corgea zurückgegebenen metadata des Scans. worktree_dirty ist true, wenn der Scan nicht committete lokale Änderungen enthielt, und kann bei Scans, die mit älteren CLI-Versionen erstellt wurden, null sein. Um SCA-Issues für ein Projekt oder einen Scan aufzulisten, verwenden Sie --sca-issues oder die Kurzform -c. Die Tabelle enthält die Klassifizierung jedes Issues, und die JSON-Ausgabe enthält das Feld classification, sofern vorhanden.
oder
Mit --code-quality (oder --quality/-q) listen Sie Codequalitäts-Issues auf. --scan-id begrenzt sie auf einen Scan.
Listenbefehle lösen das Projekt über die Remote-URL auf. Mit --repo org/repo (oder einer Repository-URL) wählen Sie ein anderes Repository, mit --project-name einen exakten Corgea-Projektnamen.

​
Scan oder Issue untersuchen

Um einen bestimmten Scan zu überprüfen:
Um Probleme mit detaillierter Ausgabe zu überprüfen:
Für Erläuterungen zu Fixes oder Diffs:

​
Integration mit Git-Hooks

Um Code Quality und Sicherheit zu gewährleisten, können Sie die Corgea CLI über Pre-Commit-Hooks in Ihren Git-Workflow integrieren. So scannen Sie Codeänderungen vor dem Commit oder Push. Richten Sie den Pre-Commit-Hook mit folgendem Befehl ein:
Beim Einrichten des Pre-Commit-Hooks werden Sie nach der gewünschten Scan-Konfiguration gefragt. Die Standardkonfiguration umfasst die Scan-Typen PII und Secrets sowie die Fehlerstufen CR, HI, ME und LO. Aktivieren Sie sie mit:
Um die Pre-Commit-Prüfung beim Commit zu umgehen, verwenden Sie den folgenden Befehl:

​
Umgebungsvariablen

​
Debug-Modus

Um Debug-Logs zu aktivieren, setzen Sie CORGEA_DEBUG=1, bevor Sie einen Befehl ausführen.
Im Debug-Modus enthält die Debug-Ausgabe bei fehlgeschlagenen Upload-Requests den HTTP-Status und den Response Body. Dies erleichtert die Fehlerdiagnose.

​
Zusätzliche Optionen

Für weitere Optionen und Befehle verwenden Sie:

​
Versionshinweise

Für vollständige Versionshinweise besuchen Sie bitte unsere GitHub Releases-Seite.