## 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
```text
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/pst_Fq_VCD-dxmBm6o6_Wc6Stw