FAQ: cover the v26.7.1 features - #117
Closed
vpetersson-bot wants to merge 1 commit into
Closed
Conversation
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.
Contributor
Author
|
Superseded by #118, which folds this together with the other two v26.7.1 site changes into a single PR. The commit is carried over unchanged (cherry-picked with |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Audited the FAQ against the v26.7.1 release notes. Most of the release was already covered — worth saying, since the interesting output of an audit is usually the short list.
Already accurate, no change needed:
cyclonedx_validator.py:59lists exactly 1.3–1.7 with matching shipped schemasThree gaps, now closed
1. Drift detection was documented nowhere
grep -rli "drift"returned nothing outside blog posts. This is a headline v26.7.1 capability and arguably the thing that makes VEX trustworthy rather than decorative, sohow-do-i-use-vex.mdgains a Keeping your statements current section covering stale statements and uncovered High/Critical findings.The framing is that a stale
not_affectedis worse than no VEX at all, because it tells a customer you have assessed something you have not.Also marked the Dependency-Track sync opt-in — the previous wording implied it was automatic.
2. CBOM ingestion breadth
what-is-a-cbom.mddescribed auto-detection but not that ingestion previously depended on which tool produced the CBOM. Now notes that every lineage ingests, that assets are normalized against the CycloneDX 1.7 crypto registry, and adds the new workspace-level crypto posture.3. New: How does sbomify count vulnerabilities? (weight 69)
Counts now reflect current posture instead of summing every historical SBOM version, so totals drop on upgrade. Without an explanation that reads like a bug, and it is the obvious support question this week. The page states plainly that nothing was fixed by the change and the new number is simply the honest one, then covers what a count includes, VEX suppression, and why release-scoped counts are pinned to the artifacts actually shipped.
Placed at weight 69, keeping it in the vulnerability cluster (scanning 65, VEX 66–67, CBOM 68) ahead of Trust Center at 70.
Verification
bun run lint:markdownclean; Hugo buildsNote: a site-wide link audit also turned up three pre-existing broken links unrelated to this change — those are in #116, kept separate.