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.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-imagevollstä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,pipunduvauf 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.
Voraussetzungen
- Corgea-Konto: Ein aktives Corgea-Konto.
- Token zur Authentifizierung: Ein gültiges Corgea-API-Token oder JWT-Zugriffstoken.
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
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.
uv meldet, dass sein Tool-Verzeichnis nicht auf Ihrem PATH ist, führen Sie aus:
Mit pip installieren
Wenn Sieuv nicht verwenden, können Sie die Corgea-CLI mit dem Python-Paketinstaller pip installieren:
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ärdateicorgea in ein Verzeichnis in Ihrem PATH. Die folgenden latest/download-URLs verweisen stets auf das neueste Release.
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 Beispielhttps://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:Auf eine Single-Tenant-Instanz verweisen
Bei einer Single-Tenant-Instanz müssen Sie die CLI mit der Option--url auf Ihre Instanz verweisen:
Verwendung
Befehle und Optionen
Package Advisories prüfen
Mitcorgea 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.
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 Siecorgea 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 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.
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.
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: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:
--set-default hinzufügen. Damit wird der übergebene --agent-Wert dauerhaft übernommen:
CORGEA_DEFAULT_AGENT überschreibt den gespeicherten Standard. Das ist in CI-Umgebungen nützlich, in denen nicht in die Konfigurationsdatei geschrieben werden soll.
Scan-Bericht hochladen
Laden Sie einen Scan-Bericht über STDIN oder als Datei (JSON, SARIF, FPR oder Coverity XML) zu Corgea hoch:--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.
--wait wartet er auf den Abschluss und gibt die Ergebnisse aus:
Codebasis scannen
Um Ihr aktuelles Verzeichnis mit dem Standard-BLAST-Scanner zu scannen:--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:
--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):
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 15 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:
--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.
--target bestimmte Dateien oder Teilbereiche Ihres Projekts auswählen. Die Option akzeptiert kommagetrennte Dateipfade, Verzeichnispfade, Glob-Muster, Git-Selektoren oder stdin.
Beispiele:
--exclude ausschließen. Diese akzeptiert durch Kommas getrennte Glob-Muster und kann mit oder ohne --target verwendet werden.
--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.
--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.
--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.
has:key und key:value, beispielsweise has:pipeline_url oder environment:production.
- Blast Base AI Scan
- PolicyIQ Scan
- Malicious Code Detection Scan
- Secrets Detection Scan
- Erkennung von persönlich identifizierbaren Informationen (PII)
--scan-type können Sie den Scan auf einen oder mehrere Typen beschränken.
--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 inDockerfile- 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:
--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.
dockeroderpodmanmuss in IhremPATHverfügbar sein. Corgea verwendet das zuerst gefundene Programm; mitCORGEA_CONTAINER_ENGINElegen 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-imagewird nur vom BLAST-Scanner unterstützt.
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.
--sbom nach Abschluss eine CycloneDX-SBOM. Standardmäßig wird bom.json verwendet; optional kann ein Pfad angegeben werden:
--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.
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:
--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.
worktree_dirty=true gemeldet hat, übergeben Sie --ignore-dirty-worktree (CLI 1.11.1 oder höher). Die Option kann nur zusammen mit --skip-if-commit-scanned-recently verwendet werden. Ein neuer Scan meldet Corgea weiterhin den tatsächlichen Dirty-Status.
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 oder --include-image 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
Mitcorgea 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.
--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:
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: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:
--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 15 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):--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.
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.
--code-quality (oder --quality/-q) listen Sie Codequalitäts-Issues auf. --scan-id begrenzt sie auf einen Scan.
--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: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:Umgebungsvariablen
Debug-Modus
Um Debug-Logs zu aktivieren, setzen SieCORGEA_DEBUG=1, bevor Sie einen Befehl ausführen.