CodeMender-Suchmodi

CodeMender bietet über den Befehl cm find drei verschiedene Scanmodi. Jeder Modus ist für eine bestimmte Phase des Softwareentwicklungszyklus konzipiert und bietet ein ausgewogenes Verhältnis zwischen Geschwindigkeit, Umfang und Tiefe.

Suchmodi vergleichen

In der folgenden Tabelle werden die drei cm find-Scanmodi verglichen:

Modus Befehl Zielbereich Typische Laufzeit Optimal für
Standardsuchlauf cm find PATH Angegebenes Verzeichnis Moderate Laufzeit Lokale Entwickler*innen finden, Schnellchecks, explorative Rezensionen
Unterschieds-Scan cm find PATH --diff[=REF] Geänderte Dateien und abhängige Dateien (z. B. Aufrufer und Aufgerufene) Schnelle Ausführung CI/CD-Pipelines für Pull-Anfragen (GitHub Actions, Cloud Build), Pre-Commit-Hooks
Detaillierter Scan cm find PATH --deep Gesamtes Repository Längere Laufzeit Geplante Audits, Release-Bereitschaft, Compliance-Zertifizierungen (SOC 2, ISO)

Standardscan (Standardeinstellung)

Ein Standardscan ist der Standardmodus, wenn Sie cm find ohne zusätzliche Scan-Flags ausführen. Es wird ein autonomer Scan des angegebenen Zielverzeichnisses in einer einzelnen Sitzung ausgeführt. Während des Scans erkennt CodeMender Quellcode-Dateien, priorisiert sie anhand von Mustern für Sicherheitslücken, führt eine erste Sicherheitsanalyse durch und meldet potenzielle Sicherheitslücken, gruppiert nach Schweregrad und Typ.

Die folgenden Beispiele zeigen, wie Sie einen Standardscan für ein Zielverzeichnis ausführen:

# Scan a directory using the default model
cm find ./src

# Scan with a specific Gemini model
cm find ./src --model gemini-3.8-flash

Vorteile

Ein Standard-Scan funktioniert ohne Konfiguration und ohne zusätzliche Flags oder Parameter. Es bietet ein ausgewogenes Verhältnis zwischen Geschwindigkeit und Abdeckung bei moderater Laufzeit und verwendet nur wenige Tokens und Rechenressourcen, was es für die tägliche Entwicklung kostengünstig macht.

Kompromisse und Einschränkungen

Ein Standardscan hat einen geringeren Recall bei großen Codebasen und untersucht möglicherweise nicht jede Datei in großen Enterprise-Repositories mit mehreren Paketen, da er in einem einzelnen Sitzungskontext ausgeführt wird. Außerdem konzentriert sich das Tool hauptsächlich auf lokale Muster in einzelnen Dateien, was die Analyse über mehrere Pakete hinweg einschränkt. Es werden möglicherweise Sicherheitslücken übersehen, die sich auf weit entfernte Pakete erstrecken.

Geeignet für

Verwenden Sie einen Standardscan in den folgenden Fällen:

  • Führen Sie einen Scan auf Ihrem lokalen Computer aus, bevor Sie Änderungen per Commit festschreiben, um während der lokalen Entwicklung schnelles Feedback zu erhalten.
  • Untersuchen Sie ein neu geklontes Repository oder ein kleines Projekt, um den Sicherheitsstatus zu ermitteln.
  • Untersuchen Sie ein bestimmtes Unterverzeichnis oder Modul, wenn Sie ein potenzielles Problem untersuchen.

Unterschieds-Scan

Bei einem Diff-Scan wird eine Git-Diff-Analyse für Pull-Anfrage-Workflows und CI/CD-Pipelines durchgeführt, indem geänderte und hinzugefügte Dateien untersucht werden. Dabei wird der Fokus auf die genauen Zeilenbereiche (Diff-Hunks) gelegt, die sich geändert haben. Neben der Überprüfung der geänderten Zeilen wird auch eine Folgenabschätzung durchgeführt, um unberührte Dateien im Repository zu finden, die die geänderten Funktionen und Symbole aufrufen, importieren oder von ihnen abhängen. So wird sichergestellt, dass Änderungen, die Verträge oder Funktionssignaturen in einer Datei ändern, keine Sicherheitslücken in abhängigen Dateien verursachen.

Während des Scans isoliert CodeMender automatisch bereits vorhandene Sicherheitslücken in unverändertem Code, damit Legacy-Probleme nicht dazu führen, dass der Scan fehlschlägt oder die Pull-Anfrage blockiert wird. Anschließend werden die Ergebnisse anhand Ihrer --fail-on-Richtlinie ausgewertet und in Tabellen-, JSON- oder SARIF v2.1.0-Format ausgegeben.

Die folgenden Beispiele zeigen, wie Sie einen Diff-Scan für Änderungen in der Arbeitskopie, bereitgestellte Änderungen oder einen Zielbranch ausführen:

# Scan working copy changes versus HEAD
cm find . --diff

# Scan staged changes only (pre-commit)
cm find . --diff --staged

# Scan a pull request branch against the main branch in CI/CD
cm find . --diff=origin/main --format=sarif --output=results.sarif \
    --fail-on=CRITICAL,HIGH

Informationen zu End-to-End-Pipeline-Konfigurationen finden Sie unter Mit CI/CD integrieren.

Vorteile

Ein Diff-Scan ist schnell und deterministisch und dauert in der Regel weniger als 2 Minuten, damit die Laufzeiten der CI/CD-Pipeline kurz bleiben. Im Gegensatz zu Diff-Scannern, die nur geänderte Zeilen untersuchen, werden mit --diff Beziehungen zwischen Aufrufer und Aufgerufenem untersucht, um dateiübergreifende Sicherheitsregressionen und Vertragsverletzungen zu erkennen. Da Ergebnisse in unverändertem Code unterdrückt werden, werden Pull-Requests nur bei Problemen blockiert, die durch die Änderungen eingeführt oder von ihnen betroffen sind. So werden unnötige Berichte und Build-Fehler vermieden. Bei einem Diff-Scan wird auch SARIF v2.1.0 für die direkte Einbindung in GitHub-Code-Scanning-Anmerkungen und Cloud Build-Dashboards ausgegeben.

Kompromisse und Einschränkungen

Bei einem Diff-Scan wird nur Code im betroffenen Bereich des Pull-Requests analysiert. Vorhandene Sicherheitslücken in unveränderten Teilen des Repositorys werden nicht gefunden. Außerdem ist ein Git-Repository mit Zugriff auf die Zielbasisreferenz erforderlich.

Geeignet für

Verwenden Sie einen Differenzscan in den folgenden Fällen:

  • Führen Sie automatisierte Prüfungen für jede Pull-Anfrage in CI/CD-Pipelines wie GitHub Actions, Cloud Build, GitLab CI oder Jenkins aus.
  • Prüfen Sie, ob lokale Änderungen in Pre-Commit- oder Pre-Push-Hooks sauber sind, bevor Sie Code in das Remote-Repository übertragen.
  • Prüfen Sie, ob durch Zusammenführungen zwischen Release-Branches Regressionen eingeführt werden.

Detaillierter Scan

Ein Deep Scan ist ein umfassender Scanmodus, der für umfassende, repositoryweite Sicherheitsüberprüfungen entwickelt wurde. Dabei werden Quellcode-Dateien im gesamten Repository gleichzeitig mit parallelen Worker-Prozessen geprüft, die mit --deep-workers konfiguriert werden. Der Standardwert ist 8 und es wird ein Bereich von 1 bis 16 unterstützt. Wenn potenzielle Ergebnisse gefunden werden, werden sie anhand des umgebenden Codekontexts validiert und bestätigt, um Falschmeldungen herauszufiltern, bevor Ergebnisse gemeldet werden.

Die folgenden Beispiele zeigen, wie Sie einen Deep Scan für ein Repository ausführen:

# Run an exhaustive deep scan across the entire repository
cm find . --deep

# Tune concurrency and use the cyber-specialized security model
cm find . --deep --deep-workers=8 --model=gemini-3.8-flash-cyber

Vorteile

Ein umfassender Scan bietet einen hohen Recall und eine umfassende Erkennung von Sicherheitslücken in großen Unternehmenscodebases. Er übertrifft Scans in einer einzelnen Sitzung und verwendet die automatisierte Überprüfung, um eine hohe Präzision zu gewährleisten. Es unterstützt mehrere Sprachen und ist plattformunabhängig. Es funktioniert in allen von Gemini unterstützten Sprachen, ohne dass sprachspezifische Compiler, Build-Setups oder Grammatikdateien erforderlich sind. Außerdem wird die Ressourcennutzung optimiert, indem die Analyse auf Produktionscode konzentriert und der Rechen- und Tokenverbrauch für Dateien, die nicht zur Produktion gehören, minimiert wird.

Kompromisse und Einschränkungen

Verwenden Sie keinen Deep Scan als synchronen Check, der Pull-Anfragen blockiert. Bei gründlichen Scans wird eine umfassende, repositoryweite Analyse durchgeführt. Daher sind längere Laufzeiten und höhere Tokenausgaben als bei Standard- oder Differenz-Scans erforderlich.

Geeignet für

Verwenden Sie einen Tiefenscan in den folgenden Fällen:

  • Führen Sie geplante Sicherheitsüberprüfungen in allen Produktionsrepositories täglich oder wöchentlich durch.
  • Führen Sie vor der Veröffentlichung von Hauptversionen oder Produktionsbereitstellungen eine vollständige Sicherheitsprüfung vor der Veröffentlichung durch.
  • Prüfnachweise für SOC 2-, ISO 27001-, FedRAMP- oder PCI-DSS-Compliance- und Zertifizierungsprüfungen generieren
  • Richten Sie eine erste Sicherheits-Baseline ein, wenn Sie eine neue Codebasis in CodeMender einbinden.

Suchmodus auswählen

Anhand der folgenden Referenztabelle können Sie den richtigen Scanmodus für Ihren Workflow auswählen:

Workflow oder Umgebung Anwendungsfall und Ziel Empfohlener Modus Beispielbefehl
Lokales Terminal Schnelle Suche oder Überprüfung eines bestimmten Moduls Standardsuchlauf cm find ./src
Lokales Terminal Vor-Commit-Prüfung für bereitgestellte Änderungen vor dem Pushing Unterschieds-Scan cm find . --diff --staged
CI/CD-Pipeline Automatisierte Pull-Anfrage-Gating für geänderten Code und Aufrufer Unterschieds-Scan cm find . --diff=origin/main --fail-on=CRITICAL,HIGH
Geplante Pipeline oder geplanter Audit Nächtliche Audits, Pre-Release-Gates, SOC 2-Compliance Detaillierter Scan cm find . --deep --deep-workers=8

Referenz zu Befehls-Flags nach Modus

In den folgenden Tabellen werden die Befehlszeilen-Flags beschrieben, die von den einzelnen Scanmodi unterstützt werden.

Häufig verwendete Flags (alle Modi)

Die folgenden Flags gelten für alle cm find-Scanmodi:

Flag Standardeinstellung Beschreibung
-c, --context TEXT "" Zusätzlicher Kontext, um den Scan-Agenten zu unterstützen, z. B. Architekturhinweise.
--model MODEL_NAME gemini-3.8-flash Gemini-Modell, das verwendet werden soll (gemini-3.8-flash, gemini-3.8-flash-cyber).
-y, --yes false Alle interaktiven Bestätigungsaufforderungen überspringen.
--unrestricted false Deaktivieren Sie die Dateisystem-Sandbox.

Flags für den Vergleichsscan

Mit den folgenden Flags werden cm find --diff-Scans konfiguriert:

Flag Standardeinstellung Beschreibung
--diff[=REF] Aus Aktivieren Sie den Differenzmodus für die Zielreferenz, z. B. origin/main oder HEAD~1. Ohne REF wird mit HEAD verglichen. Kann nicht mit --deep verwendet werden.
--staged Aus Unterschied auf den bereitgestellten Index beschränken (git diff --cached). Erfordert --diff.
--diff-depth DEPTH 1 Durchlauf-Tiefe für die Wirkungsanalyse (1 bis 3, Standard: 1 Hop).
--diff-workers COUNT 4 Anzahl der gleichzeitigen Worker für Pull-Anfrage-Prüfungsjobs (1 bis 16).
--diff-max-neighbors COUNT 10 Maximale Anzahl der abhängigen Dateien des Anrufers oder Angerufenen, die geprüft werden sollen.
--fail-on SEVERITIES CRITICAL,HIGH Kommagetrennte Schweregrade, die dazu führen, dass cm find mit dem Code 1 beendet wird.
--fail-on-truncation Aus Mit dem Code 1 beenden, wenn die Nachbarerkennung das Limit überschreitet.
--format FORMAT table Ausgabeformat: table, json oder sarif.
--output FILE Standardausgabe Bericht in eine Datei statt in die Standardausgabe schreiben.

Flags für detaillierte Scans

Mit den folgenden Flags werden cm find --deep-Scans konfiguriert:

Flag Standardeinstellung Beschreibung
--deep false Aktivieren Sie einen umfassenden Deep Scan für das gesamte Repository. Kann nicht mit --diff verwendet werden.
--deep-workers COUNT 8 Anzahl der gleichzeitigen Worker für den Tiefenscan (1 bis 16).