Roadmap
What is not in 5.1.0. "Planned" means designed but not written; "under consideration" may not be built. What is shipped is on the documentation page.
Languages
5.1.0 covers Java, Python, JavaScript/TypeScript and Go. Each additional language needs a rule set and a false-positive corpus before it is worth shipping.
| Language | Status | What it needs |
|---|---|---|
| C and C++OpenSSL, libsodium, mbedTLS, WolfSSL | Planned | OpenSSL's API is the largest single rule set of any library here, and the EVP interface selects algorithms by string at runtime much as the JCA does. |
| C#.NET cryptography, BouncyCastle.NET | Planned | The .NET class names are unambiguous, so this is mostly rule authoring rather than new detection technique. |
| RustRustCrypto, ring, rustls | Planned | Crate-level detection through Cargo.toml, then call sites. rustls already offers a hybrid key exchange, so completed work needs recognising too. |
| Kotlin and Scalavia the JCA | Planned | Both reach the same JCA the Java detector already understands; the work is the syntax around the call, not the catalogue. |
| Ruby, PHP, SwiftOpenSSL bindings, CryptoKit | Under consideration | Wanted, but each needs its own false-positive corpus before it is worth shipping. |
| Terraform and KubernetesKMS keys, cert-manager, service mesh | Under consideration | Infrastructure declares a great deal of cryptography. The difficulty is that the algorithm is usually named by a cloud key identifier rather than in the file. |
SARIF output
5.1.0 writes CycloneDX 1.7 only. SARIF
2.1.0 is next: it puts findings in an editor's Problems panel and in a pull
request's checks tab. The rule catalogue already carries what SARIF's
rules[] needs, so this is a serialiser rather than a redesign.
Signed CBOMs are also planned — signing each document with ML-DSA makes the artefact itself quantum-safe.
GitHub Action
A published Action in the GitHub Marketplace, so CI setup is three lines of YAML. It will also support diff scanning: scan only what a pull request touched and fail the build on new quantum-vulnerable cryptography, so a repository can freeze its exposure before finishing the migration.
Until then, a workflow step that runs the installer and
crypto-view . --fail-on high does the same job. The installer
publishes a SHA-256, so the step can be pinned.
Analysis
| Capability | Status | Why it matters |
|---|---|---|
| Crypto-agility grading | Planned | Separate from the vulnerability count: is the algorithm hard-coded at the call site, or read from configuration? A codebase that reads its algorithm from config migrates in a day; one with four hundred hard-coded literals does not. |
| Scan comparison | Planned | A view of what changed between two commits — added, removed, fixed. The history already stores everything this needs. |
| Data-lifetime input | Under consideration | Ask how long the data must stay confidential, then rank key-establishment findings against that date rather than a generic one. |
| Read-only API | Under consideration | Query the history and fetch a CBOM by URL, so an asset inventory can consume it without a person in the loop. |
Requests: contact@qcomply.tech.