Every component.SBOMEvery cipher.CBOMEvery quantum risk.PQC

SBOMLens is a software composition analysis (SCA) and SBOM/CBOM management platform built by ChainLabs. It identifies open-source components from the manifests and lockfiles of 10 package ecosystems, matches them against NVD, OSV and GHSA with a CI gate that fails closed, checks licences, and exports the SBOM. From the same scan it builds a cryptographic bill of materials (CBOM) from source code in seven language families, configuration files and certificates, and grades every algorithm for post-quantum readiness against NIST FIPS 203/204/205. It is priced per organisation rather than per developer.

Yes. SBOMLens does software composition analysis: it reads the manifests and lockfiles of 10 package ecosystems, matches every component that has an exact version against NVD, OSV and GHSA (a component declared only as a version range is reported as not checked), checks licences against your policy, and exports the result as a CycloneDX or SPDX SBOM. Components are identified from what manifests and lockfiles declare; SBOMLens does not match code snippets, and binary analysis is in preview. On top of SCA it produces a CycloneDX CBOM from the same scan, graded for post-quantum risk, and writes Auto-VEX statements with their evidence.

An SBOM lists the software components an application is built from — libraries, versions, licences. A CBOM lists the cryptographic assets it relies on — algorithms, key lengths, protocol versions and certificates. You need the SBOM to answer “are we exposed to this CVE?” and the CBOM to answer “what breaks when RSA does?”. SBOMLens produces both.

SBOMLens generates both an SBOM (CycloneDX 1.6 or 1.5, or SPDX 2.3) and a CBOM (CycloneDX 1.6) from one CLI scan, and sbomctl scan --with-cbom puts both in a single CycloneDX 1.6 file. As of September 2026, the public product pages of the other major SCA vendors do not show a cryptographic-algorithm inventory with post-quantum grades; JFrog Xray can add CBOM data to its CycloneDX SBOM export, but it covers certificates and secrets, not algorithms or key sizes. The SBOMLens CBOM covers Go, Java/Kotlin, JavaScript/TypeScript, Python, Rust, C/C++/Objective-C and C#, TLS settings in nginx, Apache httpd, HAProxy, openssl.cnf and Spring configuration, and PEM certificates and keys.

Yes. sbomctl scan --with-cbom writes the software components and the cryptographic assets into one CycloneDX 1.6 JSON document, and SBOMLens tests its CycloneDX output against the official 1.6 schema. Because both lists come from the same scan and sit in the same file, they cannot describe different builds. The option works for source scans; it is not available with --upload or --binary.

Ten package ecosystems: npm, PyPI, Maven, NuGet, Go modules, Cargo, Composer, RubyGems, CocoaPods and SwiftPM. Gradle build files are not parsed; Java dependencies are read from a Maven pom.xml. When a Gradle build file is present, sbomctl ci names it and fails with exit code 6 unless run with --allow-unsupported. Binary analysis, in preview, takes a single file or a whole folder and reads Go binaries, JAR, WAR and EAR archives and Python wheels and eggs.

Yes, in preview. Binary analysis takes a single file or a whole folder. It identifies Go binaries from the build info in ELF, PE and Mach-O files, JAR, WAR and EAR archives from the Maven coordinates in pom.properties (including nested JARs), and Python packages from wheel, egg and dist-info metadata. Other ELF, PE and Mach-O files are matched by signature and marked low confidence. The result is an SBOM; binaries are not scanned for a CBOM.

Yes. The Enterprise plan includes an on-premise build that runs fully air-gapped, matching vulnerabilities against a seeded advisory snapshot that you refresh, so no outbound connection is needed. The same server runs on Microsoft Azure, AWS and KT ucloud for teams that need domestic data residency.

The build fails. sbomctl ci exits with code 4 when no advisory source (NVD, OSV or GHSA) answered, so a scan that could not be checked at all never passes as clean. If only some sources answered, the result is judged on the sources that did. On the server, an SBOM that no source could check is shown as Unverified. Other failures have their own codes: 2 for vulnerability policy, 3 for licence policy, 5 for a failed upload and 6 when a detected manifest cannot be parsed or no component was found.

Auto-VEX reads the dependency graph and marks a finding not_affected when the vulnerable component is used only as a development dependency or is already at or past the fixed version. Statements at or above a 0.7 confidence score are generated automatically with their justification and rationale; the rest go to a person for review. Findings a team rules out by hand can be suppressed with a documented reason and an expiry date.

VEX (Vulnerability Exploitability eXchange) is the standard way to state that a listed vulnerability does not affect your product. Writing VEX statements by hand is the slowest part of vulnerability management. Auto-VEX derives the statement from dependency-graph evidence and records the justification, confidence score and rationale behind each one; a statement a person wrote always overrides an automatic one. sbomctl vex auto --vex-format cyclonedx writes CycloneDX 1.6 VEX locally and adds an import check that suggests, but never applies, not_affected for a direct npm dependency no source file imports. sbomctl vex add --project saves a statement you wrote to the SBOMLens server.

Yes. sbomctl cbom policy checks the CBOM against the built-in NIST policy or your own YAML rules and fails the build on a violation, so a newly introduced weak algorithm is stopped in CI rather than found in an audit. The built-in policy denies weak algorithms and short keys and warns on RSA-2048; to fail on quantum-vulnerable algorithms, list them (RSA, ECDSA, ECDH, DH, DSA) under deny.algorithms in your YAML.

Any team that ships or procures software under a security obligation. The rules differ by sector: SBOMs for medical devices (US FDA Section 524B) and for products with digital elements (EU Cyber Resilience Act), a cryptographic inventory for US federal systems under Executive Order 14412, supply-chain evidence in financial services (DORA ICT third-party risk) and automotive (UN R155, ISO/SAE 21434), supplier risk management under NIS2, and Korea’s plan for public-sector SBOM submission. SBOMLens produces the inventory each of them starts from.

It produces the artifacts those rules start from. SBOMLens exports SBOMs as CycloneDX 1.6 or 1.5 (JSON or XML) or SPDX 2.3 (JSON or Tag-Value), CBOMs as CycloneDX 1.6, on their own or in the same file as the SBOM, VEX as CycloneDX 1.6 VEX with its justification, and CI findings as SARIF 2.1. That covers the machine-readable SBOM the EU Cyber Resilience Act expects in technical documentation from December 2027, the SBOM the FDA requires for cyber devices under Section 524B, and the cryptographic inventory Executive Order 14412 asks CISA and NIST to standardise as a CBOM. SBOMLens produces the inventory; it does not certify compliance.

Because the dates are set. FIPS 203, 204 and 205 finalised the replacement algorithms in August 2024. NIST’s draft IR 8547 deprecates 112-bit quantum-vulnerable algorithms such as RSA-2048 after 2030 and disallows all quantum-vulnerable public-key algorithms after 2035. Executive Order 14412 requires high-value and high-impact US federal systems to use post-quantum key establishment by 31 December 2030 and post-quantum digital signatures by 31 December 2031. Migration takes years and data captured today can be decrypted later, so the inventory has to exist before the plan can. SBOMLens classifies each cryptographic asset as safe, vulnerable or ready and names the replacement algorithm for each vulnerable one.

Per organisation, not per developer, at a fixed monthly price. Free is $0 for one project, five SBOMs per project and 100 API-key calls a day, and includes SBOM diff, the dependency graph, Auto-VEX and alerts. Standard is $199 per organisation per month for 10 projects and 10,000 API-key calls a day, and adds server-side CBOM, post-quantum grading, certificate expiry tracking and CBOM diff. Premium is $1,999 per organisation per month for 50 projects, unlimited API calls and dedicated support, with SLA terms agreed in the contract. Dashboard use does not count toward API limits. Beyond 50 applications, and for on-premise or air-gapped deployment, Enterprise is quoted, starting at $40 per application per month for applications 51 to 150.

In preview, yes. The SBOMLens admission webhook for AKS refuses a pod whose image has no SBOM uploaded with sbomctl upload --image-ref, whose image has an open critical vulnerability, or whose scan is still pending or incomplete. A partial scan is admitted with a warning. Each cluster uses its own organisation-scoped admission key. By default the webhook fails open (failurePolicy: Ignore), so if SBOMLens cannot be reached the deployment is allowed. The operator enables it on the SBOMLens server.

Yes. On Azure, SBOMLens runs on Container Apps with managed identities, PostgreSQL with Entra-only authentication, Redis and Blob Storage without access keys, and Key Vault references for the few secrets that remain, so no secret sits in configuration; the Bicep templates are in the repository. The same product runs on AWS, KT ucloud and air-gapped on-premise hardware. Every plan is available now by direct contract; the Azure Marketplace listing is planned for 2027 Q1, and the Azure DevOps task is in preview.

Two weeks. ChainLabs runs SBOMLens against your own environment and delivers the first results — SBOM, CBOM, PQC assessment and a vulnerability view — within that window, with a demo configured for your stack.