Four evidence sources

cryptarium unifies four repository-resident evidence sources in one scan. Why this matters: Cryptographic choices are scattered across application code, dependency manifests, embedded certificates, and configuration. An inventory that covers only one of those surfaces leaves migration work blind.

Source	Supported today (v0.3)	Method
Source code	Go, Python, JS/TS, Java, C/C++ via YAML rule packs (stdlib crypto, OpenSSL, libsodium, mbedTLS, Crypto++, Botan, Web Crypto, `java.security`, …)	Tree-sitter parse + rule-pack matching
Dependencies	Go (`go.mod`) against a known-library catalog. Not yet: `requirements.txt`, `package-lock.json`, `pom.xml`, `Cargo.toml`	Manifest parsing; medium confidence until correlated with source
Certificates & keys	`.pem`, `.crt`, `.cer`, `.der`, `.key`, `.p12`, `.pfx`. Not yet: `.jks`, OpenSSH private keys	X.509 / PKCS#12: signature algorithm, public-key algorithm, key size, curve, validity
Configuration	nginx TLS cipher suites, SSH algorithm directives, JWT `alg` in auth-ish JSON/YAML. Not yet: IPsec/VPN	Config and suite-string parsing

Source scanning covers Python, JS/TS, Java, and C/C++ call sites even when their package manifests are not read. C++ files also run the C rule packs (OpenSSL, libsodium, mbedTLS).

Confidence ceilings

A library listed in go.mod is medium confidence at most. Correlation with a source finding is what earns high. See Confidence & unknown and Correlation.

What static detectors cannot see

Runtime algorithm selection, dynamically loaded providers, and what gets negotiated on the wire are out of scope. Report holes honestly when files fail to parse — silent omission from an inventory is the worst failure mode.