agent's SBOM diff flagged 200 changes — all were hash-only and

Not specified by the original author.

TL;DR

Every rebuild re-hashes, so a naive SBOM diff reports 200 changes where nothing actually changed. Diff on name plus version (ignoring hashes), or use an SBOM diff tool that treats hash-only changes as noise.

Error

agent's SBOM diff flagged 200 changes  -  all were hash-only and the security review was noise

Steps

1. Confirm the noise: check whether the flagged entries differ only in hashes with names and versions unchanged. Expected output: The diff is hash churn, not real change.

2. Re-run the comparison keyed on package name and version only, treating hash differences as expected. Expected output: The diff shrinks to the real changes, possibly zero.

3. Switch the review tooling to an SBOM-aware diff that separates content changes from hash churn. Expected output: Future diffs report signal by default.

4. If hashes must be reviewed (tamper detection), separate that into its own check rather than the change-review diff. Expected output: Two clear signals: what changed, and whether artifacts match.

5. Tell the agent to summarize SBOM diffs by name and version, calling out hash-only entries as noise. Expected output: Reviews stay short and honest.

When to use

• An SBOM diff is dominated by hash-only changes
• Security review is drowning in noise from rebuilds
• You are choosing SBOM diff tooling

When not to use

• Diffs with real version changes; review those
• Hash mismatches against a trusted baseline; that is tamper detection
• First-time SBOM reviews; everything is new and that is fine

Variant phrasings

SBOM diff shows hundreds of hash-only changes

ignore hash churn in SBOM comparison

SBOM diff noise from rebuilds

Why it happens

Hashes cover the exact artifact bytes, and rebuilds, repackaging, or registry mirrors change bytes without changing the software. A byte-level diff therefore reports change on every rebuild, burying the version changes the review is actually for.

Edge cases

• A hash change with the same version can still mean a compromised artifact; keep tamper detection as a separate check.
• Reproducible builds eliminate the churn at the source; worth it if the noise is chronic.
• Some regulations require hash review; satisfy them with the dedicated check, not the change diff.

Provenance

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

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

Thread query: agent's SBOM diff flagged 200 changes - all were hash-only and the security review was noise

TL;DR: Every rebuild re-hashes, so a naive SBOM diff reports 200 changes where nothing actually changed. Diff on name plus version (ignoring hashes), or use an SBOM diff tool that treats hash-only changes as noise.

Not specified by the original author.

TL;DR: Almost none of those 2,300 are new - the base-image bump changed package version strings, so the dedup keys stopped matching and every old finding re-filed as new. Re-scan the old image digest, diff by CVE plus package identity, and triage only the true-new set.

the scanner reported 2,300 new findings overnight after a base-image bump - the agent couldn't tell which were real

Steps

1. Pin both sides by digest, not tag: record the old image digest (pre-bump) and the new digest. Expected: two immutable scan targets - tags move, digests do not.

2. Scan both digests with the same scanner version and the same vulnerability database. Expected: two finding lists computed under identical conditions.

3. Diff the lists on (CVE ID, package purl, installed version): findings present in both are carryover, findings only in the new scan are genuinely new. Expected: the "2,300 new" collapses to a small true-new set plus a large re-flagged set.

4. Bulk-close or bulk-carry the re-flagged findings back onto their original tickets, matching on the old CVE-plus-package key. Expected: the backlog returns to roughly its pre-bump size plus the true-new items.

5. Triage only the true-new set, prioritized by severity and KEV membership. Expected: the on-call reviews dozens of findings, not thousands.

6. Fix the pipeline: key findings on digest-pinned scans and stable package identity so the next base-image bump diffs instead of flooding. Expected: the next bump produces a diff report, not an alert storm.

Use this when

• Finding counts spike right after a base-image, distro, or major dependency bump
• The "new" findings carry CVE IDs you have seen before
• Dedup keys include version strings or tags that the bump changed
• Triage is blocked because nobody trusts the "new" label

Not for this skill when

• The findings are genuinely new (new CVE IDs, first-seen dates check out) - triage them normally
• Counts spike with no image or dependency change - look for a scanner or database update instead
• A single image shows 2,300 findings on its first-ever scan - that is a dirty base image, not a dedup problem

Variant phrasings

• trivy thousands of new vulnerabilities after base image update
• scanner re-reported all CVEs as new after image rebuild
• how to diff container scan results between image digests

Why it happens

Dedup keys are usually built from CVE ID plus package name plus version string plus image tag. A base-image bump changes the version strings (new distro package builds) and often the tag, so every key changes and every old finding looks new. The scanner did its job - it reported what it saw. The pipeline's identity function just could not recognize anything it had seen before.

Edge cases

• Some "re-flagged" findings genuinely changed severity (a new exploit published overnight) - re-score the carryover set, do not just bulk-close it.
• Distro package versioning (epochs, release suffixes) defeats naive string diffing - normalize with purls before diffing.
• If the old digest is no longer pullable, diff against your last stored SBOM for that digest instead of rescanning.

Provenance

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

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

Thread query: the scanner reported 2,300 new findings overnight after a base-image bump - the agent couldn't tell which were real

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: