CodeMender-Suchmodi

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

Scanmodi vergleichen

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

Modus Befehl Zielbereich Typische Laufzeit Optimal für
Standard scan cm find PATH Angegebenes Verzeichnis Moderate Laufzeit Erkennung lokaler Entwickler, schnelle Überprüfungen, explorative Überprüfungen
Diff-Scan cm find PATH --diff[=REF] Geänderte Dateien und abhängige Dateien (z. B. Aufrufer und Aufgerufene) Schnelle Laufzeit CI/CD-Pipelines für Pull-Anfragen (GitHub Actions, Cloud Build), Pre‑Commit-Hooks
Tiefenscan cm find PATH --deep Gesamtes Repository Längere Laufzeit Geplante Audits, Freigabebereitschaft, Compliance-Zertifizierungen (SOC 2, ISO)

Standardscan (Standardeinstellung)

Ein Standardscan ist der Standardmodus, wenn Sie cm find ausführen, ohne zusätzliche Scan-Flags anzugeben. Dabei wird ein autonomer Scan des angegebenen Zielverzeichnisses in einer einzelnen Sitzung ausgeführt. Während des Scans erkennt CodeMender Quelldateien, priorisiert sie anhand von Sicherheitslückenmustern, 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 Standardscan funktioniert ohne Konfiguration und ohne zusätzliche Flags oder Parameter. Er bietet ein ausgewogenes Verhältnis zwischen Geschwindigkeit und Abdeckung mit einer moderaten Laufzeit und verwendet nur wenige Tokens und Rechenressourcen, was ihn für die tägliche Entwicklung kostengünstig macht.

Kompromisse und Einschränkungen

Ein Standardscan hat eine geringere Recall-Rate 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 er sich hauptsächlich auf lokale Muster in einzelnen Dateien, was die Analyse über mehrere Pakete hinweg einschränkt und dazu führen kann, dass Sicherheitslücken in weit entfernten Paketen nicht erkannt werden.

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 committen, um während der lokalen Entwicklung schnelles Feedback zu erhalten.
  • Überprüfen Sie ein neu geklontes Repository oder ein kleines Projekt, um eine erste Einschätzung des Sicherheitsstatus zu erhalten.
  • Überprüfen Sie ein bestimmtes Unterverzeichnis oder Modul, wenn Sie ein potenzielles Problem untersuchen.

Diff-Scan

Ein Diff-Scan führt eine Git-Diff-Analyse für Pull-Anfragen-Workflows und CI/CD-Pipelines durch, indem er geänderte und hinzugefügte Dateien untersucht und sich dabei auf die genauen Zeilenbereiche (Diff-Hunks) konzentriert, die geändert wurden. Neben der Überprüfung geänderter Zeilen wird auch eine Auswirkungsanalyse 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 unberührtem Code, damit ältere Probleme nicht dazu führen, dass der Scan fehlschlägt oder die Pull-Anfrage blockiert wird. Anschließend werden die Ergebnisse mit Ihrer --fail-on-Richtlinie verglichen 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, für bereitgestellte Änderungen oder für einen Zielzweig 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-Pipelinekonfigurationen finden Sie unter Mit CI/CD einbinden.

Vorteile

Ein Diff-Scan ist schnell und deterministisch und dauert in der Regel weniger als 2 Minuten, um die Laufzeiten der CI/CD-Pipeline kurz zu halten. Im Gegensatz zu Diff-Scannern, die nur geänderte Zeilen untersuchen, werden mit --diff Aufrufer- und Aufgerufene-Beziehungen überprüft, um Sicherheitsregressionen und Vertragsverletzungen in mehreren Dateien zu erkennen. Da Ergebnisse in unberührtem Code unterdrückt werden, blockiert der Scan Pull-Anfragen nur bei Problemen, die durch die Änderungen eingeführt oder beeinflusst wurden. So werden unnötige Berichte und Build-Fehler vermieden. Ein Diff-Scan gibt auch SARIF v2.1.0 für die direkte Einbindung in GitHub Code Scanning-Anmerkungen und Cloud Build-Dashboards aus.

Kompromisse und Einschränkungen

Ein Diff-Scan analysiert nur Code im betroffenen Bereich der Pull-Anfrage und findet keine bereits vorhandenen Sicherheitslücken in unberührten Teilen des Repositorys. Außerdem ist ein Git-Repository mit Zugriff auf die Zielbasisreferenz erforderlich.

Geeignet für

Verwenden Sie einen Diff-Scan in den folgenden Fällen:

  • Führen Sie automatisierte Überprü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-Zweigen keine Regressionen eingeführt werden.

Tiefenscan

Ein Tiefenscan ist ein umfassender Scanmodus, der für umfassende, repositoryweite Sicherheitsaudits entwickelt wurde. Dabei werden Quelldateien im gesamten Repository gleichzeitig mit parallelen Workern geprüft (konfiguriert mit --deep-workers, der Standardwert ist 8 und der Bereich liegt zwischen 1 und 16). Wenn potenzielle Ergebnisse gefunden werden, werden sie anhand des umgebenden Codekontexts validiert und bestätigt, um False Positives herauszufiltern, bevor die Ergebnisse gemeldet werden.

Die folgenden Beispiele zeigen, wie Sie einen Tiefenscan 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 Tiefenscan bietet eine hohe Recall-Rate und eine umfassende Erkennung von Sicherheitslücken in großen Enterprise-Codebasen. Er übertrifft Scans in einer einzelnen Sitzung und verwendet die automatisierte Überprüfung, um eine hohe Genauigkeit zu gewährleisten. Er unterstützt mehrere Sprachen und ist plattformunabhängig. Er funktioniert mit 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 Nicht-Produktionsdateien minimiert wird.

Kompromisse und Einschränkungen

Verwenden Sie keinen Tiefenscan als synchrone Überprüfung, die Pull-Anfragen blockiert. Tiefenscans führen eine gründliche, repositoryweite Analyse durch. Daher ist eine längere Laufzeit und ein höherer Tokenverbrauch als bei Standard- oder Diff-Scans erforderlich.

Geeignet für

Verwenden Sie einen Tiefenscan in den folgenden Fällen:

  • Führen Sie geplante Sicherheitsaudits nach einem nächtlichen oder wöchentlichen Zeitplan für alle Produktions-Repositories aus.
  • Führen Sie vor der Veröffentlichung von Hauptversionen oder Produktionsbereitstellungen ein vollständiges Sicherheitsaudit vor der Veröffentlichung durch.
  • Erstellen Sie Auditnachweise für SOC 2-, ISO 27001-, FedRAMP- oder PCI-DSS-Compliance- und ‑Zertifizierungsüberprüfungen.
  • Richten Sie eine erste Sicherheits-Baseline ein, wenn Sie eine neue Codebasis in CodeMender einbinden.

Scanmodus auswählen

In der folgenden Referenz finden Sie Informationen zur Auswahl des richtigen Scanmodus für Ihren Workflow:

Workflow oder Umgebung Anwendungsfall und Ziel Empfohlener Modus Beispielbefehl
Lokales Terminal Schnelle Erkennung oder Vertrauensüberprüfung für ein bestimmtes Modul Standard scan cm find ./src
Lokales Terminal Pre‑Commit-Überprüfung für bereitgestellte Änderungen vor dem Übertragen Diff-Scan cm find . --diff --staged
CI/CD-Pipeline Automatisierte Pull-Anfragen-Gating für geänderten Code und Aufrufer Diff-Scan cm find . --diff=origin/main --fail-on=CRITICAL,HIGH
Geplante Pipeline oder Audit Nächtliche Audits, Vorabveröffentlichungs-Gates, SOC 2-Compliance Tiefenscan cm find . --deep --deep-workers=8

Referenz für Befehls-Flags nach Modus

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

Allgemeine Flags (alle Modi)

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

Flag Standardeinstellung Beschreibung
-c, --context TEXT "" Zusätzlicher Kontext zur Steuerung des Scan-Agents, z. B. Architekturnotizen.
--model MODEL_NAME gemini-3.8-flash Zu verwendendes Gemini-Modell (gemini-3.8-flash, gemini-3.8-flash-cyber).
-y, --yes false Alle interaktiven Bestätigungsaufforderungen überspringen.
--unrestricted false Sandbox für das Dateisystem deaktivieren.

Flags für Diff-Scans

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

Flag Standardeinstellung Beschreibung
--diff[=REF] Aus Diff-Modus für die Zielreferenz aktivieren, z. B. origin/main oder HEAD~1. Ohne REF, wird mit HEAD verglichen. Kann nicht mit --deep verwendet werden.
--staged Aus Diff-Bereich auf den bereitgestellten Index beschränken (git diff --cached). Erfordert --diff.
--diff-depth DEPTH 1 Traversal-Tiefe für die Auswirkungsanalyse (1 bis 3, Standard: 1-Hop).
--diff-workers COUNT 4 Anzahl der gleichzeitigen Worker für Pull-Anfragen-Auditjobs (1 bis 16).
--diff-max-neighbors COUNT 10 Maximale Anzahl der zu überprüfenden abhängigen Aufrufer- oder Aufgerufene-Dateien.
--fail-on SEVERITIES CRITICAL,HIGH Kommagetrennte Schweregrade, die dazu führen, dass cm find mit Code 1 beendet wird.
--fail-on-truncation Aus Mit dem Code 1 beenden, wenn die Erkennung von Nachbarn das Limit überschreitet.
--format FORMAT table Ausgabeformat: table, json oder sarif.
--output FILE Standardausgabe Bericht in eine Datei schreiben, anstatt ihn in der Standardausgabe auszugeben.

Flags für Tiefenscans

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

Flag Standardeinstellung Beschreibung
--deep false Umfassenden, repositoryweiten Tiefenscan aktivieren. Kann nicht mit --diff verwendet werden.
--deep-workers COUNT 8 Anzahl der gleichzeitigen Worker für den Tiefenscan (1 bis 16).