Rank 3 / Established band / Confidence MOD

QCecuring CBOM

QCecuring / PQC discovery capability record for edition 2026.7.

6.53Index score / 10[1]

Documented scanners for TLS, certificates, source code, binaries, cloud key stores, filesystems and SSH, with CycloneDX 1.6 CBOM export. S19

Established MOD

Seven criterion scores

C19

Discovery

How broadly and deeply does the product find cryptographic assets?

C54

Correctness

Is detection accuracy measured against named ground truth?

C66

Remediation loop

Can a finding move through ownership, action and verified closure?

C77

Reporting

Can technical and executive readers understand and reuse the result?

Evidence for every cell (JSON): URLs read, verbatim quotes and rationale · Post-review totals

Research record · reviewed 2026-09-26

Evidence behind all seven scores

Edition 2026.7 scores were fixed using the 27 September 2026 method. A 30 September check asked whether archived excerpts could be found in cited sources; a separate 1 October internal review assessed what those sources support. Neither later check changed a score, weight, rank or cohort. Original rationales, adjustments, citations and both separate checks remain visible. Read the method · Download the 1 October claim ledger.

Discovery

9 / 10

Weight 4/19 · 1.89 points of the overall score

Internal 1 October claim review: Partial or qualified support. Algorithm/key-size quote supports depth, but scored surface count and hybrid handling depend on other pages.

1 October source-text check: Archived excerpt reproduced. Checked 2026-10-01; text access does not independently validate the numeric score or complete rationale.

Historical 30 September source-access check

Archived excerpt reproduced in a cited source. Checked 2026-09-30; this older access state remains separate from the 1 October source-text and claim review.

Assessment: Docs scanner reference documents (a) TLS endpoints, (b) certificates/ADCS/Windows store, (c) source code in 6 languages, (d) binaries/linked libraries, (e/f) AWS ACM/KMS and Azure Key Vault, (g) agent filesystem keys/keystores, (i) SSH endpoints, with algorithm and key-size depth; ML-KEM/ML-DSA appear in the risk table, but TLS key_share/named-group (hybrid X25519MLKEM768) detection is not documented, so not 10.

Cited sources and original archived excerpt

URL availability labels below reflect the historical 30 September source-access screen.

Algorithm, key size, and quantum risk level

Original scoring anchor: between 8 (5-6 surfaces with algorithm depth) and 10 (>=7 surfaces, algorithm+parameter depth, PQC/hybrid detection)

Evidence artifact

6 / 10

Weight 3/19 · 0.95 points of the overall score

Internal 1 October claim review: Narrow feature documented. Public documentation explicitly specifies CycloneDX 1.6 JSON output; no integrity mechanism cited.

1 October source-text check: Archived excerpt reproduced. Checked 2026-10-01; text access does not independently validate the numeric score or complete rationale.

Historical 30 September source-access check

Archived excerpt reproduced in a cited source. Checked 2026-09-30; this older access state remains separate from the 1 October source-text and claim review.

Assessment: CycloneDX v1.6 CBOM export thoroughly documented (algorithmProperties incl. NIST quantum security level, certificateProperties, dependencies, BOM-Link). No signature or hash chain on the exported CBOM is documented (only the license file is Ed25519-signed), and no public sample found; github.com/qcecuring has no public repositories.

Cited sources and original archived excerpt

URL availability labels below reflect the historical 30 September source-access screen.

Exports your full cryptographic inventory as a CycloneDX v1.6 JSON document. The export includes: bomFormat: "CycloneDX" , specVersion: "1.6" Unique serial number (URN UUID)

Original scoring anchor: 6: standard-schema export documented, no integrity mechanism

Change detection

6 / 10

Weight 3/19 · 0.95 points of the overall score

Internal 1 October claim review: Narrow feature documented. Documented comparison lists improved/regressed/unchanged and violation deltas; no signed change history shown.

1 October source-text check: Archived excerpt reproduced. Checked 2026-10-01; text access does not independently validate the numeric score or complete rationale.

Historical 30 September source-access check

Archived excerpt reproduced in a cited source. Checked 2026-09-30; this older access state remains separate from the 1 October source-text and claim review.

Original assessment: Sensors run scans on hourly/6h/12h/daily/weekly schedules; compliance assessments report deltas vs the previous run; architecture lists 'Email notifications for policy violations and certificate expiry'. No tamper-evident history documented. Caveats: trend delta comes from on-demand 'Run Assessment', and email alerts are Standard/Enterprise only.

Final review: 7 → 6. The diff comes from a user-triggered compliance assessment, not from scan-to-scan drift on the scheduled scans. Anchor 6 is therefore met only loosely. One of the two 8-conditions (tamper-evident history) is wholly absent, and the alert is a single architecture-table row. That is not 'clearly between' two anchors, so the rubric's lower-anchor default applies. Row total falls 6.68 -> 6.53 (124/19).

Review evidence and archived ruling

/platform/sensors: 'Schedule | Scan frequency (hourly, 6h, 12h, daily, weekly)'. /platform/compliance: 'Click Run Assessment on any standard...' then 'Trend Comparison | Delta vs. the previous assessment for the same standard | Direction indicator: IMPROVED, REGRESSED, or UNCHANGED'. /architecture: one table row, 'Alerts | Email notifications for policy violations and certificate expiry'. No tamper-evident history, audit log, hash chain or signature was found in the 22 docs pages.

Read the review file
Cited sources and original archived excerpt

URL availability labels below reflect the historical 30 September source-access screen.

Delta vs. the previous assessment for the same standard Direction indicator: IMPROVED, REGRESSED, or UNCHANGED Per-category changes (violations added/resolved)

Original scoring anchor: between 6 (scheduled rescans with diff/drift reporting) and 8 (scheduled monitoring with drift alerts AND tamper-evident history)

Risk quantification

6 / 10

Weight 3/19 · 0.95 points of the overall score

Internal 1 October claim review: Narrow feature documented. Vendor documents risk categories with algorithm examples; no numerical model asserted.

1 October source-text check: Archived excerpt reproduced. Checked 2026-10-01; text access does not independently validate the numeric score or complete rationale.

Historical 30 September source-access check

Archived excerpt reproduced in a cited source. Checked 2026-09-30; this older access state remains separate from the 1 October source-text and claim review.

Assessment: Docs document 5-level categorical risk (CRITICAL..NONE) by algorithm plus per-standard rules with key-size constraints, deadlines and actions. A 6-factor weighted formula with HNDL/retention exists only in a vendor blog; it is not corroborated in the technical docs (exported properties list has no score fields), so it is not credited.

Cited sources and original archived excerpt

URL availability labels below reflect the historical 30 September source-access screen.

Every asset is classified automatically: Risk Level Meaning Examples CRITICAL Broken or deprecated MD5, SHA-1, DES, RC4, TLS 1.0/1.1 HIGH Quantum-vulnerable RSA, ECDSA, ECDH, DH, DSA

Original scoring anchor: 6: categorical risk levels from algorithm vulnerability plus some context

Correctness

4 / 10

Weight 2/19 · 0.42 points of the overall score

Internal 1 October claim review: Partial or qualified support. Parsing limitations describe potential misses, not a measured false-positive rate; score four remains a rubric judgment.

1 October source-text check: Archived excerpt reproduced. Checked 2026-10-01; text access does not independently validate the numeric score or complete rationale.

Historical 30 September source-access check

Archived excerpt reproduced in a cited source. Checked 2026-09-30; this older access state remains separate from the 1 October source-text and claim review.

Assessment: Parse limitations and partial/failed scan status with error lists are documented; no precision/recall, benchmark or ground truth found in the 22 docs pages or product page.

Cited sources and original archived excerpt

URL availability labels below reflect the historical 30 September source-access screen.

Encrypted PEM keys are detected but cannot be parsed without the passphrase (they still appear as assets with algorithm info) Keystores with individual entry passwords different from the store password may not fully parse

Original scoring anchor: 4: accuracy or false-positive handling described, no metric

Remediation loop

6 / 10

Weight 2/19 · 0.63 points of the overall score

Internal 1 October claim review: Narrow feature documented. JSON export and Action Required guidance satisfy final six; no named ticket integration inferred.

1 October source-text check: Archived excerpt reproduced. Checked 2026-10-01; text access does not independently validate the numeric score or complete rationale.

Historical 30 September source-access check

Archived excerpt reproduced in a cited source. Checked 2026-09-30; this older access state remains separate from the 1 October source-text and claim review.

Assessment: Per-violation required action and migration deadline plus 'Export the full assessment as JSON' = export plus guidance. No Jira/ServiceNow/ticketing integration documented in docs.qcecuring.com/cbom or on the integrations page; no automated remediation documented for CBOM.

Cited sources and original archived excerpt

URL availability labels below reflect the historical 30 September source-access screen.

Action Required remediation (e.g., “Migrate to ML-KEM”)

Original scoring anchor: 6: one-way ticket/export plus guidance

Reporting

7 / 10

Weight 2/19 · 0.74 points of the overall score

Internal 1 October claim review: Partial or qualified support. Framework families listed, but mapping output/accuracy not independently checked.

1 October source-text check: Archived excerpt reproduced. Checked 2026-10-01; text access does not independently validate the numeric score or complete rationale.

Historical 30 September source-access check

Archived excerpt reproduced in a cited source. Checked 2026-09-30; this older access state remains separate from the 1 October source-text and claim review.

Assessment: Compliance mapping to CNSA 2.0/NIST PQC/FIPS 140-3 with per-standard reports, CycloneDX/JSON export and REST API are documented; the executive artifact is a dashboard ('executive summary' cards), and the 'Reports' page has no docs entry, so short of 8. No public sample report.

Cited sources and original archived excerpt

URL availability labels below reflect the historical 30 September source-access screen.

CNSA 2.0 — NSA Commercial National Security Algorithm Suite NIST PQC — Post-Quantum Cryptography transition requirements FIPS 140-3 — Approved algorithms and minimum key sizes

Original scoring anchor: between 6 (dashboards plus exports) and 8 (executive and technical reports with documented compliance mapping)

Research scope, product-status record and unresolved evidence gaps

Documentation reviewed 2026-09-26: No rename, acquisition, discontinuation or dated major release found. A public technical docs portal for CBOM (docs.qcecuring.com/cbom, 22 pages: architecture, deployment, 11 scanner types, CycloneDX v1.6 import/export, compliance, API) is live; it was not read for 2026.5 (brief says 'carried_thin'). Docs pages carry no version or date, so when they appeared is not established.

Archived product-status source · Source check: HTTP 200. The archived summary has not been independently revalidated in full.

The large upward movement (+1.73 total) comes from reading the vendor's public technical docs portal docs.qcecuring.com/cbom (22 pages, raw text fetched 2026-09-26), which the 2026.5 index did not read (2026.6 brief: 'Not re-fetched; carried, provisional'). It is not a judgment that the product changed. Only docs-documented scanners were counted for C1: the product page (qcecuring.com/product/cbom) also claims HSMs (Thales Luna, Entrust nShield, CloudHSM), Kubernetes/containers, email (S/MIME, PGP) and network devices, but no scanner page exists for these, so they were not counted. The vendor blog at qcecuring.com/blog/quantum-risk-scoring-methodology publishes weights (AV 0.25, DS 0.20, RP 0.20, HE 0.15, SC 0.10, RC 0.10) and claims 'QCecuring CBOM integrates quantum risk scoring directly into the CBOM generation process'; the docs' exhaustive export-property list and asset detail panel show no numeric score, so C4 stays at 6 until the docs corroborate it. Nothing was run against a live instance; all scores rest on documentation. The product is self-hosted (Docker Compose + MongoDB + Java sensors) and requires a vendor license file, so claims cannot be independently exercised without a license. Quotes are verbatim from HTML-to-text extraction; table cells run together without separators, and whitespace may differ from the rendered page.

Original product evidence (JSON) · Final matrix and applied review changes · Edition identity and hashes