Audits the OpenSSL, ERTS, Elixir, exqlite, and SQLite versions
baked into Mob's pre-built OTP tarballs and into the project's
deps/exqlite/c_src/sqlite3.c.
Why this layer exists
Generic dependency scanners (mix_audit, osv-scanner,
Aqua/Snyk/Trivy) all assume dynamic linking — they look at lockfiles
and don't see versions baked into static archives. Mob ships
libcrypto.a (OpenSSL), libbeam.a (ERTS), the entire SQLite
amalgamation, and a frozen Elixir stdlib inside the OTP tarball
that gets copied into every app binary. Nothing in your mix.lock
reveals these versions.
This layer looks inside.
What it does
Fingerprint — locate cached tarballs at
~/.mob/cache/otp-*-{hash}/, extract real versions of OpenSSL, ERTS, Elixir, and the bundled exqlite BEAMs.Drift detection — compare fingerprints against the
BundledVersionsmanifest. Any mismatch is a:highfinding — it means the manifest is lying about what shipped, which is the exact failure mode the manifest exists to prevent.SQLite fingerprint — read
deps/exqlite/c_src/sqlite3.cfrom the scanned project and extractSQLITE_VERSION. SQLite isn't in the OTP tarball; it's compiled per-app via exqlite.Version transparency — emit informational notes documenting every detected version with a pointer to its upstream advisory page. We don't pretend to do live CVE lookups for OpenSSL/SQLite — there's no reliable machine-readable feed at this writing (OpenSSL retired its JSON feed; OSV.dev doesn't cover native libs). The notes give the user everything they need to verify manually.
Hex-ecosystem CVEs (including exqlite the BEAM package) are handled
by hex_deps, not duplicated here.