CodeMender find modes

CodeMender provides three distinct scanning modes through the cm find command. Each mode is designed for a specific stage of the software development lifecycle, balancing speed, scope, and depth.

Compare find modes

The following table compares the three cm find scanning modes:

Deep scan (default)

A deep scan is the default mode when you run cm find without providing additional scanning flags (the --deep flag is also supported for backward compatibility). It is an exhaustive scanning mode designed for comprehensive security audits. It audits source files across the target directory or repository concurrently using parallel workers (configured with --deep-workers, which defaults to 8 and supports a range of 1 to 16). As it discovers candidate findings, it validates and corroborates them against surrounding code context to filter out false positives before reporting results.

The following examples demonstrate how to run a deep scan across a repository:

# Run an exhaustive deep scan across the repository (default mode)
cm find .

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

Strengths

A deep scan runs with zero configuration and delivers high recall and comprehensive vulnerability discovery across large enterprise codebases. It outperforms single-session scans and uses automated verification to maintain high precision. It is also platform-independent and works across all languages supported by Gemini without requiring language-specific compilers, build setups, or grammar files. Finally, it optimizes resource usage by focusing analysis on production code and minimizing compute and token consumption on non-production files.

Trade-offs and limitations

Don't use a deep scan as a synchronous check that blocks pull requests. Deep scans perform a thorough, file-by-file analysis. As a result they require a longer runtime and higher token spend than quick or diff scans.

When to use

Use a deep scan in the following scenarios:

• Run scheduled security audits on a nightly or weekly schedule across all production repositories.
• Perform a full pre-release security audit before major version releases or production deployments.
• Generate audit evidence for SOC 2, ISO 27001, FedRAMP, or PCI-DSS compliance and certification reviews.
• Establish an initial security baseline when onboarding a new codebase to CodeMender.

Diff scan

A diff scan performs Git diff analysis for pull request workflows and CI/CD pipelines by inspecting modified and added files, focusing on the exact line ranges (diff hunks) that changed. In addition to inspecting changed lines, it performs impact analysis to discover untouched files in the repository that call, import, or depend on the modified functions and symbols. This helps ensure that changes altering contracts or function signatures in one file don't introduce vulnerabilities in dependent files.

During the scan, CodeMender automatically isolates pre-existing vulnerabilities in untouched code so that legacy issues don't cause the scan to fail or block the pull request. It then evaluates findings against your --fail-on policy and outputs results in table, JSON, or SARIF v2.1.0 format.

The following examples demonstrate how to run a diff scan against working copy changes, staged changes, or a target branch:

# 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

For end-to-end pipeline configurations, see Integrate with CI/CD.

Strengths

A diff scan is fast and deterministic, typically finishing in under 2 minutes to keep CI/CD pipeline runtimes short. Unlike diff scanners that only inspect changed lines, --diff inspects caller and callee relationships to catch cross-file security regressions and contract breaches. Because it suppresses findings in untouched code, the scan only blocks pull requests on issues introduced or affected by the changes, avoiding noisy reports and unnecessary build failures. A diff scan also emits SARIF v2.1.0 for direct integration into GitHub Code Scanning annotations and Cloud Build dashboards.

Trade-offs and limitations

A diff scan only analyzes code within the affected area of the pull request and doesn't find pre-existing vulnerabilities in untouched parts of the repository. It also requires a Git repository with access to the target base reference.

When to use

Use a diff scan in the following scenarios:

• Run automated checks on every pull request in CI/CD pipelines such as GitHub Actions, Cloud Build, GitLab CI, or Jenkins.
• Verify that local changes are clean in pre-commit or pre-push hooks before pushing code to the remote repository.
• Validate that merges between release branches don't introduce regressions.

Quick scan

A quick scan (cm find --quick) runs a single-session autonomous scan of the specified target directory instead of the default concurrent per-file deep scan. During the scan, CodeMender discovers source files, prioritizes them based on vulnerability patterns, performs an initial security analysis, and reports potential vulnerabilities grouped by severity and type.

The following examples demonstrate how to run a quick scan on a target directory:

# Run a single-session quick scan on a directory using the default model
cm find ./src --quick

# Run a quick scan with a specific Gemini model
cm find ./src --quick --model gemini-3.8-flash

Strengths

A quick scan balances speed and coverage with a moderate runtime and uses fewer tokens and less compute than a full deep scan, making it cost-effective for fast exploratory checks during everyday development.

Trade-offs and limitations

A quick scan has lower recall on large codebases and might not explore every file in large, multi-package enterprise repositories because it operates within a single session context. It also focuses primarily on local patterns within individual files, which limits cross-package analysis and might miss vulnerabilities spanning distant packages.

When to use

Use a quick scan in the following scenarios:

• Run a fast scan on your local machine to get quick feedback during local development.
• Inspect a newly cloned repository or a small project for a rapid initial assessment of its security posture.
• Inspect a specific subdirectory or module when doing a quick exploratory check.

Choose a find mode

Use the following reference table to select the right scanning mode for your workflow:

Command flag reference by mode

The following tables describe the command-line flags supported by each scanning mode.

Common flags (all modes)

The following flags apply to all cm find scanning modes:

Diff scan flags

The following flags configure cm find --diff scans:

Quick scan flags

The following flag configures cm find --quick scans: