Cryptographic Discovery Methods Compared: Finding Every Algorithm in Your Enterprise

The Cryptographic Visibility Problem

Enterprise organizations typically have no comprehensive view of what cryptographic algorithms, protocols, and implementations exist across their infrastructure. Surveys consistently show that most CISOs cannot answer basic questions:

• How many instances of RSA-2048 key exchange exist in our environment?
• Which applications still use SHA-1 for integrity?
• Where is TLS 1.0/1.1 still active?
• What percentage of our key exchange is quantum-vulnerable?

Without answers to these questions, PQC migration planning is impossible, compliance reporting is guesswork, and cryptographic risk management is blind.

The challenge is that cryptography exists at every layer of the technology stack — in application code, compiled binaries, network protocols, cloud services, configuration files, and hardware devices. No single discovery method can find it all. This guide compares every major approach, identifies what each finds and misses, and explains how to combine them for complete cryptographic visibility.

Overview of Discovery Methods

Method	What It Analyzes	Coverage	Deployment Complexity	Runtime Impact
Static Code Analysis	Source code	Application-level crypto	Medium	None
Binary Scanning	Compiled binaries	Library-level crypto	Medium	None
Network Traffic Analysis	Live network packets	Protocol-level crypto	Medium	Minimal (passive)
Cloud API Enumeration	Cloud provider APIs	Cloud service crypto	Low	None
Configuration Scanning	Config files, registries	Declared crypto settings	Low	None
Runtime Tracing (eBPF)	Kernel/application syscalls	Actual crypto operations	High	Low-Medium

Method 1: Static Code Analysis

How It Works

Static code analysis examines source code without executing it, identifying:

• Calls to cryptographic APIs (e.g., OpenSSL_init_crypto(), Cipher.getInstance())
• Algorithm constants and parameters (e.g., "AES/CBC/PKCS5Padding", RSA_PKCS1_OAEP_PADDING)
• Key size specifications (e.g., KeyPairGenerator.initialize(2048))
• Certificate operations and TLS configuration
• Hardcoded keys and secrets (as a secondary finding)

Strengths

Strength	Description
Complete code coverage	Analyzes all code paths, including rarely executed ones
No runtime required	Works on code that isn’t deployed or running
Language-aware	Can understand API semantics specific to each language/framework
Developer-friendly	Results map directly to source code locations for remediation
CI/CD integration	Can run in build pipelines to catch new crypto usage
Historical analysis	Can analyze Git history to track crypto changes over time

Weaknesses

Weakness	Description
Source code required	Cannot analyze third-party libraries without source
Dynamic crypto invisible	Runtime-selected algorithms (config-driven) may be missed
Language coverage varies	Each language requires specific parsers and pattern libraries
False positives	Dead code, test code, and commented code generate noise
Indirect crypto calls	Wrapper libraries may obscure actual algorithm usage
Doesn’t see the full picture	A code call to OpenSSL doesn’t tell you what’s actually negotiated at runtime

What It Finds vs. Misses

Finds	Misses
Explicit algorithm selection in code	Algorithms selected by library defaults
Key size parameters	Actually negotiated cipher suites (runtime)
TLS configuration in application code	Infrastructure-level TLS (load balancer, CDN)
Custom crypto implementations	Third-party closed-source library crypto
API usage patterns	Configuration-file-driven algorithm selection
Deprecated algorithm usage	Crypto in compiled dependencies

Tools

• Semgrep: Custom rules for crypto API detection across languages
• CodeQL: Deep semantic analysis for crypto patterns
• Cryptosense Analyzer: Specialized crypto-focused static analysis
• SonarQube: General SAST with crypto-relevant rules
• Checkmarx/Fortify: Enterprise SAST with crypto detection capabilities

Best For

• Development teams wanting to catch crypto issues during code review
• Identifying where custom crypto implementations exist
• CI/CD pipeline integration for continuous monitoring
• Organizations with large proprietary codebases

Method 2: Binary Scanning

How It Works

Binary scanning examines compiled executables, libraries, and firmware images to identify cryptographic implementations:

• Symbol table analysis (identifying linked crypto libraries)
• Pattern matching for known crypto constants (S-boxes, round constants, magic numbers)
• Library version identification (e.g., OpenSSL 1.1.1 vs. 3.0 vs. 3.4)
• Algorithm identification from code patterns even in stripped binaries

Strengths

Strength	Description
No source needed	Works on commercial off-the-shelf (COTS) software
Finds embedded crypto	Detects crypto compiled into binaries, including statically linked
Library identification	Identifies exact versions of crypto libraries in use
Firmware analysis	Can analyze IoT device, medical device, and embedded firmware
Dependency depth	Finds crypto in transitive dependencies not visible in SBOMs
Detects known vulns	Links library versions to known CVEs

Weaknesses

Weakness	Description
Doesn’t show runtime behavior	A binary may contain multiple algorithms but only use one
Obfuscation defeats it	Code obfuscation or packing can hide crypto patterns
Architecture-specific	Analysis tools must support the target architecture (x86, ARM, MIPS)
Parameter ambiguity	May identify an algorithm without knowing the key size used
Container overhead	Scanning containers requires layer extraction
No protocol context	Finds crypto libraries but not how they’re used in protocols

What It Finds vs. Misses

Finds	Misses
Linked cryptographic libraries and versions	Runtime algorithm selection (configuration-driven)
Statically compiled crypto code	Dynamically loaded crypto providers
Known vulnerable library versions	Actual protocol behavior
Embedded crypto constants (S-boxes)	Key sizes used at runtime
Firmware cryptographic capabilities	Which capabilities are actually activated
Third-party/COTS crypto implementations	Protocol-level behavior (TLS version negotiated)

Tools

• Binary Analysis Platform (BAP): Academic-grade binary analysis
• Ghidra: NSA’s reverse engineering framework with crypto identification plugins
• binwalk: Firmware extraction and analysis
• EMBA: Embedded firmware analysis framework
• Tern: Container image analysis for library identification
• Syft/Grype: SBOM generation and vulnerability scanning from binaries

Best For

• Inventorying COTS/third-party software cryptography
• Medical device and IoT firmware assessment
• Container image crypto library inventory
• Identifying vulnerable OpenSSL/BoringSSL versions in production binaries

Method 3: Network Traffic Analysis

How It Works

Network traffic analysis passively monitors network communications to identify cryptographic protocols in use:

• TLS/SSL handshake analysis (ClientHello, ServerHello messages)
• Cipher suite negotiation extraction
• Certificate information from handshake messages
• Protocol version identification
• Key exchange algorithm detection
• VPN/IPsec IKE negotiation analysis

Strengths

Strength	Description
Shows actual behavior	Captures what’s really negotiated, not just what’s configured
No endpoint access needed	Works from a network tap or span port
Complete protocol visibility	Sees every TLS session crossing monitored network segments
Client + server view	Shows both sides of the negotiation
Historical analysis	Captured traffic can be analyzed retroactively
Finds shadow IT	Discovers crypto usage in unknown/unmanaged services

Weaknesses

Weakness	Description
Encrypted inner protocols invisible	Cannot see application-layer crypto inside TLS
Network position dependent	Only sees traffic crossing monitored network segments
Ephemeral connections missed	Short-lived or low-frequency connections may be missed during monitoring
Data at rest invisible	Cannot identify encryption for stored data
Internal traffic gaps	East-west traffic within a host/container is invisible
Volume challenges	High-throughput networks generate massive pcap data

What It Finds vs. Misses

Finds	Misses
TLS versions and cipher suites in use	Encryption at rest (database, disk, file)
Key exchange algorithms (RSA, ECDHE, ML-KEM)	Application-layer crypto inside TLS tunnels
Certificate algorithms and key sizes	Internal container-to-container crypto (same host)
VPN/IPsec negotiated algorithms	Cloud-internal encryption (provider-managed)
Actual negotiated protocols (not just configured)	Code-level crypto (hashing, signing within apps)
Unencrypted connections (identifying gaps)	Offline operations (batch encryption, key generation)

Tools

• Zeek (formerly Bro): Network analysis framework with SSL/TLS parsing
• JA3/JA4 fingerprinting: TLS client/server fingerprinting
• tshark/Wireshark: Protocol analysis with TLS dissection
• Arkime (formerly Moloch): Large-scale packet capture and analysis
• Network TAPs: Passive hardware for traffic mirroring
• Flow analysis tools: NetFlow/IPFIX-based protocol identification

Best For

• Discovering what TLS versions and cipher suites are actually negotiated in production
• Identifying quantum-vulnerable key exchange across all network connections
• Finding unencrypted data flows that should be encrypted
• Monitoring for cipher suite downgrade attacks or misconfigurations

Method 4: Cloud API Enumeration

How It Works

Cloud API enumeration uses cloud provider APIs to inventory cryptographic configurations across cloud services:

• KMS key inventory (algorithm, size, rotation status)
• TLS certificate configurations on load balancers and CDNs
• Encryption at rest settings (S3, RDS, EBS, etc.)
• VPN and Direct Connect encryption parameters
• IAM and authentication cryptographic settings
• Secrets manager configurations

Strengths

Strength	Description
Comprehensive cloud visibility	Covers all cloud-managed crypto in minutes
API-driven accuracy	Returns exact configurations, not inferred values
Low effort	Automated via cloud provider APIs — no agents needed
Multi-cloud support	AWS, Azure, GCP all provide comprehensive APIs
Real-time	Can be queried continuously for drift detection
Includes managed services	Covers database encryption, storage encryption, etc.

Weaknesses

Weakness	Description
Cloud-only	Doesn’t cover on-premises or hybrid infrastructure
Provider-managed crypto opaque	Some encryption is provider-managed and not visible
Application crypto invisible	Doesn’t see crypto within application code running on cloud
Permissions required	Needs broad read permissions across cloud accounts
Multi-account complexity	Enterprise environments may have hundreds of accounts
Default encryption ambiguity	”Encrypted by default” doesn’t specify algorithm/key management

What It Finds vs. Misses

Finds	Misses
KMS key algorithms and sizes	Application-level encryption within VMs/containers
Load balancer TLS policies	Custom crypto libraries in application code
Storage encryption settings (S3, EBS, RDS)	Provider-internal transport encryption
VPN encryption configurations	Crypto in third-party SaaS integrations
Certificate configurations (ACM, Key Vault)	Runtime algorithm negotiation details
Secrets management encryption	On-premises crypto connected to cloud

Tools

• AWS Config / Security Hub: AWS-native crypto configuration inventory
• Azure Policy / Defender for Cloud: Azure crypto compliance scanning
• GCP Security Command Center: GCP crypto posture assessment
• Prowler: Open-source cloud security assessment (multi-cloud)
• ScoutSuite: Multi-cloud security auditing
• Steampipe: SQL-based cloud infrastructure querying
• Cloud Custodian: Policy-as-code for cloud crypto compliance

Best For

• Rapid cloud cryptographic posture assessment
• Identifying unencrypted cloud resources (S3 buckets, EBS volumes)
• Verifying KMS key configuration compliance
• Continuous monitoring for cloud crypto drift

Method 5: Configuration Scanning

How It Works

Configuration scanning reads configuration files, registries, and settings to identify declared cryptographic parameters:

• Web server TLS configurations (nginx.conf, apache ssl.conf)
• Application server crypto settings (JVM security properties, .NET machine.config)
• Database encryption configurations (TDE settings, connection encryption)
• Operating system crypto policies (Windows registry, Linux crypto-policies)
• Network device configurations (router/switch/firewall crypto settings)

Strengths

Strength	Description
Direct and accurate	Configuration is the authoritative source for declared settings
Lightweight	Reading config files requires minimal resources
Infrastructure coverage	Catches network devices, servers, databases — not just applications
Declarative	Shows intended configuration, useful for compliance
Automation-friendly	Easily integrated with configuration management (Ansible, Puppet)
Change tracking	Config management tools track crypto configuration changes over time

Weaknesses

Weakness	Description
Configuration ≠ reality	Configured settings may not reflect actual runtime behavior
Scattered locations	Crypto config exists in dozens of different file formats and locations
Default values invisible	Many crypto settings use library defaults not explicitly in config
No coverage of custom code	Only finds framework/server-level crypto, not application logic
Dynamic environments	Containers and serverless may not have persistent config files
Incomplete picture	Doesn’t show what clients actually negotiate

What It Finds vs. Misses

Finds	Misses
Configured TLS versions and cipher suites	Actually negotiated parameters (depends on client)
Database encryption settings	Application-layer crypto within the database
OS crypto policy (min TLS version, disabled algos)	Crypto in user-space applications ignoring OS policy
Web server certificate paths and types	Certificate content details (must read cert file separately)
Network device IKE/IPsec configurations	Third-party SaaS crypto configurations
Declared key sizes and algorithms	Runtime key generation parameters

Tools

• OpenSCAP: Security configuration scanning against NIST guidelines
• InSpec/Cinc Auditor: Compliance-as-code for crypto configuration
• Ansible/Puppet auditing: Configuration drift detection
• CIS Benchmarks: Crypto-specific benchmark checks
• testssl.sh: TLS configuration testing (active probing)
• ssl-scan/sslscan: TLS configuration enumeration
• Custom scripts: Often required for application-specific configs

Best For

• Infrastructure-level crypto policy compliance
• Verifying TLS configurations across web server fleets
• Network device crypto configuration auditing
• Establishing baseline crypto configuration standards

Method 6: Runtime Tracing (eBPF)

How It Works

Runtime tracing uses kernel-level instrumentation (primarily eBPF on Linux) to observe actual cryptographic operations as they happen:

• Hooks into crypto library function calls (OpenSSL, GnuTLS, NSS)
• Captures algorithm parameters at function entry (key sizes, mode)
• Observes key generation, encryption, decryption, signing, verification
• Records actual session establishment parameters
• Traces crypto operations across all processes on a host

Strengths

Strength	Description
Ground truth	Shows exactly what crypto operations actually execute
No application changes	Observes from kernel level without modifying applications
Covers all processes	Any crypto operation on the host is visible
Runtime parameters	Captures actual key sizes, algorithms, and modes used
Dynamic crypto visible	Sees configuration-driven and negotiated algorithm selection
Container-aware	Works across all containers on a host

Weaknesses

Weakness	Description
Linux-only (eBPF)	eBPF is primarily a Linux technology; Windows alternatives are limited
Kernel version dependency	Requires modern kernels (5.x+) for full eBPF capability
Performance overhead	Tracing adds measurable (though typically small) overhead
Security sensitivity	Requires elevated privileges (CAP_BPF, CAP_PERFMON)
Operational complexity	Deploying and managing eBPF programs requires expertise
Only sees active operations	Dormant code paths or unused algorithms are invisible
Library-specific hooks	Must be adapted to each crypto library’s function signatures

What It Finds vs. Misses

Finds	Misses
Every actual crypto operation on the host	Crypto on network devices (routers, switches, firewalls)
Exact algorithms and key sizes used at runtime	Cloud-managed encryption operations
Dynamic/negotiated algorithm selection	Crypto on Windows hosts (limited eBPF support)
Container crypto operations	Code paths that don’t execute during observation period
Unusual or unexpected crypto usage	Hardware-accelerated crypto that bypasses library calls
Crypto library version from function signatures	Future planned crypto usage

Tools

• BCC (BPF Compiler Collection): Tools for crypto function tracing
• bpftrace: High-level tracing language for crypto observation
• Falco: Runtime security with crypto-relevant rules
• Tracee (Aqua Security): eBPF-based runtime detection
• Custom eBPF programs: Tailored crypto function tracing
• SystemTap: Alternative kernel tracing (broader OS support)

Example: eBPF Crypto Function Tracing

// eBPF program to trace OpenSSL cipher selection
SEC("uprobe/SSL_new")
int trace_ssl_new(struct pt_regs *ctx) {
    // Capture SSL context creation
    u64 pid = bpf_get_current_pid_tgid();
    // Log which process is creating TLS connections
    bpf_printk("SSL_new called by PID %d\n", pid >> 32);
    return 0;
}

SEC("uprobe/SSL_set_cipher_list")
int trace_cipher_list(struct pt_regs *ctx) {
    // Capture configured cipher suites
    char cipher_list[128];
    bpf_probe_read_user_str(cipher_list, sizeof(cipher_list), 
                           (void *)PT_REGS_PARM2(ctx));
    bpf_printk("Cipher list: %s\n", cipher_list);
    return 0;
}

Best For

• Discovering actual runtime crypto behavior in production systems
• Identifying crypto operations that configuration scanning misses
• Validating that configured crypto settings are actually applied
• Finding unexpected or unauthorized crypto usage

Comparison Matrix: All Methods

Criterion	Static Code	Binary Scan	Network Traffic	Cloud API	Config Scan	eBPF Runtime
Source code needed	Yes	No	No	No	No	No
Agent required	No	No	No (tap/span)	No	Varies	Yes (kernel)
Runtime impact	None	None	Minimal	None	None	Low-Medium
Finds at-rest crypto	✓	✓	✗	✓	✓	✓
Finds in-transit crypto	Partial	✗	✓	Partial	✓	✓
Finds code-level crypto	✓	✓	✗	✗	✗	✓
Finds infrastructure crypto	✗	✗	✓	✓	✓	Partial
Finds cloud crypto	✗	✗	✗	✓	Partial	✗
Shows actual negotiation	✗	✗	✓	✗	✗	✓
COTS/third-party coverage	✗	✓	✓	✓	Partial	✓
Medical device/IoT	✗	✓	✓	✗	Partial	✗
Air-gapped compatible	✓	✓	✓	✗	✓	✓

The Combined Approach: Complete Cryptographic Visibility

No single method provides complete visibility. A comprehensive CBOM requires combining multiple methods:

Recommended Combination by Environment Type

Cloud-Native Environment

Primary:   Cloud API Enumeration (cloud services) +
           Network Traffic Analysis (actual TLS behavior) +
           Static Code Analysis (application crypto)
Secondary: eBPF Runtime Tracing (container crypto validation)

Traditional Data Center

Primary:   Network Traffic Analysis (protocol visibility) +
           Configuration Scanning (infrastructure crypto) +
           Binary Scanning (application/COTS crypto)
Secondary: Static Code Analysis (in-house applications)

Hybrid Environment (Most Enterprises)

Primary:   All six methods in appropriate combinations
           Cloud API for cloud layer
           Network Traffic for all network segments
           Config Scanning for infrastructure
           Binary Scanning for COTS/third-party
           Static Code for proprietary applications
Secondary: eBPF Runtime for high-priority validation

Air-Gapped / Government

Primary:   Configuration Scanning (infrastructure) +
           Binary Scanning (firmware, COTS software) +
           Network Traffic Analysis (from approved captures)
Secondary: Static Code Analysis (mission applications)
Note:      Cloud API not applicable; eBPF requires approval

Coverage Gap Analysis

Even with all six methods combined, gaps may remain:

Gap	Why It Exists	Mitigation
Hardware crypto (HSM internals)	Opaque hardware operations	HSM vendor APIs and audit logs
SaaS provider crypto	Third-party infrastructure	Vendor assessment questionnaires
Transient connections	Very short-lived or infrequent	Extended monitoring periods
Custom hardware	Proprietary crypto in ASICs/FPGAs	Hardware vendor documentation
Legacy mainframe	Unique crypto facilities	Mainframe-specific discovery tools

How QCecuring CBOM Combines Discovery Methods

QCecuring CBOM integrates multiple discovery methods into a unified platform:

• Multi-method orchestration: Automatically deploys appropriate discovery methods based on target environment
• Result correlation: Combines findings from different methods to eliminate false positives and validate true positives
• Gap identification: Highlights areas where discovery coverage is incomplete
• Unified CBOM output: Produces a single CycloneDX CBOM regardless of how cryptographic instances were discovered
• Continuous monitoring: Combines network analysis + config scanning + cloud API for ongoing visibility
• Priority scoring: Weights findings by discovery confidence (runtime-confirmed > configured > code-present)

The result is comprehensive cryptographic visibility that no single discovery method can achieve alone — enabling confident PQC migration planning and compliance reporting.

Key Takeaways

• No single discovery method provides complete cryptographic visibility — each method has specific strengths and blind spots
• Network traffic analysis shows what’s actually negotiated — the ground truth for protocol-level crypto
• Static code analysis finds application-level crypto — essential for proprietary software but requires source access
• Binary scanning covers COTS and third-party software — critical for medical devices, IoT, and commercial products
• Cloud API enumeration provides instant cloud crypto visibility — automated and comprehensive for cloud-managed services
• Configuration scanning captures infrastructure-level crypto — authoritative for declared settings but may not reflect runtime reality
• eBPF runtime tracing provides ground truth for Linux systems — observes actual crypto operations but requires modern kernels and elevated access
• A combined approach is essential for complete CBOM — most enterprises need 3-4 methods minimum
• Discovery confidence varies by method — runtime-confirmed findings are highest confidence; code-present is lowest
• QCecuring CBOM integrates multiple discovery methods into a unified platform that correlates findings across sources
• Start with network traffic + cloud API + config scanning for fastest coverage, then add code/binary/runtime for depth
• Coverage gap analysis should be explicit — know what you cannot see and plan mitigations