From 0853d0be053b7c5d3e98c8ebb0488c47b0789c7a Mon Sep 17 00:00:00 2001 From: Cyborg Viktor <307551610+vpetersson-bot@users.noreply.github.com> Date: Thu, 30 Jul 2026 10:32:31 +0000 Subject: [PATCH 1/4] Add v26.7.1 release announcement post Drafts the release post for v26.7.1, following the house pattern for release announcements (byline Viktor Petersson, "The One That ..." title, TL;DR block, per-theme sections, Getting Started). Leads on VEX, which is the substantive change in this release: three formats, in-product triage, Dependency-Track sync, and scheduled drift detection. Then CBOM ingestion breadth (framed as closing the gap left by v26.7.0), Trust Center exposure, and the vulnerability-count posture fix, which is called out separately because users will see their totals drop. Left as `draft: true` so merging does not publish it before it has been reviewed -- delete that line to ship. Verified: dprint clean, Hugo builds, and every internal link resolves (previous release post, /features/ trust-center/, /authors/vpetersson/, all tag pages). (cherry picked from commit 0fd7024e14a81253facdd55e12b8588f2d2cc0dc) --- ...-v26-7-1-the-one-that-says-not-affected.md | 109 ++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 content/posts/2026-07-30-announcing-sbomify-v26-7-1-the-one-that-says-not-affected.md diff --git a/content/posts/2026-07-30-announcing-sbomify-v26-7-1-the-one-that-says-not-affected.md b/content/posts/2026-07-30-announcing-sbomify-v26-7-1-the-one-that-says-not-affected.md new file mode 100644 index 0000000..458b127 --- /dev/null +++ b/content/posts/2026-07-30-announcing-sbomify-v26-7-1-the-one-that-says-not-affected.md @@ -0,0 +1,109 @@ +--- +title: "Announcing sbomify v26.7.1: The One That Says \"Not Affected\"" +description: "sbomify v26.7.1 ships end-to-end VEX support across CycloneDX, OpenVEX, and CSAF, with in-product triage, Dependency-Track sync, and scheduled drift detection. CBOM ingestion now covers every lineage, the Trust Center exposes VEX and CBOM per release, and vulnerability counts finally reflect your current posture." +author: + display_name: Viktor Petersson +categories: + - announcement +tags: [sbom, release, vex, openvex, csaf, cbom, vulnerability-management, trust-center] +tldr: "sbomify v26.7.1 makes VEX a first-class citizen: author or upload VEX in CycloneDX, OpenVEX, or CSAF, triage findings in the product, sync triage decisions from Dependency-Track, and let scheduled drift detection tell you when your statements have gone stale or a new High/Critical finding is uncovered. The release also broadens CBOM ingestion to every lineage, surfaces VEX and CBOM per release in the Trust Center, and fixes vulnerability counts so they reflect your current release rather than every SBOM you have ever uploaded." +date: 2026-07-30 +slug: announcing-sbomify-v26-7-1-the-one-that-says-not-affected +draft: true +--- + +An SBOM tells you what is in your software. A vulnerability scanner tells you which of those components have known CVEs. Neither answers the question your customers actually ask: **are you affected?** + +Most of the time, the honest answer is no. The vulnerable function is never called, the affected code path is compiled out, the component ships but is never reachable. That answer has a standard format, VEX, and until now sbomify could store it but not really work with it. v26.7.1 changes that. Here is what matters for you. + +## VEX, End to End + +**VEX** (Vulnerability Exploitability eXchange) is a machine-readable statement about whether a specific vulnerability actually affects a specific product. Instead of shipping an SBOM and leaving your customers to draw their own conclusions from a raw CVE list, you tell them: this one is not affected, and here is why. + +The reason this matters is asymmetric effort. Without VEX, every customer who scans your artifact independently rediscovers the same forty findings and files the same questions with your security team. With VEX, you make the determination once and it travels with the product. + +v26.7.1 supports the whole lifecycle: + +- **Three formats, one workflow.** Author or upload VEX as CycloneDX VEX, [OpenVEX](https://github.com/openvex), or [CSAF](https://oasis-open.github.io/csaf-documentation/). sbomify ingests all three and normalizes them, so your choice of format is a detail rather than a commitment. +- **Triage inside the product.** Findings can be triaged where you already look at them, with the status and justification recorded as a proper VEX statement rather than a comment in a spreadsheet. +- **Dependency-Track triage sync.** If your team already triages in Dependency-Track, that work no longer has to be redone. Opt in, and triage decisions flow into sbomify and are automatically pinned to the relevant release. +- **Scheduled drift detection.** This is the part teams underestimate. VEX statements go stale: a new version changes whether a code path is reachable, or a new High/Critical finding lands with no statement covering it at all. sbomify now checks on a schedule and tells you, rather than letting a six-month-old "not affected" quietly become wrong. + +That last point is the difference between VEX as a compliance artifact and VEX as something you can actually rely on. + +--- + +## CBOM: Every Lineage Now Ingests + +[v26.7.0 introduced Cryptography BOM support](/2026/07/07/announcing-sbomify-v26-7-0-the-one-that-gets-quantum-ready/) and post-quantum readiness assessment. The gap in that release was ingestion breadth: depending on which tool produced your CBOM, sbomify might or might not recognize it. + +That gap is closed. Every CBOM lineage now ingests, with CycloneDX 1.7 crypto-registry normalization so assets from different generators land in the same shape. Alongside that, the crypto asset UX has been reworked, CBOMs are exposed through [TEA](https://github.com/CycloneDX/transparency-exchange-api), and your workspace dashboard now includes crypto posture next to everything else. + +If you tried CBOM upload last month and your generator was not picked up, try again. + +--- + +## The Trust Center Gets Your Posture + +Your [Trust Center](/features/trust-center/) is the public face of all this, and it now carries the new artifacts: + +- **VEX and CBOM downloads per release**, alongside the SBOMs already there. +- **Vulnerability posture on the release page**, so a customer can see your position without emailing you for it. +- **A simpler posture panel.** The VEX toggle is gone. It was a control that asked visitors to understand an implementation detail before they could read the page, which is precisely backwards for a page aimed at people evaluating your product. + +--- + +## Numbers That Reflect Reality + +One fix in this release deserves calling out on its own, because if you looked at your vulnerability counts before today, they were probably wrong in a specific and unhelpful way. + +Counts were aggregated across **every historical SBOM version** rather than your current posture. Upload ten iterations of a component over six months, fix things along the way, and the dashboard still counted findings from all ten. The number went up and never came down. + +Counts now reflect current posture. Expect your totals to drop, in most cases substantially. Nothing was fixed by the change itself; the number is simply telling the truth now. + +Alongside that: + +- **Component pages no longer time out at scale.** Two query fixes for workspaces with large artifact histories, where the page could hit a 504. +- **Dependency-Track 4 and 5 both work**, including findings pagination. +- **The SBOMs list shows the latest artifact per format**, not just the most recent upload overall, so a CycloneDX SBOM no longer hides behind an SPDX one. +- **Skipped assessments read as skipped**, not as warnings. A skipped scan is information, not a problem to investigate. + +--- + +## A Fresh Look + +The dashboard onboarding flow has been redesigned, and component, product, and vulnerability pages have had a design refresh. Under it, the front end has migrated to Tailwind v4 colours, which mostly means the palette is consistent in places it previously was not. + +--- + +## API and Security + +- **Workspace-scoped tokens are enforced across the whole workspaces API.** A token bound to one workspace cannot read another, on every endpoint rather than most of them. +- **The component SBOMs list endpoint gains version and format filtering**, so you can ask for exactly the artifact you want instead of fetching everything and filtering client-side. +- **Dependency updates** covering pillow, pyasn1, and datamodel-code-generator. + +--- + +## Under the Hood + +A few things that are invisible in the product but change how quickly we can respond when something breaks for you: + +- Every app's test suite now runs in CI, and CI fails loudly if one goes missing rather than silently skipping it. +- Frontend test failures can no longer pass CI silently, and a long-standing flake in the vulnerability trends timeline is fixed. +- Our error tracking stopped tagging production events as `development`, which had been quietly hiding production alerts from the people meant to see them. + +Unglamorous, but it is the difference between hearing about a problem from our monitoring and hearing about it from you. + +--- + +## Getting Started + +If you are on the **hosted platform**, all of the above is already live. The fastest way to see the VEX work is to open a component with known findings and triage one: pick a status, record a justification, and note that what you get back is a real VEX statement you can publish, not an annotation trapped in our database. If you already triage in Dependency-Track, enable the sync instead and let your existing decisions flow in. + +For **self-hosted** deployments, pull `ghcr.io/sbomify/sbomify:v26.7.1` and update. + +Either way, check your vulnerability counts after upgrading. If they drop sharply, that is the posture fix working as intended. + +For the full technical detail, see the [v26.7.1 release notes on GitHub](https://github.com/sbomify/sbomify/releases/tag/v26.7.1). + +As always, I would like to hear how this lands, and particularly where the VEX workflow does not fit how your team actually triages. VEX is a young standard and the tooling around it is still finding its shape; if the model we have chosen gets in your way, that is useful for us to know. Open a support ticket from inside [the app](https://app.sbomify.com) and it will reach the team. From 3b531acad38f792e3a284152875954c97a96ddde Mon Sep 17 00:00:00 2001 From: Cyborg Viktor <307551610+vpetersson-bot@users.noreply.github.com> Date: Thu, 30 Jul 2026 10:41:24 +0000 Subject: [PATCH 2/4] Fix three broken internal links Found by a site-wide link audit of the built output (331 pages). All three predate this change and 404 today: - posts/2026-01-23-...-attestations.md used a /blog/ prefix for a post permalink; the permalink format is /:year/:month/:day/:title/ - compliance/fda-medical-device.md linked /blog/fda-medical-device-sbom- requirements/ instead of the post's dated permalink - faq/why-do-i-need-an-sbom.md linked /compliance/fda/, which does not exist; the page is /compliance/fda-medical-device/ Verified: dprint clean, Hugo builds, and a re-run of the audit reports zero broken internal links across the site. (cherry picked from commit bf5f8612316a65b26c60b48c69c069f9e5b52931) --- content/compliance/fda-medical-device.md | 2 +- content/faq/why-do-i-need-an-sbom.md | 2 +- ...-01-23-announcing-sbomify-v0-25-the-one-with-attestations.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/compliance/fda-medical-device.md b/content/compliance/fda-medical-device.md index 0d2b04c..b4c339f 100644 --- a/content/compliance/fda-medical-device.md +++ b/content/compliance/fda-medical-device.md @@ -59,7 +59,7 @@ sbomify ships an **FDA Medical Device (2025)** plugin that grades each uploaded ## Additional Resources -For more details, see our [FDA Medical Device SBOM Requirements guide](/blog/fda-medical-device-sbom-requirements/). +For more details, see our [FDA Medical Device SBOM Requirements guide](/2026/01/09/fda-medical-device-sbom-requirements/). ## Official Source diff --git a/content/faq/why-do-i-need-an-sbom.md b/content/faq/why-do-i-need-an-sbom.md index bd1e3ab..b62d19b 100644 --- a/content/faq/why-do-i-need-an-sbom.md +++ b/content/faq/why-do-i-need-an-sbom.md @@ -25,7 +25,7 @@ SBOMs are increasingly required by law and industry standards: - **[EU Cyber Resilience Act (CRA)](/compliance/eu-cra/)** - Requires SBOMs for all products with digital elements sold in the EU - **[NTIA Minimum Elements](/compliance/ntia-minimum-elements/)** - US government baseline for SBOM content - **[NIST 800-171](/compliance/nist-800-171/)** - Supply chain risk management requirements -- **[FDA guidance](/compliance/fda/)** - Medical device manufacturers must submit SBOMs +- **[FDA guidance](/compliance/fda-medical-device/)** - Medical device manufacturers must submit SBOMs - **[PCI DSS 4.0](/compliance/pci-dss/)** - Payment industry now references software composition analysis See our full [Compliance guide](/compliance/) for details on each framework. diff --git a/content/posts/2026-01-23-announcing-sbomify-v0-25-the-one-with-attestations.md b/content/posts/2026-01-23-announcing-sbomify-v0-25-the-one-with-attestations.md index 4545ad4..c5195b9 100644 --- a/content/posts/2026-01-23-announcing-sbomify-v0-25-the-one-with-attestations.md +++ b/content/posts/2026-01-23-announcing-sbomify-v0-25-the-one-with-attestations.md @@ -43,7 +43,7 @@ Knowing when your software reaches end-of-support or end-of-life is critical for You can set these dates manually in the UI for both **products** and **components**. This is useful for tracking your own release schedules and support commitments. -For common Linux distributions and frameworks, lifecycle data can also be added automatically. The [Lifecycle Database](/blog/2026/01/20/announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi/#know-when-your-software-goes-end-of-life) in sbomify-action embeds CLE data directly into your SBOMs during generation. This covers distributions like Ubuntu, Debian, Alpine, and Fedora, as well as language runtimes and frameworks including Python, Go, Django, Rails, and React. +For common Linux distributions and frameworks, lifecycle data can also be added automatically. The [Lifecycle Database](/2026/01/20/announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi/#know-when-your-software-goes-end-of-life) in sbomify-action embeds CLE data directly into your SBOMs during generation. This covers distributions like Ubuntu, Debian, Alpine, and Fedora, as well as language runtimes and frameworks including Python, Go, Django, Rails, and React. These dates flow through to your Trust Center and can be displayed on public product pages. For organizations subject to regulations like the [EU Cyber Resilience Act](/compliance/eu-cra/), tracking lifecycle information is a requirement. From d3aec44b559b6217852a9ec60fd6842e5a0eb88f Mon Sep 17 00:00:00 2001 From: Cyborg Viktor <307551610+vpetersson-bot@users.noreply.github.com> Date: Thu, 30 Jul 2026 10:45:26 +0000 Subject: [PATCH 3/4] FAQ: cover the v26.7.1 features Audited the FAQ against the v26.7.1 release notes. Most of the release was already covered -- VEX formats, Dependency-Track sync, Trust Center VEX and CBOM exposure, and the CycloneDX/SPDX version claims all matched the code. Three gaps remained. how-do-i-use-vex.md Scheduled drift detection was documented nowhere on the site. Adds a "Keeping your statements current" section covering stale statements and uncovered High/Critical findings, and explains why a stale not_affected is worse than no VEX. Also marks the Dependency-Track sync as opt-in, which the previous wording did not say. what-is-a-cbom.md Ingestion previously depended on which generator produced the CBOM. Notes that every lineage now ingests and that assets are normalized against the CycloneDX 1.7 crypto registry, plus the new workspace-level crypto posture. how-does-sbomify-count-vulnerabilities.md (new, weight 69) Counts now reflect current posture rather than a sum over every historical SBOM version, so totals drop on upgrade. That reads like a bug without an explanation, and support will be asked. Also documents what a count includes, VEX suppression, and why release-scoped counts are pinned to the artifacts actually shipped. Verified: dprint clean, Hugo builds, new FAQ renders and appears in the FAQ index, and all internal links in the changed pages resolve. (cherry picked from commit 71587277d4f66326fb7b78e425be8081ef2efdf0) --- content/faq/how-do-i-use-vex.md | 17 ++++++-- .../how-does-sbomify-count-vulnerabilities.md | 43 +++++++++++++++++++ content/faq/what-is-a-cbom.md | 5 ++- 3 files changed, 60 insertions(+), 5 deletions(-) create mode 100644 content/faq/how-does-sbomify-count-vulnerabilities.md diff --git a/content/faq/how-do-i-use-vex.md b/content/faq/how-do-i-use-vex.md index 8451234..6167cf1 100644 --- a/content/faq/how-do-i-use-vex.md +++ b/content/faq/how-do-i-use-vex.md @@ -1,8 +1,8 @@ --- title: "How do I use VEX with sbomify?" description: "Learn how Vulnerability Exploitability eXchange (VEX) lets you communicate which vulnerabilities actually affect your product, and how to upload, triage, and distribute VEX documents through sbomify." -answer: "A VEX document tells consumers which vulnerabilities in your SBOM are actually exploitable in your product and which are not. sbomify ingests CycloneDX VEX, OpenVEX, and CSAF 2.0 VEX, applies your statements to OSV and Dependency Track findings so noise is suppressed, and publishes the VEX alongside your SBOMs in your Trust Center. You can also triage vulnerabilities directly in sbomify and generate a VEX from your decisions." -tldr: "VEX is the companion to your SBOM that says \"this CVE is in our dependency tree but it does not actually affect our product, here is why.\" sbomify accepts VEX in CycloneDX, OpenVEX, and CSAF 2.0 formats, suppresses VEX'd findings in your vulnerability results, flags CISA KEV entries, and shares VEX next to SBOMs in the Trust Center." +answer: "A VEX document tells consumers which vulnerabilities in your SBOM are actually exploitable in your product and which are not. sbomify ingests CycloneDX VEX, OpenVEX, and CSAF 2.0 VEX, applies your statements to OSV and Dependency Track findings so noise is suppressed, and publishes the VEX alongside your SBOMs in your Trust Center. You can also triage vulnerabilities directly in sbomify, generate a VEX from your decisions, and have sbomify flag statements that have gone stale or High and Critical findings that no statement covers." +tldr: "VEX is the companion to your SBOM that says \"this CVE is in our dependency tree but it does not actually affect our product, here is why.\" sbomify accepts VEX in CycloneDX, OpenVEX, and CSAF 2.0 formats, suppresses VEX'd findings in your vulnerability results, flags CISA KEV entries, shares VEX next to SBOMs in the Trust Center, and runs scheduled drift detection so stale statements and uncovered High/Critical findings do not go unnoticed." weight: 67 keywords: [VEX, CycloneDX VEX, OpenVEX, CSAF VEX, vulnerability exploitability, SBOM VEX, vulnerability triage, CISA KEV, false positive, CRA VEX] url: /faq/how-do-i-use-vex/ @@ -133,10 +133,21 @@ You do not have to author VEX by hand or in an external tool. sbomify has an in- - **In-app triage.** Review scanner findings on the vulnerability dashboard, record `not_affected` decisions with justifications, apply bulk decisions across CVEs, and preview the effect with a dry run before committing. - **CISA KEV flags.** Findings that appear in the CISA Known Exploited Vulnerabilities catalog are flagged so you triage the vulnerabilities that attackers actually use first. - **Self-VEX generation.** sbomify generates a CycloneDX VEX from your triage decisions, complete with CISA tracking fields (serial number and statement timestamps), so your published VEX always matches your ledger. -- **Dependency Track sync.** If Dependency Track is your triage system of record, sbomify syncs your DT analysis decisions in as VEX and pins them to the matching releases. +- **Dependency Track sync.** If Dependency Track is your triage system of record, opt in and sbomify syncs your DT analysis decisions in as VEX, pinning them to the matching releases so you do not triage the same finding twice. Alternatively, keep a source-controlled `vex/` directory in the same repo that produces the SBOM, merge the per-CVE statements in CI, and upload the result alongside the SBOM. Pull requests on `vex/` carry the audit trail. +## Keeping your statements current + +A VEX statement is a claim about a specific version of your product, and claims expire. The vulnerable code path you ruled unreachable last quarter may be reachable after a refactor, and a new release can pull in High or Critical findings that no existing statement covers. Left alone, a stale `not_affected` is worse than no VEX at all: it tells your customers you have assessed something you have not. + +sbomify checks for this on a schedule and tells you when your VEX has drifted away from reality: + +- **Stale statements.** Statements that no longer match the findings on your current release are surfaced rather than silently carried forward. +- **Uncovered High and Critical findings.** New findings at High or Critical severity with no VEX statement covering them are flagged, so the gap between "scanned" and "assessed" does not quietly widen between releases. + +This runs without configuration. The point is that VEX becomes something you can rely on for audit and customer questions, instead of a document that was accurate on the day it was written. + ## Signing your VEX A VEX is a security-relevant claim about your product. Sign it with the same machinery you use to [sign your SBOM](/faq/how-do-i-sign-an-sbom/) - typically `actions/attest-build-provenance` against the VEX file path - so consumers can verify the VEX came from your CI pipeline and was not modified in transit. Without a signature, a VEX is only as trustworthy as the channel that delivered it. diff --git a/content/faq/how-does-sbomify-count-vulnerabilities.md b/content/faq/how-does-sbomify-count-vulnerabilities.md new file mode 100644 index 0000000..c01d5a3 --- /dev/null +++ b/content/faq/how-does-sbomify-count-vulnerabilities.md @@ -0,0 +1,43 @@ +--- +title: "How does sbomify count vulnerabilities?" +description: "sbomify counts vulnerabilities against your current posture - the latest artifact per component and format - not by summing findings across every SBOM version you have ever uploaded." +answer: "Vulnerability counts in sbomify reflect your current posture: the findings present in the latest artifact for each component and format, with VEX-suppressed findings excluded. They are not a running total across every historical SBOM version. If your counts dropped noticeably after upgrading to v26.7.1, that is the fix for exactly this behaviour landing - the earlier numbers were inflated by superseded SBOM versions." +tldr: "Counts reflect your current posture, not the sum of every SBOM you have ever uploaded. Fixing a vulnerability and uploading a new SBOM makes the count go down. If your totals dropped after v26.7.1, the old numbers were counting superseded versions." +weight: 69 +keywords: [vulnerability count, vulnerability dashboard, current posture, historical SBOM versions, count dropped, vulnerability totals, VEX suppression] +url: /faq/how-does-sbomify-count-vulnerabilities/ +--- + +## The short answer + +Counts reflect **current posture**: the findings present in the latest artifact for each component and format, after VEX statements are applied. They are not a cumulative total of everything ever scanned. + +This is the behaviour you want, because it means the number responds to your work. Fix a vulnerability, upload a new SBOM, and the count goes down. + +## Why your count may have dropped + +If you have been using sbomify for a while and your totals fell noticeably around v26.7.1, nothing broke and nothing was fixed in your software. The counts were previously aggregated across **every historical SBOM version** for a component rather than the current one. + +The practical effect was a number that could only ever go up. Upload ten iterations of a component over six months, remediate along the way, and findings from all ten versions were still counted, including ones you had already fixed and superseded. + +That is now corrected, so expect the totals to drop, in many cases substantially. The new number is the honest one. + +## What is included in a count + +- **The latest artifact per component and format.** A CycloneDX SBOM and an SPDX SBOM for the same component are both current; version 3 of that CycloneDX SBOM supersedes versions 1 and 2. +- **Findings from your enabled scanners**, whether that is the built-in OSV scanning or [Dependency Track](/faq/how-do-i-enable-vulnerability-scanning/). +- **Minus anything covered by VEX.** Findings you have marked `not_affected` are suppressed, so the dashboard shows triaged exposure rather than raw scanner output. See [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/). + +Skipped assessments are reported as skipped rather than counted as problems, so a scan that could not run does not inflate or deflate your posture. + +## Release-scoped counts + +A release pins specific artifacts, so a release's vulnerability posture is calculated against the artifacts pinned to it rather than whatever is newest on the component. This is deliberate: a release you shipped six months ago should report the posture of what you actually shipped, not of your current `main`. + +That release posture is what your customers see on the public [Trust Center](/features/trust-center/) release page. + +## Further reading + +- [How do I enable vulnerability scanning?](/faq/how-do-i-enable-vulnerability-scanning/) - where the findings come from +- [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/) - suppressing findings that do not affect you +- [How do I create a software release?](/faq/how-do-i-create-a-software-release/) - how artifacts get pinned to a release diff --git a/content/faq/what-is-a-cbom.md b/content/faq/what-is-a-cbom.md index e7c2778..6a131a4 100644 --- a/content/faq/what-is-a-cbom.md +++ b/content/faq/what-is-a-cbom.md @@ -2,7 +2,7 @@ title: "What is a CBOM and how does sbomify support it?" description: "A Cryptography Bill of Materials (CBOM) inventories the cryptographic assets in your software. sbomify auto-detects CBOMs, builds a crypto inventory, and assesses post-quantum readiness." answer: "A CBOM (Cryptography Bill of Materials) is a CycloneDX BOM that inventories cryptographic assets: algorithms, keys, certificates, and protocols. sbomify auto-detects CBOM content on upload, renders a crypto-asset inventory, runs a post-quantum cryptography (PQC) readiness assessment against NIST guidance, and publishes CBOMs on your public release pages next to your SBOMs." -tldr: "A CBOM is the cryptographic sibling of an SBOM: it lists the algorithms, keys, certificates, and protocols your software uses. sbomify ingests and auto-classifies CBOMs, shows a crypto inventory with a post-quantum readiness view, and shares them through your Trust Center." +tldr: "A CBOM is the cryptographic sibling of an SBOM: it lists the algorithms, keys, certificates, and protocols your software uses. sbomify ingests and auto-classifies CBOMs from any generator, normalizes them against the CycloneDX 1.7 crypto registry, shows a crypto inventory with a post-quantum readiness view, and shares them through your Trust Center." weight: 68 keywords: [CBOM, Cryptography Bill of Materials, crypto inventory, post-quantum cryptography, PQC readiness, quantum-safe, CycloneDX CBOM] url: /faq/what-is-a-cbom/ @@ -16,9 +16,10 @@ That question is becoming urgent. Migrating to post-quantum cryptography starts ## What sbomify does with CBOMs -- **Auto-detection.** Upload a CycloneDX document containing cryptographic assets and sbomify automatically classifies it as a CBOM, no special flag needed. You can also be explicit with `BOM_TYPE: cbom` in [sbomify-action](https://github.com/sbomify/sbomify-action), which uploads the document verbatim. +- **Auto-detection, whatever produced it.** Upload a CycloneDX document containing cryptographic assets and sbomify automatically classifies it as a CBOM, no special flag needed. Every CBOM lineage is ingested, and assets are normalized against the CycloneDX 1.7 cryptographic registry, so output from different generators lands in the same shape instead of depending on which tool you happened to use. You can also be explicit with `BOM_TYPE: cbom` in [sbomify-action](https://github.com/sbomify/sbomify-action), which uploads the document verbatim. - **Crypto-asset inventory.** The document detail page renders an inventory of the cryptographic assets found: algorithms, key sizes, certificates, and protocols. - **Post-quantum readiness.** The PQC readiness assessment plugin classifies each asset against NIST guidance and gives your component a post-quantum posture view, so you can see at a glance which algorithms are quantum-vulnerable and where. +- **Workspace-level crypto posture.** Your workspace dashboard summarizes crypto posture alongside your other artifacts, so post-quantum readiness is visible across the estate rather than one component at a time. - **Trust Center distribution.** CBOMs appear on your public release pages next to SBOMs and VEX, with the same access controls, and are exposed through the [Transparency Exchange API](/faq/how-do-i-enable-tea-in-sbomify/) as a supported artifact type. ## How do I generate a CBOM? From 5f00103cb165b4a42e1b0a6e1062a7e01a6eec5a Mon Sep 17 00:00:00 2001 From: Cyborg Viktor <307551610+vpetersson-bot@users.noreply.github.com> Date: Thu, 30 Jul 2026 11:30:00 +0000 Subject: [PATCH 4/4] ci: install d2 from a pinned release instead of piping install.sh Hugo Build Check has been failing on every branch since ~10:45 today, including master, with: install: cannot create regular file '/usr/local/share/man/man1/d2.1': Permission denied make: *** [Makefile:11: install] Error 1 The `Install d2` step pipes https://d2lang.com/install.sh into sh. That script runs `make install`, which installs a man page into /usr/local/share/man/man1 -- a path the GitHub runner user cannot write. Nothing in this repository changed to cause it; two branches that ran before 10:45 passed with identical workflow files, and master fails the same way without any of this branch's content. Download the pinned release tarball and install just the binary into ~/.local/bin, added to GITHUB_PATH. No make, no man page, no sudo. The version and a sha256 of the artifact are pinned, so the step also stops depending on whatever an unversioned remote script does next -- relevant for a repo running Scorecard. Applied to all three occurrences: lint.yml (lint, hugo-build) and deploy.yml (deploy). Verified: both workflows parse, and the step was dry-run end to end locally -- checksum verifies and `d2 --version` reports v0.7.1 with no elevated permissions. --- .github/workflows/deploy.yml | 18 +++++++++++++++++- .github/workflows/lint.yml | 36 ++++++++++++++++++++++++++++++++++-- 2 files changed, 51 insertions(+), 3 deletions(-) diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml index b02690e..c81ae81 100644 --- a/.github/workflows/deploy.yml +++ b/.github/workflows/deploy.yml @@ -34,7 +34,23 @@ jobs: bun-version: latest - name: Install d2 - run: curl -fsSL https://d2lang.com/install.sh | sh -s -- + env: + # Pinned: the upstream install.sh runs `make install`, which writes a + # man page into /usr/local/share/man/man1 and fails on GitHub runners + # with "Permission denied". Installing the binary directly avoids that, + # and pins the version instead of piping an unversioned script to sh. + D2_VERSION: 0.7.1 + D2_SHA256: eb172adf59f38d1e5a70ab177591356754ffaf9bebb84e0ca8b767dfb421dad7 + run: | + curl -fsSL -o d2.tar.gz \ + "https://github.com/terrastruct/d2/releases/download/v${D2_VERSION}/d2-v${D2_VERSION}-linux-amd64.tar.gz" + echo "${D2_SHA256} d2.tar.gz" | sha256sum -c - + tar -xzf d2.tar.gz + mkdir -p "${HOME}/.local/bin" + install -m 0755 "d2-v${D2_VERSION}/bin/d2" "${HOME}/.local/bin/d2" + echo "${HOME}/.local/bin" >> "${GITHUB_PATH}" + rm -rf d2.tar.gz "d2-v${D2_VERSION}" + "${HOME}/.local/bin/d2" --version - name: Cache Bun dependencies uses: actions/cache@v4 diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index 66b1b9b..f9c2741 100644 --- a/.github/workflows/lint.yml +++ b/.github/workflows/lint.yml @@ -46,7 +46,23 @@ jobs: run: bun install - name: Install d2 - run: curl -fsSL https://d2lang.com/install.sh | sh -s -- + env: + # Pinned: the upstream install.sh runs `make install`, which writes a + # man page into /usr/local/share/man/man1 and fails on GitHub runners + # with "Permission denied". Installing the binary directly avoids that, + # and pins the version instead of piping an unversioned script to sh. + D2_VERSION: 0.7.1 + D2_SHA256: eb172adf59f38d1e5a70ab177591356754ffaf9bebb84e0ca8b767dfb421dad7 + run: | + curl -fsSL -o d2.tar.gz \ + "https://github.com/terrastruct/d2/releases/download/v${D2_VERSION}/d2-v${D2_VERSION}-linux-amd64.tar.gz" + echo "${D2_SHA256} d2.tar.gz" | sha256sum -c - + tar -xzf d2.tar.gz + mkdir -p "${HOME}/.local/bin" + install -m 0755 "d2-v${D2_VERSION}/bin/d2" "${HOME}/.local/bin/d2" + echo "${HOME}/.local/bin" >> "${GITHUB_PATH}" + rm -rf d2.tar.gz "d2-v${D2_VERSION}" + "${HOME}/.local/bin/d2" --version - name: Run linters run: bun run lint @@ -72,7 +88,23 @@ jobs: bun-version: latest - name: Install d2 - run: curl -fsSL https://d2lang.com/install.sh | sh -s -- + env: + # Pinned: the upstream install.sh runs `make install`, which writes a + # man page into /usr/local/share/man/man1 and fails on GitHub runners + # with "Permission denied". Installing the binary directly avoids that, + # and pins the version instead of piping an unversioned script to sh. + D2_VERSION: 0.7.1 + D2_SHA256: eb172adf59f38d1e5a70ab177591356754ffaf9bebb84e0ca8b767dfb421dad7 + run: | + curl -fsSL -o d2.tar.gz \ + "https://github.com/terrastruct/d2/releases/download/v${D2_VERSION}/d2-v${D2_VERSION}-linux-amd64.tar.gz" + echo "${D2_SHA256} d2.tar.gz" | sha256sum -c - + tar -xzf d2.tar.gz + mkdir -p "${HOME}/.local/bin" + install -m 0755 "d2-v${D2_VERSION}/bin/d2" "${HOME}/.local/bin/d2" + echo "${HOME}/.local/bin" >> "${GITHUB_PATH}" + rm -rf d2.tar.gz "d2-v${D2_VERSION}" + "${HOME}/.local/bin/d2" --version - name: Cache Bun dependencies uses: actions/cache@v4