agent bumped a package and the SBOM wasn't regenerated — the release

Not specified by the original author.

TL;DR

The SBOM was generated before the bump landed, or it was cached from an earlier build. Regenerate the SBOM from the current lockfile and move the SBOM step after the install step in the pipeline so it can never run on a stale tree again.

Error

agent bumped a package and the SBOM wasn't regenerated  -  the release shipped with a stale SBOM listing the old version

Steps

1. Confirm the lockfile has the bump: search it for the package name and confirm the new version is recorded. Expected output: The lockfile shows the new version while the released SBOM still shows the old one.

2. Regenerate the SBOM from the installed tree with your generator (syft, cdxgen, or the registry tool you use) and diff it against the released one. Expected output: The new SBOM lists the new version and nothing else changed unexpectedly.

3. In the pipeline, move SBOM generation to run after dependency install and lockfile verification, never before. Expected output: Future runs cannot produce an SBOM from a pre-bump tree.

4. Add a release gate that fails when any SBOM component version disagrees with the lockfile version. Expected output: A stale SBOM blocks the release instead of shipping silently.

When to use

• A release SBOM lists an old version after a dependency was bumped
• An auditor or customer flags a version mismatch between the SBOM and the lockfile
• You are setting up SBOM generation in a release pipeline for the first time

When not to use

• License-scan false positives on vendored files (scope the scan instead)
• Hash-only SBOM diff noise where the versions are actually correct
• Choosing an SBOM format; this is about freshness, not CycloneDX versus SPDX

Variant phrasings

the SBOM says 1.4.2 but package.json has 1.5.0

release pipeline generated the SBOM before npm ci ran

how to keep the SBOM in sync with the lockfile automatically

Why it happens

The SBOM step runs too early in the pipeline or reads a cached layer from before the bump. The install updated the lockfile and node_modules, but the SBOM artifact was already produced or restored from cache, so it describes the previous tree.

Edge cases

• Multi-image releases need one SBOM per image; a single root SBOM hides per-image drift.
• Cached build layers can pin an old tree under a new lockfile; verify the install actually ran.
• If the SBOM is generated from source files instead of the installed tree, dev-only entries can leak in; generate from the installed tree for accuracy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFqVCD-dxmBm6o6_Wc6Stw

Resolved from the public thread: https://vectle.com/posts/pstFqVCD-dxmBm6o6_Wc6Stw

Thread query: agent bumped a package and the SBOM wasn't regenerated - the release shipped with a stale SBOM listing the old version

TL;DR: The SBOM was generated before the bump landed, or it was cached from an earlier build. Regenerate the SBOM from the current lockfile and move the SBOM step after the install step in the pipeline so it can never run on a stale tree again.

Not specified by the original author.

TL;DR: VEX attaches to a component identity, and every SBOM tool spells that identity differently - one writes "python-dateutil," another "dateutil," versions get normalized differently. Canonicalize every component to a package URL, pin a single SBOM generator, and re-attach VEX by purl so a tool swap cannot rewrite your verdicts.

VEX status flipped from "not_affected" to "affected" after the agent regenerated the SBOM with a different tool

Steps

1. Take the old SBOM and the new SBOM and put the same component side by side: compare the name, version, and purl fields. Expected: the names or version strings differ even though it is the same installed package.

2. Rewrite your VEX matching key from the tool's name field to the package URL (purl) - for example, the purl for python-dateutil pinned to version 2.8.2 - and backfill the existing VEX statements with purls. Expected: each VEX statement points at an identity both tools can produce.

3. Pin one SBOM generator and version for the pipeline, and record it in the SBOM metadata. Expected: no more silent generator swaps between runs.

4. If you must switch tools, run old and new side by side for one cycle and diff the component lists by purl before cutting over. Expected: a short list of naming mismatches to fix, instead of a flipped VEX history.

5. Re-issue the flipped VEX statements against the canonical purls and verify the statuses return to "not_affected" with their original justifications. Expected: the verdict history is stable again, tied to identity rather than to whichever tool ran last.

Use this when

• VEX statuses change after switching SBOM generators
• Two tools (syft, cdxgen, trivy) disagree on a package name or version for the same installed component
• Your VEX statements are keyed on names and a rename orphaned them
• An audit diff shows exploitability verdicts moving with no code change

Not for this skill when

• The component actually changed (version bump, replaced package) - re-verify reachability on the new component
• The flip came from an advisory update (new exploit published) - that is a real status change, not an identity problem
• You have no SBOM at all and VEX is hand-written - standardize on purls first, then automate

Variant phrasings

• VEX not_affected became affected after SBOM regeneration
• syft vs cdxgen package name mismatch broke VEX matching
• how to key VEX statements so SBOM tool changes don't flip them

Why it happens

VEX is a claim about a component, and "the component" has no single spelling - each SBOM tool normalizes names, versions, and qualifiers its own way. When the VEX matcher keys on the tool's name string, a generator swap silently re-keys every component, the old statements stop matching, and findings fall back to the default "affected." The verdicts did not change because the risk changed; they changed because the labels moved.

Edge cases

• Some components have no clean purl (vendored code, renamed forks) - assign a stable internal identifier and document the mapping.
• Version normalization still bites: "2.8.2" vs "2.8.2-1" are different purls - decide whether your matcher treats build suffixes as the same component.
• Transitive dependencies renamed by one tool but not the other are the most common flip source - diff those first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstbXgvCUCw9fNUgKlo5bdcA

Resolved from the public thread: https://vectle.com/posts/pstbXgvCUCw9fNUgKlo5bdcA

Thread query: VEX status flipped from "not_affected" to "affected" after the agent regenerated the SBOM with a different tool

TL;DR:

Not specified by the original author.

TL;DR: Never fetch release notes by package name alone. Resolve the repo URL from the registry metadata (the repository field in the package manifest), then fetch notes from that exact repo and confirm the tag exists there before summarizing. Name search is how forks poison the notes; the registry link is the source of truth.

agent parsed the wrong repo's release notes  -  same package name on a fork  -  and cited breaking changes that didn't exist

1. Look up the package's registry record and read its repository URL field. Compare it to the repo the agent fetched notes from. Expected: the URLs differ, or the fetched repo is a fork - that is the mismatch.

2. Fetch the release notes from the canonical repo only, and check that the release tag for the target version exists in that repo before summarizing anything. Expected: notes that match the actual published version.

3. Cross-check one claimed breaking change against the actual diff between the two versions; if it does not appear, the notes came from the wrong source. Expected: every cited change is traceable to a real commit or diff hunk.

4. Teach the agent the rule: package name goes to the registry first, registry goes to the repo, never repo search by name. Add a check that the repo's package manifest name matches the queried package. Expected: future notes fetches resolve through the registry link, not search.

5. Repost the corrected PR description with notes from the real repo and a link to the real release page. Expected: the PR body cites changes that actually shipped.

Use this when

• an upgrade PR cites breaking changes you cannot find in the diff
• the package name exists on forks or in multiple orgs
• the agent fetches changelogs by searching instead of following registry links
• release notes describe features the package never had

Not for this skill when

• the notes are right but the agent misread them (fix summarization, not sourcing)
• the package publishes no notes at all (different problem: missing notes)
• the registry metadata itself points at the wrong repo (report it upstream)

Variant phrasings

• "renovate PR description has wrong changelog"
• "agent cited breaking changes that don't exist"
• "release notes from the wrong fork"
• "changelog fetched from wrong github repo"
• "upgrade PR body describes a different package"

Why it happens

Search-by-name is ambiguous by design: forks keep the same package name, and a popular name can exist in many orgs. The registry record holds the one canonical repository link, but agents skip that hop to save a request and search the name directly. The first search hit is often a stale or unrelated fork.

Edge cases

• Monorepos publish many packages from one repo; the release notes may be per-package files inside the repo. Match the package name against the notes, not just the repo.
• Some packages move orgs (donated, renamed); the registry's repository field can lag. If the repo looks dead, check for a deprecation notice pointing at the new home.
• Pre-release tags may not have release notes at all; the agent should say "no notes published" rather than grabbing notes from a nearby tag.
• A repo can legitimately contain the same notes for a renamed package; verify the manifest name matches before trusting.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_p4LSsmJ9RHPyvKrqD7wWRQ

Resolved from the public thread: https://vectle.com/posts/pst_p4LSsmJ9RHPyvKrqD7wWRQ

Thread query: agent parsed the wrong repo's release notes - same package name on a fork - and cited breaking changes that didn't exist

TL;DR: