agent's scan diff flagged config changes as new vulnerabilities

Not specified by the original author.

TL;DR

A naive diff compares raw output rows, so any changed banner, patched version string, or reordered service makes the old row vanish and a new row appear, reported as a brand-new vulnerability. Diff on the stable identity of a finding, check, host, and location, and classify each difference as new, resolved, changed, or unchanged, with changed items shown as changes, never as fresh criticals.

agent's scan diff flagged config changes as new vulnerabilities

Use this when

• A scan diff lists new vulnerabilities that, on inspection, are the same services with updated versions or banners.
• Resolved counts and new counts are both implausibly high between two scans of the same authorized scope.

Not for this skill when

• The environment genuinely changed wholesale, such as a rebuilt server. A human should review that diff; classification rules assume continuity.
• The two scans used different tool versions or template sets. Note that as a diff caveat before blaming identity matching.

Steps

1. Take one flagged new item and find its counterpart in the earlier scan by hand, identifying what raw field changed, such as a version string in the evidence. Verify: Verify: the change is a field difference inside the same check and location, named explicitly.
2. Define the diff identity as check id plus host plus location, with evidence treated as an attribute that can change, and write the classification rules for new, resolved, and changed. Verify: Verify: the rules decide the hand-worked example as changed, not new.
3. Re-run the diff with those rules and compare category counts against the naive diff. Verify: Verify: new and resolved counts fall to plausible numbers and the changed category holds the rest.
4. Render changed items with a short what-changed note drawn from the differing fields, so a version bump reads as a version bump. Verify: Verify: a reader can see why each changed item was classified that way.
5. Add golden tests: a pair of small scan files with a known banner change, a true new finding, and a true resolution, asserting the diff classifies all three correctly. Verify: Verify: the tests pass and would fail under raw-row diffing.

Variant phrasings

scan diff version change flagged new vulnerability

The symptom phrasing.

diff findings by identity check host location classify changed

The design phrasing.

pentest scan comparison false new resolved counts inflated

The counts phrasing.

Compatibility: Compatibility: any agent diffing workflow over scanner exports; identity fields must be extracted identically from both scans.

Why it happens

Scanners describe the present, including incidental details like banners and build strings that change for innocent reasons, patching most of all. Row-level diffing cannot tell a changed description from a changed reality, so routine maintenance becomes a flood of new and resolved pairs. Identity-based diffing encodes what a finding is, separately from how it was described on the day.

Edge cases / pitfalls

• A version change can itself resolve or introduce a real vulnerability; classification as changed should trigger a re-evaluation of that finding, not a free pass.
• Tool or template updates between scans change descriptions en masse; pin tool versions per engagement or annotate the diff with the version change.
• Keep the naive counts out of client reports entirely once you have seen them mislead; publish only the classified diff.

Provenance

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

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

Thread query: agent's scan diff flagged config changes as new vulnerabilities

TL;DR: A naive diff compares raw output rows, so any changed banner, patched version string, or reordered service makes the old row vanish and a new row appear, reported as a brand-new vulnerability. Diff on the stable identity of a finding, check, host, and location, and classify each difference as new, resolved, changed, or unchanged, with changed items shown as changes, never as fresh criticals.

Not specified by the original author.

TL;DR

Kernel configs are generated artifacts with version-specific structure: new symbols appear, defaults flip, and the file header and ordering change, so a naive text diff or a strict parser melts down exactly when a kernel update happens. Parse the config into a symbol-to-value map (set, unset, module, built-in, string), compare maps semantically, and classify changes into expected-new-version noise (new symbols at defaults) versus meaningful changes (a previously set symbol removed or flipped). Report only the meaningful set, with the full map diff available as evidence.

agent's diff parser failed on kernel config changes

Use this when

• The agent errors out reading the new kernel config, or reports thousands of changed lines after a routine kernel update.
• The flagged changes are almost all new symbols or reordered entries.
• A symbol the fleet actually cares about (a filesystem, a security option) changing would be invisible in the flood.

Not for this skill when

• The config file is missing because the distro does not ship one in boot. Read the running config from proc config.gz or the package files instead.
• The comparison is between two hand-maintained configs for the same kernel. A plain diff is appropriate there.

Steps

1. Collect sample config pairs (previous and new kernel) from representative hosts and reproduce the parser failure or flood offline. Verify: the failure mode is reproduced with real files
2. Rewrite the comparison as a semantic map diff: parse each config into symbol states, ignoring comments, ordering, and header lines. Verify: identical-semantics files with different ordering produce an empty diff
3. Define meaningful change rules with the platform owner: a set symbol becoming unset or absent, a value flip on a watchlist of security and filesystem symbols, versus new symbols appearing at defaults. Verify: the rules are written down and the watchlist is explicit
4. Classify and re-run on the sample pairs. Verify: the output is a short list of meaningful changes with the noise summarized as counts
5. Wire the classifier into the wave post-checks and add the sample pairs as regression fixtures. Verify: the next kernel update produces a readable kernel-change note in the wave report

Variant phrasings

kernel config diff parser fails new version semantic diff

The main phrasing.

config symbol map compare built-in module unset

The implementation phrasing.

kernel update config changes noise vs meaningful watchlist

The triage phrasing.

Compatibility: Compatibility: Linux kernels shipping config in boot or via proc config.gz (IKCONFIG); symbol semantics are kconfig-standard across distros.

Why it happens

Kernel configuration is a database wearing a text file costume. Each release adds and occasionally removes symbols, and the generated file reflects the whole kconfig tree, not just your choices. Text-diff tooling measures the file; the agent needs to measure the choices. The semantic map approach also makes the watchlist idea possible: a handful of symbols (SELinux, filesystems, virtualization options) deserve human eyes when they change, and everything else deserves a count, not an alarm.

Edge cases / pitfalls

• A symbol that disappears entirely can mean a feature was removed or renamed and split; check the new symbol set for the successor before declaring a regression.
• Distros patch their kernels, so the same version number on two distros can have different symbol sets; keep fixtures per distro.
• The running config and the boot file can differ after a partial update; record which source each reading came from.

Provenance

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

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

Thread query: agent's diff parser failed on kernel config changes

TL;DR: Kernel configs are generated artifacts with version-specific structure: new symbols appear, defaults flip, and the file header and ordering change, so a naive text diff or a strict parser melts down exactly when a kernel update happens. Parse the config into a symbol-to-value map (set, unset, module, built-in, string), compare maps semantically, and classify changes into expected-new-version noise (new symbols at defaults) versus meaningful changes (a previously set symbol removed or flipped). Report only the meaningful set, with the full map diff available as evidence.

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: