diff --git a/assets/images/site/cbom-inventory-card.png b/assets/images/site/cbom-inventory-card.png new file mode 100644 index 0000000..e57ce2b Binary files /dev/null and b/assets/images/site/cbom-inventory-card.png differ diff --git a/assets/images/site/cbom-protocols-tab.png b/assets/images/site/cbom-protocols-tab.png new file mode 100644 index 0000000..5db5b93 Binary files /dev/null and b/assets/images/site/cbom-protocols-tab.png differ diff --git a/assets/images/site/cbom-workspace-dashboard.png b/assets/images/site/cbom-workspace-dashboard.png new file mode 100644 index 0000000..6b435c5 Binary files /dev/null and b/assets/images/site/cbom-workspace-dashboard.png differ diff --git a/content/faq/how-do-i-upload-a-cbom.md b/content/faq/how-do-i-upload-a-cbom.md new file mode 100644 index 0000000..1af14be --- /dev/null +++ b/content/faq/how-do-i-upload-a-cbom.md @@ -0,0 +1,25 @@ +--- +title: "How do I upload a CBOM to sbomify?" +description: "Upload a Cryptography Bill of Materials (CBOM) to sbomify via the API, the CI/CD action, or the web UI, and let auto-detection tag it correctly." +answer: "Upload a CBOM exactly like an SBOM: through the API, the sbomify-action in CI, or the web UI. sbomify auto-detects CycloneDX documents whose components are cryptographic assets and tags them cbom; for a mixed document (software components plus crypto assets), set bom_type=cbom explicitly or let it run both the SBOM and crypto pipelines side by side." +tldr: "Same upload paths as SBOMs. Pure CBOMs are auto-detected; mixed documents keep their SBOM analyses and gain a crypto inventory on top. All CBOM lineages work: CycloneDX 1.6, 1.7, and legacy IBM CBOM 1.0." +weight: 87 +keywords: [CBOM upload, cryptography bill of materials, CycloneDX CBOM, crypto inventory, bom_type cbom, CBOM API] +url: /faq/how-do-i-upload-a-cbom/ +--- + +## Three ways in + +1. **API**: `POST /api/v1/sboms/artifact/cyclonedx/{component_id}` with the CBOM as the request body, exactly like an SBOM upload. Add `?bom_type=cbom` to tag it explicitly. +2. **CI/CD**: the [sbomify-action](https://github.com/sbomify/sbomify-action) uploads a pre-generated CBOM verbatim with `bom-type: cbom`, or generates one for you with `cbom-generate: true`. +3. **Web UI**: upload the file on the component page like any other artifact. + +## What auto-detection does + +A CycloneDX document whose components are all cryptographic assets is a pure CBOM and gets tagged `cbom` automatically. A software SBOM that carries some crypto assets keeps `bom_type=sbom` so it retains NTIA checks and vulnerability scanning, and the crypto inventory, post-quantum grading, and posture card run on it anyway. You lose nothing either way. + +## Which formats work + +Every CBOM lineage in circulation: CycloneDX 1.6 (what most scanners emit today), CycloneDX 1.7 with cryptography-registry identifiers, and the legacy IBM CBOM 1.0 format from older cbomkit and sonar-cryptography releases. The stored bytes are never modified; every analysis is derived on read. + +See the [CBOM feature page](/features/cbom/) for what happens after upload. diff --git a/content/faq/how-does-sbomify-grade-quantum-readiness.md b/content/faq/how-does-sbomify-grade-quantum-readiness.md new file mode 100644 index 0000000..ea31f6b --- /dev/null +++ b/content/faq/how-does-sbomify-grade-quantum-readiness.md @@ -0,0 +1,24 @@ +--- +title: "How does sbomify grade quantum readiness?" +description: "How sbomify classifies each cryptographic asset in a CBOM as quantum-safe, quantum-vulnerable, or needs-review, grounded in NIST guidance." +answer: "sbomify classifies every cryptographic asset by algorithm identity: standardized post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) grade quantum-safe; anything Shor's algorithm breaks (RSA, ECDSA, ECDH, Diffie-Hellman, all elliptic curves) grades quantum-vulnerable; Grover-weakened or unfinalized algorithms (AES-128, Falcon, XMSS) grade needs-review. Each verdict carries its reasoning and a concrete FIPS 203/204/205 migration target." +tldr: "Identity-based grading grounded in NIST FIPS 203/204/205 and CNSA 2.0: PQC algorithms are safe, Shor-breakable public-key crypto is vulnerable, edge cases get flagged for review. AES-256 and SHA-256 are safe; AES-128 needs review; a declared nistQuantumSecurityLevel never overrides what the algorithm actually is." +weight: 88 +keywords: [quantum readiness, post-quantum cryptography, PQC grading, ML-KEM, ML-DSA, SLH-DSA, quantum-vulnerable, CBOM analysis, CNSA 2.0] +url: /faq/how-does-sbomify-grade-quantum-readiness/ +--- + +## The verdicts + +Every asset in a CBOM gets one of four grades: + +- **Quantum-safe**: NIST-standardized post-quantum algorithms (ML-KEM / FIPS 203, ML-DSA / FIPS 204, SLH-DSA / FIPS 205, including their pre-standardization names Kyber, Dilithium, and SPHINCS+), plus symmetric crypto and hashes at adequate strength (AES-192/256, ChaCha20, SHA-256 and up). +- **Quantum-vulnerable**: everything Shor's algorithm breaks: RSA, DSA, ECDSA, EdDSA, ECDH, X25519, Diffie-Hellman, and any elliptic-curve construction. The verdict includes a migration target: signatures point at ML-DSA or SLH-DSA, key establishment at ML-KEM. +- **Needs review**: Grover-weakened sizes (AES-128), classically broken primitives (MD5, SHA-1, DES, 3DES), and PQC candidates that are selected but not finalized (Falcon/FN-DSA, HQC) or stateful special-use schemes (XMSS, LMS). +- **Unknown**: the algorithm could not be identified; certificates and protocols without algorithm identity are marked not-assessed rather than guessed. + +## How identification works + +The classifier reads the asset's name, algorithm family, curve, parameter set, and OID, normalized against the CycloneDX 1.7 cryptography registry, so `secp256r1`, `prime256v1`, and `nist/P-256` all classify identically. A declared `nistQuantumSecurityLevel` never overrides algorithm identity; it only raises a data-quality flag when it contradicts the verdict, so a mislabeled CBOM cannot grade itself safe. + +Component verdicts roll up to a workspace [cryptography dashboard](/features/cbom/) that ranks which algorithms to migrate first by how many components use them. diff --git a/content/faq/which-tools-generate-cboms.md b/content/faq/which-tools-generate-cboms.md new file mode 100644 index 0000000..f5268a8 --- /dev/null +++ b/content/faq/which-tools-generate-cboms.md @@ -0,0 +1,35 @@ +--- +title: "Which tools generate CBOMs?" +description: "Tools that generate a Cryptography Bill of Materials (CBOM): the sbomify GitHub Action with cdxgen, PQCA cbomkit, cbomkit-theia for containers, and commercial scanners." +answer: "The sbomify-action generates a CBOM in CI with cbom-generate: true (cdxgen crypto detection for Java and Python projects, JS/TS source, keystores, and certificates). PQCA's cbomkit scans Java and Python source, and cbomkit-theia scans container images for certificates and keys. Any tool that emits CycloneDX cryptographic assets works; sbomify ingests them all." +tldr: "Easiest: sbomify-action with cbom-generate: true. Deepest source analysis: PQCA cbomkit (Java/Python). Container images: cbomkit-theia. All emit CycloneDX, and sbomify ingests every CBOM lineage including legacy IBM CBOM 1.0 output." +weight: 89 +keywords: [CBOM generation, cdxgen crypto, cbomkit, cbomkit-theia, sonar-cryptography, CBOM tools, generate CBOM, CycloneDX cryptographic asset] +url: /faq/which-tools-generate-cboms/ +--- + +## In your CI pipeline (easiest) + +The [sbomify-action](https://github.com/sbomify/sbomify-action) generates and uploads in one step: + +```yaml +- uses: sbomify/sbomify-action@master + with: + cbom-generate: true + env: + TOKEN: ${{ secrets.SBOMIFY_TOKEN }} + COMPONENT_ID: 'your-component-id' + LOCK_FILE: 'pom.xml' +``` + +Under the hood this runs [cdxgen](https://github.com/cdxgen/cdxgen) with crypto detection: Java and Python projects, JavaScript/TypeScript source analysis, keystores, and certificates. + +## Dedicated crypto scanners + +- **[cbomkit](https://github.com/cbomkit)** (PQCA / Linux Foundation, formerly IBM): sonar-cryptography performs deep source analysis for Java and Python; the cbomkit GitHub action wraps it for CI. Pass its output through the sbomify-action with `bom-type: cbom`. +- **[cbomkit-theia](https://github.com/cbomkit/cbomkit-theia)**: scans container images and filesystems for certificates, keys, and crypto configuration. +- **Commercial scanners**: several vendors export CycloneDX CBOMs from source or binaries; anything emitting CycloneDX cryptographic assets uploads to sbomify verbatim. + +## Already have crypto data in your SBOMs? + +If your SBOM generator embeds cryptographic assets in ordinary SBOMs, sbomify derives the crypto inventory from those documents automatically; no separate CBOM needed. See [How do I upload a CBOM?](/faq/how-do-i-upload-a-cbom/) and the [CBOM feature page](/features/cbom/). diff --git a/content/features/_index.md b/content/features/_index.md index 273e580..2848f83 100644 --- a/content/features/_index.md +++ b/content/features/_index.md @@ -15,6 +15,10 @@ Streamline your SBOM workflow from creation to analysis. Our comprehensive tools Turn transparency into a competitive advantage. Share SBOMs, VEX statements, and security certifications (like SOC 2 and ISO 27001) with stakeholders through a branded, automated portal. Support for both public transparency and private, invited access ensures you stay in control. [Explore Trust Center →](/features/trust-center/) +### CBOM: Cryptography Bill of Materials + +Know your cryptographic posture before the post-quantum deadlines arrive. Upload CBOMs (or SBOMs with embedded crypto assets), get every algorithm graded for quantum readiness, track certificate expiry, export cipher-suite inventories for PCI DSS 12.3.3, and share your posture on your Trust Center. [Explore CBOM support →](/features/cbom/) + ### SBOM Hierarchy Understand complex relationships between your software components with our hierarchical view. Map dependencies across your entire software portfolio and identify potential vulnerabilities at any level. [Discover SBOM Hierarchy →](/features/sbom-hierarchy) diff --git a/content/features/cbom.md b/content/features/cbom.md new file mode 100644 index 0000000..10027e3 --- /dev/null +++ b/content/features/cbom.md @@ -0,0 +1,58 @@ +--- + +title: "CBOM: Cryptography Bill of Materials Management" +description: "Upload, analyze, and share Cryptography Bills of Materials (CBOMs) with sbomify: automatic CBOM detection, post-quantum readiness grading, certificate and cipher-suite views, and release-level crypto inventories." + +--- + +Your [SBOMs](/what-is-sbom/) tell you what software you ship. A **CBOM (Cryptography Bill of Materials)** tells you what cryptography that software uses: algorithms, key sizes, certificates, and protocols. With NIST's post-quantum standards finalized and [EO 14412](/blog/) directing CISA and NIST to define CBOM minimum elements, cryptographic visibility is moving from nice-to-have to mandated. sbomify treats CBOMs as first-class artifacts, end to end. + +## Upload once, sbomify does the rest + +Upload a CycloneDX document through the [same API, CI/CD action, or UI](/features/generate-collaborate-analyze/) you already use for SBOMs. sbomify recognizes cryptographic content automatically: + +- A pure CBOM (every component a cryptographic asset) is tagged `cbom` and gets the full crypto pipeline. +- A software SBOM with embedded crypto assets keeps its SBOM pipelines (NTIA checks, vulnerability scanning) **and** gains a crypto inventory. You never trade one analysis for the other. +- Every CBOM lineage ingests: CycloneDX 1.6, CycloneDX 1.7 with registry identifiers, and the legacy IBM CBOM 1.0 format that older scanners emitted. Documents are stored byte-for-byte unmodified; every analysis is derived on read. + +## A crypto inventory you can actually read + +![Cryptographic asset inventory with per-asset quantum readiness grading](/assets/images/site/cbom-inventory-card.png) + +Each artifact gets a tabbed cryptographic inventory: + +- **Assets** - every algorithm, key, certificate, and protocol, graded for post-quantum readiness. Expand any row for the verdict's reasoning, NIST security levels, and a concrete migration target: quantum-vulnerable signatures point at ML-DSA (FIPS 204) or SLH-DSA (FIPS 205), key establishment at ML-KEM (FIPS 203). +- **Certificates** - subject, issuer, validity window, and a live expiry countdown with expired and expiring-soon flags, sorted soonest first. +- **Protocols** - cipher suites per protocol and version, with weak suites flagged (RC4, 3DES, NULL, export-grade) and deprecated protocol versions called out. + +Algorithm names normalize against the CycloneDX 1.7 cryptography registry, so `prime256v1`, `secp256r1`, and `nist/P-256` all resolve to the same curve however your scanner spelled it. + +## PCI DSS 12.3.3 evidence in one click + +![Protocol and cipher-suite view with weak-suite flagging](/assets/images/site/cbom-protocols-tab.png) + +PCI DSS 4.x requirement 12.3.3, mandatory since March 31, 2025, requires a documented inventory of cipher suites and protocols in use, reviewed annually. sbomify derives that inventory from your CBOMs and exports it as CSV, ready to attach to your assessment. + +## Quantum readiness across the whole workspace + +![Workspace cryptography dashboard with migrate-first guidance](/assets/images/site/cbom-workspace-dashboard.png) + +The workspace cryptography dashboard rolls every component up into one view: how many are at risk, which algorithms to migrate first ranked by how many components use them, and certificate expiry across the fleet, recomputed live. CNSA 2.0's 2030-2033 transition deadlines stop being abstract when the dashboard names the exact algorithms in your estate. + +## Share it like everything else + +CBOMs plug into the sharing machinery you already have: + +- **[Trust Center](/features/trust-center/)** - your public component pages show the crypto posture card and full inventory, so customers can verify your quantum readiness without asking. +- **Release-level CBOM** - one merged CycloneDX document per [release](/features/sbom-hierarchy/), combining every component's CBOM. Emits CycloneDX 1.6 by default for maximum tool compatibility, or native 1.7 on request. +- **[TEA](/faq/how-do-i-enable-tea-in-sbomify/)** - CBOMs are enumerated alongside SBOMs and VEX in the Transparency Exchange API. + +## Generating a CBOM + +No scanner yet? Three well-trodden paths, all ending in a one-line upload: + +1. **[sbomify-action](https://github.com/sbomify/sbomify-action)** with `cbom-generate: true` runs [cdxgen](https://github.com/cdxgen/cdxgen) crypto detection over your project (Java and Python projects, JS/TS source analysis, keystores, certificates) and uploads the result. +2. **[cbomkit](https://github.com/cbomkit)** (PQCA / Linux Foundation) scans Java and Python source with sonar-cryptography; its GitHub action drops a CycloneDX CBOM you pass through with `bom-type: cbom`. +3. **Any CycloneDX CBOM** from commercial scanners or hand-authored inventories uploads verbatim; sbomify never modifies the document. + +More detail in the [FAQ on CBOM generation tools](/faq/which-tools-generate-cboms/). diff --git a/content/posts/2024-04-10-future-proofing-cybersecurity-with-the-cryptography-bill-of-materials-cbom.md b/content/posts/2024-04-10-future-proofing-cybersecurity-with-the-cryptography-bill-of-materials-cbom.md index d126ab1..5ffa81d 100644 --- a/content/posts/2024-04-10-future-proofing-cybersecurity-with-the-cryptography-bill-of-materials-cbom.md +++ b/content/posts/2024-04-10-future-proofing-cybersecurity-with-the-cryptography-bill-of-materials-cbom.md @@ -22,6 +22,7 @@ faq: - question: "How do I generate a CBOM?" answer: "CycloneDX tools can generate CBOMs by analyzing codebases for cryptographic library usage, certificate stores, and protocol configurations. IBM's CBOM toolkit and Crypto Discovery tools provide automated scanning. For many organizations, the first CBOM is compiled manually by inventorying TLS configurations, key management systems, and cryptographic library dependencies." date: 2024-04-10 +lastmod: 2026-07-22 slug: future-proofing-cybersecurity-with-the-cryptography-bill-of-materials-cbom --- @@ -105,7 +106,9 @@ CBOMs and [SBOMs](/what-is-sbom/) are complementary inventories that address dif CycloneDX supports both in the same document. An organization generating CycloneDX SBOMs can extend them to include cryptographic asset data, producing a unified inventory that covers both component composition and cryptographic posture. -For organizations managing SBOMs with [sbomify](https://sbomify.com), adding CBOM data to the same CycloneDX documents means cryptographic assets become part of the same management, monitoring, and sharing workflow already in place for software components. +CBOM support is standardized: CycloneDX 1.6 (ECMA-424, 1st edition, June 2024) made cryptographic assets a first-class component type, and CycloneDX 1.7 (2nd edition, December 2025) added a cryptography registry of canonical algorithm and curve identifiers so different scanners name the same algorithm the same way. + +[sbomify](https://sbomify.com) treats CBOMs as first-class artifacts, whether they arrive as standalone CBOM documents or as crypto assets embedded in ordinary SBOMs. Uploads auto-detect cryptographic content, every asset is graded for post-quantum readiness with a concrete FIPS 203/204/205 migration target, certificates get live expiry countdowns, cipher suites export as PCI DSS 12.3.3 evidence, and a workspace dashboard ranks which algorithms to migrate first. The full walkthrough is on the [CBOM feature page](/features/cbom/). ## Generating a CBOM @@ -113,8 +116,8 @@ For organizations managing SBOMs with [sbomify](https://sbomify.com), adding CBO Several tools support automated cryptographic asset discovery: -- **[CycloneDX CBOM tools](https://cyclonedx.org/capabilities/cbom/)** – Generate CycloneDX-formatted CBOMs by analyzing dependencies and configurations -- **IBM Quantum Safe tools** – Scan codebases and running systems for cryptographic usage patterns +- **[sbomify-action](https://github.com/sbomify/sbomify-action)** – set `cbom-generate: true` and it runs [cdxgen](https://github.com/cdxgen/cdxgen) crypto detection over your project and uploads the result +- **[cbomkit](https://github.com/cbomkit)** (PQCA / Linux Foundation, formerly IBM) – deep source analysis for Java and Python via sonar-cryptography, plus [cbomkit-theia](https://github.com/cbomkit/cbomkit-theia) for container images - **Certificate inventory tools** – Tools like `certbot`, `openssl`, and cloud provider APIs can enumerate certificates across infrastructure ### Manual Inventory @@ -135,10 +138,11 @@ Like SBOMs, CBOMs should be treated as living documents. Certificate expirations Cryptographic transparency is gaining regulatory attention: +- **[Executive Order 14412](https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/)** (June 2026) – the first US federal document to name the CBOM: CISA and NIST must publish CBOM minimum-elements guidance by roughly March 2027, with federal post-quantum deadlines behind it (key establishment on high-value assets by end of 2030, signatures by end of 2031). Our [EO 14412 deep dive](/2026/07/22/eo-14412-cbom-minimum-elements/) covers what to expect - **NSA CNSA 2.0** – The Commercial National Security Algorithm Suite 2.0 sets timelines for U.S. national security systems to transition to quantum-resistant algorithms, starting in 2025 - **[Executive Order 14028](/compliance/eo-14028/)** and subsequent White House memoranda on quantum computing direct federal agencies to inventory cryptographic systems and develop migration plans - **[EU Cyber Resilience Act](/compliance/eu-cra/)** requires products with digital elements to implement "appropriate" cryptographic protection – documenting that cryptography via CBOMs supports compliance -- **PCI DSS 4.0** requires inventories of cryptographic algorithms and key management practices for payment card environments +- **PCI DSS 4.x requirement 12.3.3** – mandatory since March 31, 2025 – requires a documented, annually reviewed inventory of the cipher suites and protocols in use in payment card environments, which is CBOM data by another name Organizations that proactively build CBOMs will be ahead of the compliance curve as these requirements mature. diff --git a/content/posts/2026-07-22-eo-14412-cbom-minimum-elements.md b/content/posts/2026-07-22-eo-14412-cbom-minimum-elements.md new file mode 100644 index 0000000..81e7746 --- /dev/null +++ b/content/posts/2026-07-22-eo-14412-cbom-minimum-elements.md @@ -0,0 +1,72 @@ +--- + +title: "EO 14412 and the Coming CBOM Minimum Elements" +description: "Executive Order 14412 is the first US federal document to name the CBOM, directing CISA and NIST to publish minimum-elements guidance by roughly March 2027. Here is what it says, what to expect, and how to get ready." +categories: + - compliance +tags: [cbom, eo-14412, post-quantum, compliance, cryptography] +tldr: "Executive Order 14412 (June 22, 2026) directs CISA and NIST to publish minimum elements for a Cryptography Bill of Materials within 270 days, putting CBOMs on the same standardization path SBOMs took with the NTIA minimum elements in 2021. Federal deadlines follow: post-quantum key establishment on high-value assets by end of 2030, signatures by end of 2031. PCI DSS 12.3.3 already mandates cipher-suite and protocol inventories commercially. Start building your crypto inventory now." +author: + display_name: Cowboy Neil + login: Cowboy Neil + url: https://sbomify.com +faq: + - question: "What is EO 14412?" + answer: "Executive Order 14412 (June 22, 2026) is a US executive order on securing systems against advanced cryptographic attacks. It is the first US federal document to name the Cryptography Bill of Materials (CBOM), directing CISA and NIST to publish minimum-elements guidance for CBOMs within 270 days, and setting post-quantum migration deadlines for federal systems." + - question: "When is the CBOM minimum-elements guidance due?" + answer: "The executive order gives CISA and NIST 270 days from June 22, 2026, which lands around March 2027. The guidance is expected to define the minimum fields and structure a CBOM must carry, playing the same standardizing role for crypto inventories that the NTIA minimum elements played for SBOMs in 2021." + - question: "What are the federal post-quantum deadlines?" + answer: "Under EO 14412, federal high-value assets must run post-quantum key establishment by the end of 2030 and post-quantum digital signatures by the end of 2031, with FAR rules proposed to extend requirements to federal contractors. NSA CNSA 2.0 separately requires new national security system acquisitions to support post-quantum algorithms from January 1, 2027, with full transition by 2033." + - question: "Does this affect commercial organizations?" + answer: "Directly, through supply chains: FAR rules will flow federal requirements down to contractors, and every vendor selling into government will feel it. Independently, PCI DSS 4.x requirement 12.3.3 has required a documented, annually reviewed inventory of cipher suites and protocols in use since March 31, 2025, which is CBOM data by another name." +date: 2026-07-22 +slug: eo-14412-cbom-minimum-elements + +--- + +In 2021, the NTIA published the [minimum elements for an SBOM](/what-is-sbom/), and software bills of materials went from a niche practice to a procurement requirement in a few short years. On June 22, 2026, the same thing started happening to cryptography inventories: [Executive Order 14412](https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/) became the first US federal document to name the **CBOM (Cryptography Bill of Materials)**, and it put a deadline on defining one. + +## What the executive order says + +Three provisions matter for anyone who ships software: + +1. **CBOM minimum elements.** CISA and NIST must publish minimum-elements guidance for Cryptography Bills of Materials within 270 days, which lands around **March 2027**. Expect it to define the fields a CBOM must carry: algorithms and their parameters, certificates, protocols, and enough context to assess quantum exposure. +2. **Federal post-quantum deadlines.** Federal high-value assets must run post-quantum key establishment by the **end of 2030** and post-quantum digital signatures by the **end of 2031**. You cannot plan either migration without knowing what cryptography you run today, which is exactly what the CBOM requirement exists to fix. +3. **Contractor flow-down.** FAR rules are to be proposed extending requirements to federal contractors. As with SBOMs after [EO 14028](/compliance/eo-14028/), the practical audience is not just agencies; it is everyone who sells to them. + +This sits on top of deadlines that already exist. [NSA CNSA 2.0](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF) requires new national security system acquisitions to support post-quantum algorithms from January 1, 2027, with full transition by 2033. NIST's migration guidance ([NIST IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd), still a draft) sketches the same trajectory for everyone else. + +## The commercial mandate is already here + +While federal guidance is being written, one commercial requirement is already enforceable: **PCI DSS 4.x requirement 12.3.3**, mandatory since March 31, 2025, requires a documented inventory of the cipher suites and protocols in use across the cardholder data environment, reviewed at least annually. + +Read that requirement next to the CycloneDX CBOM specification and the overlap is complete: an inventory of protocols and cipher suites _is_ CBOM data. Organizations producing CBOMs today can [export exactly that inventory as evidence](/features/cbom/), while everyone else assembles it by hand every assessment cycle. + +## What minimum elements will likely contain + +Nobody outside CISA and NIST knows the final shape, but the raw material is public. CycloneDX, the only major BOM format with cryptographic modeling, was standardized as [ECMA-424](https://cyclonedx.org/) (1st edition, June 2024, CycloneDX 1.6; 2nd edition, December 2025, CycloneDX 1.7). Its model covers: + +- **Algorithms**: name, family, parameter set, curve, key size, mode, and the NIST security categories +- **Certificates**: subject, issuer, validity window, signature algorithm, lifecycle state +- **Protocols**: versions and negotiated cipher suites +- **Related material**: keys, tokens, and secrets, with references linking assets to the algorithms that secure them + +CycloneDX 1.7 added a cryptography registry: canonical identifiers for roughly a hundred algorithm families and two hundred fifty named curves, so `prime256v1` and `nist/P-256` stop being two different answers to the same question. If the guidance names a machine-readable format, this is the obvious candidate; the NTIA minimum elements similarly leaned on the formats that already existed. + +## How sbomify handles CBOMs today + +We built [CBOM support](/features/cbom/) so the inventory exists before the mandate does: + +- **Every lineage ingests**: CycloneDX 1.6, 1.7 with registry identifiers, and the legacy IBM CBOM 1.0 format from older scanners. Artifacts are stored unmodified; analysis is derived on read. +- **Post-quantum grading**: every asset classifies as quantum-safe, quantum-vulnerable, or needs-review, grounded in FIPS 203/204/205 and CNSA 2.0, with a concrete migration target per vulnerable asset. +- **Certificates and protocols**: live expiry countdowns, weak-suite flagging, and a one-click cipher-suite inventory export for PCI DSS 12.3.3. +- **Fleet view**: a workspace cryptography dashboard that ranks which algorithms to migrate first, by how many components use them. +- **Sharing**: crypto posture on your public [Trust Center](/features/trust-center/), and a merged release-level CBOM per product release. + +When the minimum-elements guidance lands, we will ship an assessment that checks your CBOMs against it, the same way we [assess SBOMs against the NTIA minimum elements](/features/generate-collaborate-analyze/) today. + +## Start now, not in March + +The lesson from the SBOM cycle is that the organizations that started inventorying before the mandates spent the mandate years refining, while everyone else spent them scrambling. The first CBOM is the hard one; [generating it](/faq/which-tools-generate-cboms/) is a solved problem, and the deadlines behind the guidance (2030 and 2031 for federal systems, 2033 for CNSA 2.0) are close enough that harvest-now-decrypt-later adversaries are already counting on your delay. + +Upload a CBOM to [sbomify](https://app.sbomify.com) and you will know your quantum exposure this afternoon. diff --git a/llms.txt b/llms.txt index 8d599c6..5bb3c45 100644 --- a/llms.txt +++ b/llms.txt @@ -19,6 +19,7 @@ This website provides: - /features/trust-center/ - Trust Center for sharing security artifacts - /features/integrations/ - CI/CD integrations (GitHub, GitLab, Bitbucket) - /features/sbom-hierarchy/ - Product, Component, Release hierarchy +- /features/cbom/ - CBOM (Cryptography Bill of Materials) management and post-quantum readiness - /pricing/ - Pricing plans (Community, Business, Enterprise) - /blog/ - Technical articles and announcements - /resources/ - SBOM tools directory and lifecycle overview