Add Part 4: VEX in the SBOM with SPDX 3.0 by vpetersson · Pull Request #84 · sbomify/sbomify.com

vpetersson · 2026-05-05T12:56:38Z

Summary

Adds Part 4 of the Yocto SBOM series: VEX in the SBOM: How Yocto Embeds Vulnerability Assessments with SPDX 3.0 — traces CVE_STATUS recipe metadata into SPDX 3.0 VEX relationship elements, plus the kernel-specific tooling that cuts CVE false positives by 70-80%.
Updates Parts 1, 2, and 3 series footers to link to Part 4.

Stacked on #83 (Part 3). Merge order: #81 → #82 → #83 → this.

Test plan

Visit /2026/05/26/yocto-vex-spdx-3-0/ — confirm post renders, including code blocks and tables
Visit Parts 1, 2, 3 — confirm series footer Part 4 entry is now a real link
Confirm Hugo build succeeds (hugo --buildFuture)

🤖 Generated with Claude Code

Covers the architectural leap to JSON-LD output, single-document merging, first-class Build elements with hasInput/hasOutput, the profile-based architecture, native VEX support, and the new build provenance features (build variables, nested builds, agent tracking, build host linking, package supplier). Updates Parts 1 and 2 series footers to link to Part 3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Traces how vulnerability information flows from Yocto's CVE_STATUS recipe metadata, patch file scanning, and upstream version checks into SPDX 3.0 VEX relationship elements (VexFixedVulnAssessmentRelationship, VexAffectedVulnAssessmentRelationship, VexNotAffectedVulnAssessment- Relationship). Documents the kernel-specific tooling that cuts CVE false positives by 70-80% by cross-referencing the kernel CNA database with compiled source files. Updates Parts 1, 2, and 3 series footers to link to Part 4. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

JPEWdev

This one needs a few changes; I'll try to remember to make them but ping me if it's getting close to time to publish

JPEWdev · 2026-05-14T02:47:31Z

+  "to": ["urn:spdx:...:package-ncurses"],
+  "relationshipType": "fixedIn",
+  "security_assessedElement": "urn:spdx:...:package-ncurses"
+}


Pretty sure claude copied this from the SPDX documentation, but it's wrong. When I have a little more time, I'll see if I can dig up a better example.

Reverted my prose substitute — the original JSON example is back in place. Will swap it in once you've dug up the corrected example.

@JPEWdev sorry about that comment. That's all Claude. I didn't even see it until now.

Replaced the JSON snippet with a prose summary in 618b764 so we are not shipping a wrong example. Happy to swap a verified JSON example back in whenever you have one to share.

JPEWdev · 2026-05-14T02:51:20Z

+With SPDX 3.0, vulnerability assessments are first-class citizens in the SBOM. The security profile provides typed elements for vulnerabilities and VEX relationships, and the Yocto implementation populates these automatically from the same `CVE_STATUS` data that `cve-check` uses. The result is a single document that answers both "what is in my image?" and "which CVEs affect it, and what is their status?"
+
+For teams subject to regulatory requirements like the [EU Cyber Resilience Act](/compliance/eu-cra/), having integrated VEX data in the SBOM significantly simplifies compliance workflows.
+


Need to add a note about some of the changes in Yocto 6.0, namely:

cve_check.bbclass is removed (but the CVE_* variables remain and are still used by the SPDX class

sbom-cve-check is now used to do CVE checking in the Yocto project by running scans against SBoMs

Reverted my prose for this — rather have you write the Yocto 6.0 section in your voice on your own post. Happy to drop in your text verbatim when you have it.

Added a "Yocto 6.0 (Wrynose)" section in 618b764 covering both points: cve_check.bbclass is gone but the CVE_* variables remain (still consumed by the SPDX class), and CVE scanning has moved to sbom-cve-check running against the SBOM itself. Please let me know if anything in the wording needs adjusting.

- Replace the inaccurate VEX/Vulnerability JSON examples (flagged as wrong) with a prose summary of what shows up in the SPDX 3.0 document. - Add a section on Yocto 6.0 (Wrynose): cve_check.bbclass is removed (CVE_* vars remain) and CVE scanning has moved to sbom-cve-check, which runs against the SBOM itself. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

This reverts commit b72db62.

Re-applies the substance of b72db62 (which was reverted in 212a59c so a prior session could punt the work back to Joshua via PR comment). - Replace the SPDX 3.0 VEX/Vulnerability JSON snippets (flagged as inaccurate copies of the SPDX docs) with a prose summary of what appears in the document. Until a verified example is available, prose is safer than publishing a wrong JSON. - Add a "Yocto 6.0 (Wrynose)" note covering the two changes Joshua raised: cve_check.bbclass has been removed (CVE_* variables remain and are still consumed by the SPDX class), and CVE scanning has moved to sbom-cve-check, which runs against the SBOM itself. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Hugo 0.162.0 (released 2026-05-26) changed the default `security.allowContent` policy from `['.*']` to `['! ^text/html$']`, which rejects raw HTML content files. Our homepage lives in `content/_index.html`, so the Hugo build started failing on every branch as soon as today's CI runs picked up the new Hugo. This restores the prior permissive default. Also fixes the nightly `Deploy Production` job on master, which has been failing for the same reason today. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

JPEWdev

Other than the one line hallunciation, this looks good to me. Feel free to submit without waiting for another review after that line is removed

JPEWdev · 2026-05-28T01:31:07Z

@@ -0,0 +1,129 @@
+---


I'm assuming this is the same as in PR #83 so I'm going to ignore it?

Correct, please ignore. This PR is stacked on #83, so the Part 3 file shows up in the diff but the only change here is the series footer swapping "Part 4 (coming soon)" for a real link to the new Part 4 post. All substantive Part 3 review belongs on #83.

JPEWdev · 2026-05-28T01:32:16Z

+**`CVE_STATUS`** — A per-CVE variable flag that records the status of individual CVEs for a recipe. Each flag entry encodes a status mapping, a detail string, and an optional description:
+
+```bash
+CVE_STATUS[CVE-2023-50495] = "backported-patch: Fix applied in our layer"


This line is an hallucination; backported-patch is not a status. Just remove it.

Removed in 80488a7 — left the not-applicable-config line as the single example.

Joshua flagged the `CVE_STATUS[CVE-2023-50495] = "backported-patch: ..."` example as not a real status. Removing it leaves the `not-applicable-config` example, which is valid. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Viktor Petersson and others added 2 commits May 5, 2026 12:55

vpetersson mentioned this pull request May 5, 2026

Add Part 5: Yocto SBOM in production #85

Open

4 tasks

content(blog): fix broken CRA link in Yocto SBOM deep-dive Part 4

2725410

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

JPEWdev suggested changes May 14, 2026

View reviewed changes

vpetersson changed the base branch from yocto-sbom-part-3 to master May 14, 2026 08:12

vpetersson and others added 3 commits May 14, 2026 08:25

Revert "content: apply Joshua's review feedback on Part 4"

212a59c

This reverts commit b72db62.

JPEWdev suggested changes May 28, 2026

View reviewed changes

		With SPDX 3.0, vulnerability assessments are first-class citizens in the SBOM. The security profile provides typed elements for vulnerabilities and VEX relationships, and the Yocto implementation populates these automatically from the same `CVE_STATUS` data that `cve-check` uses. The result is a single document that answers both "what is in my image?" and "which CVEs affect it, and what is their status?"

		For teams subject to regulatory requirements like the [EU Cyber Resilience Act](/compliance/eu-cra/), having integrated VEX data in the SBOM significantly simplifies compliance workflows.

Conversation

vpetersson commented May 5, 2026

Summary

Test plan

Uh oh!

JPEWdev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JPEWdev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants