agent's SBOM omitted dev dependencies the scanner flagged: scope fix

Not specified by the original author.

agent's SBOM omitted dev dependencies the scanner flagged: scope fix

TL;DR

The SBOM generator excluded dev dependencies, but the scanner flags them (they ship in build containers), so the SBOM and the scanner disagreed. Include dev dependencies in the SBOM scope, or document exactly why a scope excludes them. An SBOM that omits what the scanner sees is incomplete.

agent's SBOM omitted dev dependencies the scanner flagged

Steps

1. Compare the SBOM component list against the scanner's findings. Expected: The omitted dev dependencies are identified.

2. Expand the SBOM generation scope to include dev dependencies. Expected: The SBOM covers them.

3. Regenerate and re-verify: the scanner's findings now appear in the SBOM. Expected: The two agree.

4. Document the SBOM scope explicitly: what is included and why. Expected: The scope is a decision, not an accident.

5. Align the generator and scanner configs so they cannot drift apart again. Expected: The scope stays consistent.

When to use

• SBOMs miss scanner-flagged components
• dev dependencies are excluded
• the SBOM feeds compliance

When not to use

• dev dependencies genuinely never ship (then document the exclusion)
• the scanner is wrong about the component (verify manually)
• the SBOM is for a different artifact than the scanner checked

Tool compatibility

• any SBOM generator
• dependency scanners

Variant phrasings

• "SBOM omitted dev dependencies"
• "SBOM scope scanner mismatch"
• "SBOM incomplete dev deps"

Why it happens

SBOM generators default to production scopes, but scanners see the whole tree including dev dependencies that end up in build images. The two tools answered different questions, and the SBOM (the compliance artifact) was the narrower one. Scope is a decision that must be made once, explicitly, and shared by both tools.

Edge cases

• the scope decision belongs in the build config, not in tribal knowledge
• some dev dependencies genuinely do not ship; the exclusion list needs reasons
• regeneration must be part of the release pipeline, not a manual step

Provenance

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

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

Thread query: agent's SBOM omitted dev dependencies the scanner flagged: scope fix

TL;DR: The SBOM generator excluded dev dependencies, but the scanner flags them (they ship in build containers), so the SBOM and the scanner disagreed. Include dev dependencies in the SBOM scope, or document exactly why a scope excludes them. An SBOM that omits what the scanner sees is incomplete.

Not specified by the original author.

TL;DR

The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.

the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

Use this when

• A "fix" merged but the rescan still flags the same CVE.
• The PR diff shows a devDependency change for a finding reported against dependencies.
• Package names are similar across scopes and the agent picked the wrong one.

Not for this skill when

• The finding is genuinely in a devDependency (some scanners flag those). Then the bump was right and the rescan config is the problem.
• The version bump failed to resolve. That is a dependency-resolution problem.

Steps

1. Revert the devDependency bump; it was unrelated to the finding. Verify: the diff is clean and unrelated tests still pass.
2. Read the scanner output for the exact package path: which manifest, which section, which version is installed. Verify: you can point to the line in package.json (or equivalent) the scanner means.
3. Bump the correct entry to the fixed version. Verify: the lockfile shows the production dependency at the fixed version.
4. Rescan and confirm the finding is gone. Verify: the specific CVE no longer appears for that package path.
5. Add the gate: a security PR must reference the finding ID and CI must show that finding cleared on rescan before merge. Verify: a PR that bumps the wrong scope fails the gate.

Variant phrasings

bumped devDependency instead of dependency

The short phrasing.

npm audit fix wrong dependency

The tool-specific search.

fix PR wrong scope scanner still flags

The symptom phrasing.

Compatibility: npm, pip, cargo, Go modules; every ecosystem has scope concepts (dev vs prod) that agents confuse.

Why it happens

The agent matched on package name, not on the scanner's package path. Similar names across scopes (foo in dependencies vs foo in devDependencies, or a similarly named transitive dep) made the name match ambiguous, and the agent edited the first match instead of the exact one the scanner reported.

Edge cases / pitfalls

• Monorepos multiply this: the same package name can appear in several workspace manifests. The scanner's file path is the disambiguator; always use it.
• If the vulnerable package is transitive, bumping the direct devDependency does nothing; the fix is overriding or bumping the direct dependency that pulls it in.
• Some findings need the lockfile regenerated, not just the manifest edited; verify the installed version, not just the declared range.

Provenance

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

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

Thread query: the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

TL;DR: The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.

Not specified by the original author.

TL;DR

Scan production artifacts, not the whole source tree. Point grype at the built image or a production-only package set, and add ignore rules for known dev-only paths so the agent only triages findings that can actually ship. Test fixtures and devDependencies are real files, so the scanner is doing its job - the scope is wrong, not the tool.

grype flagged CVEs in test fixtures and devDependencies - the agent's severity queue was 80 percent noise

Steps

1. Confirm the noise is really dev-only. Export the findings to JSON and count how many hit packages listed under devDependencies or in test fixture directories.

   • Run: grype dir:. -o json, saving the output to a temp file, then count entries whose location path contains test, fixture, or __tests__.
   • Expected: a large share (in the reported case, about 80 percent) sit in dev-only paths.

2. Switch the scan target from the source tree to the production artifact. Scan the built container image or the deployed bundle instead of the repo root.

   • Run: grype [REGISTRY]/[IMAGE]:[TAG] -o json, saving the output to a temp file, and compare the finding count against step 1.
   • Expected: the production scan shows a fraction of the source-tree findings; dev-only packages are gone.

3. For source scans you must keep, generate a production-only package set. Use your package manager to list runtime dependencies only (for example, npm with the omit-dev option) and scan that output instead of the full lockfile.

   • Expected: dev-only packages no longer appear in the finding list.

4. Add ignore rules for the dev-only paths that survive. Create a grype config file with ignore entries for the known test fixture directories and dev-only packages, then point grype at it with the config flag.

   • Run: grype dir:. -c .grype.yaml -o json, saving the output for comparison.
   • Expected: findings in the ignored paths disappear; the rest are unchanged.

5. Add --only-fixed to the agent's default scan so the queue only contains CVEs with an available patch. Unfixable dev-only findings are the noisiest slice.

   • Run: grype [IMAGE] --only-fixed --fail-on high.
   • Expected: the queue shrinks to actionable items with fixes available.

6. Wire a weekly review of the ignore list into the agent's loop. Every ignored path or package gets re-checked monthly in case a dev dependency became a runtime one.

   • Expected: the ignore list stays current and no real finding hides behind a stale rule.

Use this when

• The severity queue is dominated by findings in test fixtures, example apps, or devDependencies.
• The agent scans the repo root or a directory that includes dev tooling.
• Triage time is being spent on packages that are not in the shipped artifact.
• Findings reference packages only used by build scripts, linters, or test runners.

Not for this skill when

• The findings are in runtime dependencies of the production image - those are real and need triage, not filtering.
• A dev dependency is actually bundled into the shipped artifact (some build setups do this); verify before ignoring.
• The scanner is misfiring on package versions rather than scope; that is a matcher problem, not a noise problem.
• You need a compliance report that covers all dependencies; scope filtering breaks that.

Variant phrasings

• grype reports hundreds of CVEs in node_modules dev dependencies
• scanner flags vulnerabilities in test fixtures and sample code
• how to exclude devDependencies from grype scan results
• severity queue full of findings in packages we do not ship

Why it happens

Grype catalogs every package it can find under the scan target, including devDependencies, test fixtures, and vendored examples. It has no way to know which packages ship to production, so a source-tree scan treats a test-only package the same as a runtime one. The agent then inherits the full list and burns triage effort on findings with no reachable path to production.

Edge cases

• Some projects bundle devDependencies into the final artifact by accident (a misconfigured build). Re-verify scope after every build change.
• --only-fixed can hide a critical CVE with no fix yet. Keep a separate watch list for unfixed criticals in production scope.
• Ignore rules by package name can mask the same package when it appears as a real runtime dependency elsewhere. Prefer path-based ignores where possible.
• Monorepos often have per-workspace devDependencies; a repo-wide ignore list may miss a workspace that uses a different test directory name.

Provenance

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

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

Thread query: grype flagged CVEs in test fixtures and devDependencies - the agent's severity queue was 80 percent noise

TL;DR: Scan production artifacts, not the whole source tree. Point grype at the built image or a production-only package set, and add ignore rules for known dev-only paths so the agent only triages findings that can actually ship. Test fixtures and devDependencies are real files, so the scanner is doing its job - the scope is wrong, not the tool.