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

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: Verify the package version in the final runtime stage, not just the builder - the vulnerable copy is the one that ships. Bumping the version in the lockfile or builder stage changes nothing if the final stage installs its own copy or inherits an old base layer. Rebuild with a clean cache on the final stage and confirm the installed version inside the running image before closing the CVE.

rescan: CVE-2026-XXXXX still present in image (lockfile shows fixed version 1.2.4)

1. Inspect the installed version inside the final image: run the image and query the package manager (for example pip show [package] or the OS package list). Expected: you see the OLD vulnerable version, proving the runtime copy was never updated.
2. Find where the final stage gets the package: read the Dockerfile stages and check whether the final stage runs its own install, copies artifacts from the builder, or inherits the package from the base image. Expected: you identify the stage that actually places the vulnerable files.
3. Apply the bump in the right stage: update the base image tag, the final-stage install line, or the copy from the builder - whichever owns the runtime copy. Expected: the Dockerfile change touches the stage that ships.
4. Rebuild with a clean layer cache for the affected stages and re-scan. Expected: the rescan no longer reports the CVE.
5. Close the ticket only after the rescan of the rebuilt image is clean, not when the lockfile changes. Expected: ticket closure is gated on scanner evidence from the shipped artifact.

Use this when

• a rescan flags a CVE the patch supposedly fixed
• the lockfile and the image disagree on package versions
• multi-stage Dockerfiles separate build and runtime
• the scanner attributes the CVE to a specific layer or path

Not for this skill when

• the scanner flags a different CVE than the one patched
• the patch itself failed to apply anywhere
• the vulnerable package lives in a sidecar or base image you do not build
• the CVE is a scanner false positive on the fixed version

Variant phrasings

• CVE still flagged after upgrade
• patch bumped wrong stage docker build
• rescan shows old package version after fix
• fixed in builder but not in final image

Why it happens

Multi-stage builds separate build-time and runtime environments. The lockfile or builder stage gets the fixed version, but the final stage installs its own copy from a base image or an unpinned install line, so the shipped artifact still carries the vulnerable package while every source-side check looks clean.

Edge cases

• cached layers can resurrect the old package - a no-cache rebuild of the final stage is the real test
• distroless or minimal base images bundle the package where no package manager can see it - match the scanner's reported file path
• the CVE may be flagged against a second copy of the same library (system vs vendored) - fix the copy the scanner names
• base image bumps can reintroduce the old package later - the rescan gate must run on every build, not just the patch build

Provenance

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

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

Thread query: the agent marked a CVE fixed, but the rescan still flagged it - the patch bumped the wrong package in a multi-stage build

TL;DR: