feat: CBOM feature page, FAQs, blog refresh, and the EO 14412 post

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.

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.

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/).

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)

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/).

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,16 +106,18 @@ 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
 
 ### Automated Discovery
 
 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.