Skip to main content

​
Why inventory cryptography

Most teams can’t say with confidence which algorithms, certificates, protocols, and keys their code uses. That inventory matters for several reasons:
  • Standards such as PCI-DSS, and frameworks published by NIST such as SP 800-175B, require an accurate cryptographic inventory.
  • Outdated or weak cryptographic implementations introduce exploitable vulnerabilities.
  • Advances in quantum computing will make many current encryption schemes obsolete.
  • Manual audits are slow and inconsistent, and they don’t scale to large or fast-changing codebases.
Crypto Finder automates cryptographic discovery, so teams can see what cryptography their code contains and keep it secure.

​
What Crypto Finder does

Crypto Finder runs OpenGrep by default and also supports Semgrep, which adds taint analysis. It fetches curated rules from the SCANOSS API and caches them locally. You can combine those remote rules with your own local rules, and configure Crypto Finder with CLI flags, environment variables, or config files. Results come out as interim JSON or as a CycloneDX 1.7 CBOM. Docker images let you run Crypto Finder in GitHub Actions, GitLab CI, Jenkins, and other CI/CD systems. Dependency scanning detects cryptographic usage in third-party dependencies and traces the call chains that reach it. It supports Go, Java through Maven or Gradle, Python, Rust, and Node through npm. The rules cache has a time-to-live (TTL). If the cache has expired and the API can’t be reached, Crypto Finder falls back to the stale cache automatically. Pass --strict to turn that fallback off. When only the ruleset has changed, the annotate command re-runs detection against a cached graph fragment. It skips the call graph rebuild, which is the expensive part of a scan.

​
How it works

  1. You point crypto-finder at a source code repository.
  2. Crypto Finder detects the programming languages in it and fetches the matching cryptographic detection rules.
  3. OpenGrep or Semgrep scans the code for cryptographic patterns using those rules.
  4. Crypto Finder writes the results to a CycloneDX CBOM or a JSON file.

​
Dead code filtering (C/C++)

In C and C++ codebases, Crypto Finder automatically excludes cryptographic findings inside statically dead preprocessor regions. These regions hold code that the compiler never includes in the final binary.

​
Supported preprocessor patterns

Crypto Finder finds dead regions by evaluating these common preprocessor directives:

​
Why dead code is filtered

Without this filtering, code inside #if 0 guards, or in platform-specific blocks that are never compiled, would produce false positives. Crypto Finder would report algorithms that the program never uses at runtime. Crypto Finder applies the filter whenever it detects C or C++ files in the target directory. It needs no configuration.

​
Use cases

​
Cryptography service

The SCANOSS Cryptography Service delivers remote cryptographic rulesets through the SCANOSS API.

​
Automatic rule fetching

During each scan, Crypto Finder detects the programming languages in the target project and fetches the matching detection rules from the SCANOSS API. It caches the rules locally for up to 7 days, the cache’s time-to-live, so scans depend less on the network and run faster.

​
Offline mode

When the SCANOSS API is unavailable, or the environment is air-gapped, Crypto Finder falls back to offline mode. It keeps scanning with the most recently cached rules.

​
Flow