Enterprise SBOM integration priorities

Implementation update, 2026-10-13: the documented contracts now have experimental Sonatype, Artifactory, and Anchore adapters. Their guides record local protocol testing and remaining commercial tenant/fidelity verification. The research below records the original prioritization, not a claim of live validation.

Research date: 2026-10-10. Tracking: census-6dt.7; Dependency-Track compatibility spike: census-6dt.5.

Crypto Census should finish the selected Dependency-Track compatibility investigation, then prioritize Sonatype SBOM Manager and JFrog Artifactory/Xray for enterprise delivery. Investigate Cybeats SBOM Studio alongside them when the customer needs searchable cryptographic inventory. Publish clear GitHub and GitLab CI artifact recipes immediately. Treat Black Duck, Anchore, and Snyk as customer-driven integrations until their handling of our evidence is demonstrated.

This is a recommended integration order, not a market-share ranking. Named customer cases and company filings establish enterprise use; they do not establish how often a prospective Census customer uses a particular SBOM feature. No comparable, independently measured installed-base dataset was found in this research. Product-family adoption is explicitly separated from adoption of an individual module.

The central compatibility question is whether a destination preserves and exposes our externally generated CBOM, including cryptographic-asset, cryptoProperties, occurrences, Census risk properties, health counters, and provenance. CycloneDX import, SPDX import, a native cryptography scanner, and CBOM export each describe different capabilities. None alone proves that external Census evidence survives import.

Eight priority integration targets

Target	Enterprise-use evidence	What it actually ingests; Census fit	Recommendation
Dependency-Track	Established OWASP project with an API-first portfolio model; its documentation describes organizational use, but this research does not establish market share. Project documentation	CycloneDX BOM ingestion is a core workflow. Preliminary inspection of the pinned 5.2.0 component converter finds no cryptoProperties mapping. This is a source-level fidelity concern, not yet a completed live round-trip result. 5.2.0 converter	First, already selected. Gate the adapter on a real import/export test and an explicit fidelity policy.
Sonatype SBOM Manager / Lifecycle	Sonatype documents Lifecycle use at Software AG and ABN AMRO. These cases demonstrate the ecosystem, not SBOM Manager adoption specifically. Customer cases	SBOM Manager has an external BOM import API, asynchronous status, and original-BOM retrieval. Lifecycle's package analysis is a different function. SBOM Manager API, Lifecycle CycloneDX input	Second discovery spike. Strongest documented original-evidence path among the SCA incumbents reviewed. Verify byte identity and searchable crypto fields separately.
JFrog Artifactory / Xray	JFrog's 2025 Form 10-K reports about 6,600 paying organizations and approximately 83% of the Fortune 100. This is JFrog Platform adoption, not Xray SBOM-import adoption. 2025 filing	Xray imports CycloneDX JSON/XML and SPDX 2.x JSON uploaded to an indexed generic repository. Artifact storage is distinct from Xray's derived vulnerability inventory. SBOM import	Third adapter candidate. Promising low-friction evidence storage for existing Artifactory customers; do not claim Xray crypto analysis without a capability test.
Cybeats SBOM Studio	A named 2025 Schneider Electric renewal covers SBOM Studio and SBOM Consumer. This supports a real enterprise foothold, not prevalence comparable to the larger platforms. Renewal announcement	Explicitly advertises a dedicated cryptographic-asset catalog, CycloneDX 1.2–1.7 and SPDX 2.2–3.0.1 ingestion. Also advertises data autocorrection, which must be checked against our immutable-evidence requirement. Product and CBOM FAQ	Parallel specialist discovery. Strong CBOM-fit claim; require a tenant, API contract, and exact external-CBOM round trip before committing an adapter.
Black Duck SCA	FPT reports using Black Duck SCA across software-project testing. FPT case	Imports SBOM files and maps scans to project versions. Its documented import field mapping concerns component identification and relationships; that does not establish complete CBOM retention. Import workflow, SBOM field support	Customer-driven next wave. Obtain a supported version's API specification and fidelity result before implementation.
Anchore Enterprise	Anchore publishes NVIDIA container-security adoption evidence. This does not prove NVIDIA uses external CBOM import. NVIDIA case	External CycloneDX, SPDX, and Syft documents become SBOM assets attached to app versions. Validation is asynchronous; package extraction follows parsing. Cryptographic fields and original-byte retrieval remain unverified. SBOM assets	Customer-driven next wave, especially container-centric organizations. Keep Enterprise separate from Syft generation and Grype vulnerability scanning.
Snyk	Salesforce publicly describes its use of Snyk for open-source security. Salesforce case	Enterprise sbom test accepts CycloneDX JSON 1.4–1.6 and SPDX JSON 2.3, requires package URLs, and returns vulnerability findings. This is package testing, not documented persistent external CBOM inventory. SBOM test	Discovery priority, low immediate CBOM-adapter priority. Do not invent package URLs for algorithms to satisfy package-oriented ingestion.
GitHub / GitLab CI platforms	Named enterprise platform cases include Mercedes-Benz on GitHub and UBS on GitLab; these establish platform adoption, not CBOM support. GitHub case, GitLab announcement	GitHub dependency submission accepts package-graph snapshots. GitLab consumes CycloneDX report artifacts for its dependency features. Neither contract establishes complete cryptographic inventory. GitHub API, GitLab dependency list	CI recipes now. Retain the exact CBOM and receipt as build artifacts. Package security integration, where useful, remains a separate artifact and feature.

Transport and operations implications

These are planning inputs, not implemented adapter contracts. “Unknown” means the reviewed public material did not establish the detail; it does not mean the vendor lacks the capability. Effort is a relative engineering estimate, not a delivery date.

Destination	Deployment and authentication	Mapping and completion	Estimated effort / unresolved gate
Dependency-Track 5.2.0	Self-hosted application; X-Api-Key.	POST multipart or PUT encoded BOM at /api/v1/bom; explicit project UUID preferred; upload token is not ingestion proof.	Medium transport, high fidelity risk. Confirm the 5.2 workflow completion contract and raw-BOM retrieval/retention. Pinned API source
Sonatype SBOM Manager	Cloud and self-hosted; recommended user-token/token-password authentication.	Precreated application internal ID and explicit version; multipart /api/v2/sbom/import; poll returned statusUrl; original download path returned on completion.	Medium. Keep ignoreValidationError=false; never silently import only selected components. Test original-byte retrieval without conversion. API
JFrog	SaaS and self-managed are documented in its filing; scoped token for artifact upload.	PUT an explicit repository/path; map application/module/version/run in immutable artifact path or controlled metadata. Storage success and Xray scan completion are separate.	Low–medium for original storage; medium for scan-status correlation. Verify downloaded SHA-256 and overwrite protections. Upload API, deployment models
Cybeats	SaaS business model is documented; confirm customer's private deployment and auth requirements.	Product/release model is documented, but upload authentication, version mapping, completion receipt, and raw download need a supported API specification.	Unknown until vendor contract and sandbox access. TEA exchange is described as proof of concept, so do not base production delivery on it yet. Company information, product FAQ
Black Duck	Hosted and on-premise documentation exists; validate service-token flow against the selected version.	Scan-to-project-version mapping is explicit. Exact automated SBOM-upload and completion endpoints were not verified here.	Medium–high discovery. Require async failure behavior, unknown-component behavior, crypto-field retention, and original retrieval. Documentation
Anchore Enterprise	Self-hosted deployment options appear in Enterprise documentation; service API-key permissions need version-specific verification.	App, version, asset name/type; anchorectl app version asset add sbom; inspect job failures at /apps/{app_id}/jobs/{job_id}.	Medium. Verify raw REST upload/auth, package extraction versus crypto retention, and original download. Asset workflow
Snyk	Hosted service with enterprise entitlement for SBOM testing; use the supported CLI/service authentication.	Organization-scoped testing; package identifiers required. CLI results are test outcomes, not an inventory import receipt.	Low for invoking a package test; unsuitable as the current CBOM-delivery contract. Command reference
GitHub / GitLab	Cloud or enterprise deployments; confirm the customer's edition and version.	GitHub snapshot API uses repository/commit/ref/run identifiers and bearer auth with contents-write permission. GitLab report artifacts map naturally to the project pipeline.	Low for CI artifact examples. Separate artifact upload success from security-report ingestion. GitHub API, GitLab report artifacts

Candidates deliberately deferred

• Mend: important enterprise ecosystem, with named Yahoo and Microsoft cases, but its import documentation explicitly excludes CBOM, CDXA, and AI/ML despite CycloneDX 1.6 support. Do not build a Census CBOM adapter under the current contract. Enterprise cases, explicit limitation.
• FOSSA: has genuine external SBOM import, including a signed-upload workflow. That is stronger evidence than export alone, but no complete Census CBOM retention contract was established. Revisit with customer demand. Import API.
• Finite State: a credible product-security option with external SBOM ingestion and native binary cryptography discovery. The latter does not prove preservation of an externally generated Census CBOM. More relevant to embedded/product-security customers than the initial Maven workflow; request a current import schema before promoting it. Platform datasheet.
• PQCA CBOMkit: promising reference compatibility target. It explicitly imports external CBOMs through POST /api/v1/cbom/{projectIdentifier} and exposes stored CBOM queries. Treat it as a cryptographic inventory interoperability target; this research does not establish broad enterprise deployment. IBM origins should not obscure its current PQCA context. Architecture.
• IBM Guardium Quantum Safe: elevate to specialist discovery alongside Cybeats when enterprise cryptographic posture management is the requirement. IBM documents CBOM JSON ingestion through built-in plugins using SFTP, REST, or object storage; this is stronger evidence than native discovery alone. Exact acceptance of Census fields, retrieval, service authentication, and asynchronous completion still need verification against the customer's product/version. Guardium Cryptography Manager's separate Quantum Safe Explorer import contract requires a gitUrl metadata property; do not generalize that proprietary producer contract to arbitrary CBOMs. IBM-wide adoption is not evidence of adoption of either product. Quantum Safe ingestion, Cryptography Manager import profiles.

Release gate for each adapter

Use one versioned capability fixture containing real Census output plus controlled crypto assets, multiple occurrences, custom risk properties, nonzero health counters, and provenance. Also exercise an actual Maven-produced merged CBOM. Keep the source SHA-256 and never alter the evidence to make a receiver accept it.

1. Submit exact bytes to a dedicated project/version; record the destination version, auth permission scope, request identity, HTTP result, and asynchronous job identifier.
2. Confirm durable ingestion through the vendor's supported completion API. Exercise rejected format, wrong project, insufficient permissions, rate limiting, failed background processing, timeout, and duplicate submission. A 2xx or an inactive token alone is insufficient.
3. Retrieve the original and compare SHA-256. Separately export/query the derived inventory and compare component type, cryptoProperties, occurrence locations, Census risk properties, health, and provenance. Record retained, normalized, dropped, rejected, and unqueryable fields individually.
4. Test retrieval after restart and document retention, deletion, project-version overwrite, permissions, private CA/proxy support, and artifact limits. Do not claim exactly-once delivery without a receiver contract proving it.
5. Publish two independent capabilities: original evidence retained and cryptographic inventory preserved/queryable. A destination may support either or both. If its derived inventory loses information, any supported integration must make that loss explicit and preserve a separately retrievable original; that policy requires a deliberate product decision.

For Dependency-Track specifically, Census custom properties may retain primitive, mode, padding, or key-size information even if standard cryptoProperties fields disappear. Report standard-field loss, actual semantic loss, and queryability separately; duplicated custom properties must not be mistaken for native CBOM support.

The current research is documentation and source review. No commercial tenant was contacted or written to, and no completed live vendor round trip is claimed. Dependency-Track's isolated local round trip is the next empirical step. Subsequent adapter work should follow customer demand and verified fidelity, rather than expanding every vendor named here.

Combining runtime cryptography evidence with a software SBOM

Recommendation: reuse the customer's existing software SBOM generator and add an explicit enrichment step. The generator owns package inventory, versions, licenses, and the software dependency graph. Census owns cryptographic observations, occurrence evidence, assessment policy, and collection health. The enrichment step consumes both artifacts from the same build, produces a derived view, and retains both originals and their hashes. This is a proposed architecture: Census does not currently implement this cross-BOM join or package ownership resolution.

CycloneDX can represent software and cryptographic assets together. Its cryptographic model includes algorithms, protocols, keys, and related material. That gives us a standard representation for observed cryptography without taking responsibility for enumerating every software package. CycloneDX CBOM capability.

Representation	Suitable when	Required behavior
One enriched CycloneDX BOM	A destination expects one authoritative inventory per application/version and supports the required crypto fields.	Copy the software inventory and graph, add Census crypto assets and supported relationships, preserve provenance, and emit a new derived artifact. Validate against an explicit compatible CycloneDX schema version. Keep both originals; the derived BOM has its own identity and hash.
Separate SBOM and CBOM, connected with BOM-Link	Independent producers, update schedules, access controls, or preservation of signed originals matter, and the consumer can resolve the links.	Keep each BOM immutable; use stable serial number/version identities and supported cross-document references. Retain a manifest locating and hashing both files. Test consumer resolution and authorization explicitly.

BOM-Link identifies a whole BOM or a specific object using urn:cdx:<uuid>/<version>#<bom-ref>; the fragment is optional. It is an identifier, not an automatic network retrieval protocol. A storage/resolution contract is still required. If an existing SBOM lacks a serial number, do not silently modify a signed original to invent one: produce a clearly derived document or use a manifest until the producer supplies a stable identity. BOM-Link specification.

The join must be evidence-based:

• Anchor the build first. Require matching application/module, release/build identity, source revision where available, and input artifact hashes. PURL plus exact version/qualifiers identifies a package candidate; a digest of the actual runtime artifact provides stronger confirmation of the bytes observed. A build ID alone does not prove that the running class came from a particular dependency. CycloneDX supports package identifiers, artifact hashes, and identity evidence. Software component identity.
• Resolve the observing caller separately from the provider. A callsite may establish that application code requested RSA; it does not by itself prove which dependency or native provider implemented RSA. Future class-to-artifact attribution must handle shaded JARs, relocated packages, duplicate classes, JDK modules, and native providers. Keep ambiguous ownership unresolved and retain the occurrence; do not guess from class/package names or invent an algorithm PURL.
• Use the correct relationship. A verified consumer can depend on a cryptographic asset; a verified implementation can provide it. These are different claims, and a library implementing an algorithm does not establish that the algorithm ran. Keep the observed callsite alongside the relationship. CycloneDX implementation relationships.
• Rewrite references safely. Namespace colliding bom-ref values using a recorded source-BOM mapping and rewrite every affected reference throughout the document, not only the dependency list. Preserve distinctions between software nodes and crypto nodes; do not deduplicate solely by algorithm name. Validate uniqueness and reference integrity before publishing. CycloneDX defines document-local reference uniqueness, dependency relationships, and scoped completeness. Pinned CycloneDX 1.6 schema.
• Keep provenance and coverage attached to the evidence. Record input hashes, producer versions, run identity, join rules, ambiguous/unmatched counts, policy version, and the original health counters. Do not reuse a source signature as a signature over transformed content. Runtime observation proves exercised behavior during the collection window; absence is unknown, not evidence that a dependency uses no cryptography or is quantum safe. An otherwise complete software SBOM must not promote the crypto subset to complete. Use scoped completeness declarations where appropriate and retain the more specific Census collection-health evidence.

Destination upload semantics are part of this architecture. Do not upload the ordinary SBOM and then the CBOM to the same application/version assuming the receiver adds their contents. Some inventory APIs treat each upload as a replacement snapshot; additive APIs may instead accumulate stale components. The adapter's versioned capability test must upload an SBOM with package A, then a CBOM with crypto B, and inspect whether A remains, B appears, and removals behave as documented. Dependency-Track's empirical spike is investigating this contract; no result is assumed here.

For a replacement receiver, publish one validated enriched snapshot after both producers finish, or use separately identified inventories with a verified linking strategy. For an additive receiver, require explicit ownership/removal semantics before enabling repeated updates. In either case, retain the source SBOM, source CBOM, derived artifact if present, join manifest, and delivery receipt. Enrichment also needs an explicit validation contract: the current publisher's strict Census-CBOM boundary must not be assumed to accept an arbitrary mixed software/crypto document.