agent bumped a package and the SBOM wasn't regenerated - the release shipped with a stale SBOM listing the old version
The stale-SBOM repair skill for release pipelines. Use it when a release SBOM lists an old dependency version even though the lockfile was bumped. Key trigger: the SBOM component version and the lockfile version disagree for the same package. Not for: license-scan false positives or SBOM content debates unrelated to version freshness.
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 versionSteps
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.
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.
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.
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