Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.scanoss.com/llms.txt

Use this file to discover all available pages before exploring further.

First Scan

Basic Scanning

Scan with remote rulesets (recommended — curated and maintained by SCANOSS):
crypto-finder scan /path/to/code
Scan with local rules only:
crypto-finder scan --no-remote-rules --rules-dir ./rules /path/to/code
Generate a CycloneDX Cryptography Bill of Materials (CBOM):
crypto-finder scan --format cyclonedx --output cbom.json /path/to/code

Common Use Cases

CI/CD Integration:
# Fail the build if findings are detected
crypto-finder scan --fail-on-findings /path/to/code
Custom Rule Combination:
# Combine remote rulesets with local custom rules
crypto-finder scan --rules-dir ./custom-rules /path/to/code
Force Fresh Ruleset Download:
# Bypass the cache and force a fresh download of remote rulesets
crypto-finder scan --no-cache /path/to/code
Post-Scan Format Conversion:
# Convert existing scan results to CycloneDX CBOM format
crypto-finder convert results.json --output cbom.json

# Or pipe directly from a scan
crypto-finder scan /path/to/code | crypto-finder convert --output cbom.json

Configuration

Crypto Finder can be configured via command-line flags, environment variables, or configuration files.
# Set an API key
crypto-finder configure --api-key YOUR_API_KEY

# Set a custom API URL
crypto-finder configure --api-url https://custom.scanoss.com
Environment Variables:
export SCANOSS_API_KEY=your-key
export SCANOSS_API_URL=https://custom.scanoss.com
Project-level configuration via scanoss.json:
{
  "settings": {
    "skip": {
      "patterns": {
        "scanning": ["node_modules/", "target/", "venv/"]
      }
    }
  }
}

Command Line Arguments

crypto-finder scan [flags] <target>
Common options:
  • --rules <file> - Custom rule file (repeatable)
  • --rules-dir <dir> - Rule directory (repeatable)
  • --no-remote-rules - Disable remote ruleset fetching
  • --no-cache - Force fresh download, bypass cache
  • --scanner <name> - Scanner to use: opengrep (default), semgrep
  • --format <format> - Output format: json (default), cyclonedx
  • --output <file> - Output file path (default: stdout)
  • --languages <langs> - Override language detection (comma-separated)
  • --fail-on-findings - Exit with error if findings detected
  • --timeout <duration> - Scan timeout (default: 10m)
  • --scan-dependencies - Scan third-party dependencies for cryptographic usage (requires deps image or local toolchains)
  • --export-callgraph - Export call graph to JSON for debugging
  • --java-jdk-major <major> - Java JDK major for Java dependency resolution/type enrichment: auto, 8, 11, 17, 21
  • --java-jdk-home <major=path> - Java JDK home mapping for explicit Java runtime selection (repeatable)
  • --interfile - Enable cross-file analysis (Semgrep Pro only)
  • --verbose, -v - Enable verbose logging
  • --help - Display help information
For a complete list of commands and options, run crypto-finder --help.

Advanced Topics

Features

  • Multi-Scanner Support — Supports OpenGrep (recommended) and Semgrep as configurable scan engines; Semgrep includes advanced taint analysis (inter-procedural data-flow tracking).
  • Dead Code Filtering (C/C++) — Automatically removes findings inside statically-dead preprocessor regions (e.g. #if 0, #ifdef, #ifndef) to eliminate false positives in C and C++ codebases. Applied automatically when C/C++ files are detected; no additional flags required.
  • Remote Rulesets — Automatically fetches and caches SCANOSS-maintained rulesets from the SCANOSS API; the local cache is used as a fallback if the remote is unavailable.
  • Flexible Configuration — Combine remote rulesets with local custom rules; configure via CLI flags, environment variables, or a scanoss.json configuration file.
  • Multiple Output Formats — Supports JSON and CycloneDX 1.6 CBOM output formats.
  • CI/CD Integration — Official Docker images available for use with GitHub Actions, GitLab CI, Jenkins, and other CI/CD platforms.
  • TTL-Based Caching — Remote rulesets are cached with a configurable time-to-live (TTL); expired cache entries are used as a fallback when the remote is unavailable (disable with --strict).