Overview

Obsidian finds the cryptography in your code, scores how ready it is for the post-quantum transition, and turns that evidence into reports, tickets, and answers for developers and AI agents. It runs as a self-hosted service: a control-plane API, a dashboard, and one or more scanner nodes.

The workflow

  1. Discover — scanner nodes (or the CLI) analyze repository source and emit normalized findings: algorithm, library, key size, file and line evidence, rule ID, severity, confidence, and a recommendation.
  2. Prioritize — findings roll up into per-repository posture and an exposure view, plus migration-readiness scoring so you can sequence the work.
  3. Prove — export a CycloneDX CBOM and score the inventory against policy frameworks.
  4. Hand off — open a GitHub issue with full evidence, or let a coding agent fetch context through the read-only MCP server.

Detection coverage

Native analysis uses tree-sitter parsers for Go, Python, JavaScript/TypeScript, Rust, Java, C#, Shell, C and C++. Solidity is analyzed line-based — no tree-sitter grammar is registered for it yet — and a regex fallback covers everything else.

In C and C++ the rules resolve OpenSSL, mbedTLS, PSA Crypto, the Linux kernel crypto API, Windows CNG with the legacy CryptoAPI, and libsecp256k1. Vendored code under vendor/, third_party/ and 3rdparty/ is scanned and tagged as third party, because code that ships in the artefact belongs in the inventory.

Built-in risk rules cover MD5, MD4, SHA-1, RIPEMD, weak ciphers, weak key sizes, insecure randomness, ECB mode, disabled certificate verification, insecure transport, deprecated Node crypto helpers, and embedded private-key or certificate material. A native module also detects operational key usage and custody references — AWS KMS, Azure Key Vault, PKCS#11 HSMs, and custody platforms (Fireblocks, Dfns, BitGo).

Optional, opt-in modules wrap host-installed tools: external/gosec, external/slither, and runtime/certificates.

Post-quantum readiness

Each repository gets a posture score, and migration candidates carry a deterministic readiness score from 0–100 and a band — ready, planned, needs_analysis, or blocked — with the drivers and blockers behind it. Scores are computed from findings, effort, and evidence; they are not AI estimates. See Read the dashboard.

Compliance frameworks

Obsidian evaluates the live inventory against built-in policy frameworks:

  • NIST FIPS 203 / 204 / 205 (ML-KEM, ML-DSA, SLH-DSA) — post-quantum readiness, scored today.
  • PCI DSS cryptography baseline — available as a selectable policy framework.

CBOM export (CycloneDX 1.7, with 1.6 compatibility) is covered in Export a CBOM. For trust boundaries and data handling, see Security and data handling.