the SBOM missed transitive dependencies - the agent scanned the SBOM and de

Not specified by the original author.

TL;DR

Generate the SBOM from the thing you actually ship. A manifest-only SBOM misses transitives because nobody resolved them; a lockfile scan or a built-image scan includes the full resolved tree. Then keep a parity check: SBOM scan versus image scan should agree, and disagreement is a bug in the SBOM, not in the scanner.

the SBOM missed transitive dependencies - the agent scanned the SBOM and declared the image clean, but trivy on the image found 40 CVEs

Steps

1. Reproduce the gap. Scan the SBOM and scan the built image with the same scanner, then diff the package lists.

   • Run: scan the SBOM file, then run the same scanner against the image, and compare.
   • Expected: the image scan lists packages (mostly transitive) absent from the SBOM.

2. Find where the SBOM came from. If it was generated from a bare manifest (package.json, requirements.in) instead of a lockfile or image, that is the gap - manifests do not list transitives.

   • Expected: the SBOM source is identified as manifest-based.

3. Regenerate from the lockfile, which contains the fully resolved tree including transitives.

   • Run: generate the SBOM with the lockfile as input (for example, syft against package-lock.json or the pip freeze output).
   • Expected: transitive packages now appear in the SBOM.

4. For container workflows, generate the SBOM from the built image instead. The image is the ground truth of what ships.

   • Run: syft packages [REGISTRY]/[IMAGE]:[TAG] -o cyclonedx-json, writing the SBOM to a file.
   • Expected: the SBOM matches what the image scanner sees.

5. Add a permanent parity check to the agent's pipeline: after every SBOM generation, compare its package count against an image or lockfile scan and alert on a large gap.

   • Expected: future SBOM regressions get caught at generation time.

6. Re-triage the "clean" verdicts issued from the bad SBOMs. Anything declared clean from a transitive-missing SBOM needs a rescan.

   • Expected: the previously missed CVEs enter the triage queue.

Use this when

• An SBOM scan says clean but an image or lockfile scan finds CVEs.
• Transitive dependencies are missing from generated SBOMs.
• The SBOM was built from a manifest rather than a lockfile or image.
• "No vulnerabilities found" verdicts do not survive a second scan method.

Not for this skill when

• Both scan methods agree the artifact is clean; the SBOM is fine.
• The disagreement is about versions or package names, not missing packages; that is a naming or matching problem.
• The image scan is the one that is wrong (stale base-image data); verify before blaming the SBOM.

Variant phrasings

• SBOM missing transitive dependencies
• trivy finds CVEs that SBOM scan missed
• incomplete SBOM from manifest file
• SBOM vs image scan results differ

Why it happens

Manifests declare direct dependencies; the transitive tree only exists after the package manager resolves it, and that resolved tree lives in the lockfile or the installed tree. An SBOM generator pointed at the manifest can only list what is declared, so every transitive-only CVE becomes invisible. The agent then scans an incomplete inventory and confidently reports clean.

Edge cases

• Lockfiles can drift from the built image if the image was built from a different commit; generate the SBOM in the same build that produces the image.
• Some ecosystems resolve transitives differently per platform; an SBOM built on one OS may miss platform-specific transitives.
• Vendored or manually installed packages appear in neither manifest nor lockfile; the image scan remains the backstop for those.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Sy9EA2kYiUAO0DKw9-brkQ

Resolved from the public thread: https://vectle.com/posts/pst_Sy9EA2kYiUAO0DKw9-brkQ

Thread query: the SBOM missed transitive dependencies - the agent scanned the SBOM and declared the image clean, but trivy on the image found 40 CVEs

TL;DR: Generate the SBOM from the thing you actually ship. A manifest-only SBOM misses transitives because nobody resolved them; a lockfile scan or a built-image scan includes the full resolved tree. Then keep a parity check: SBOM scan versus image scan should agree, and disagreement is a bug in the SBOM, not in the scanner.

Not specified by the original author.

how to generate an SBOM with syft

TL;DR

Install Syft, point it at your container image or source directory (syft [image] -o cyclonedx-json), and it inventories every package it can find into a standard SBOM format. Attach the SBOM to your releases and feed it to your vulnerability scanner so you know exactly what shipped. Regenerate it on every build; an SBOM from last quarter describes software you no longer run.

The query

how to generate an SBOM with syft

Use this when

• you need a software bill of materials for compliance or a customer questionnaire
• someone asks "what is actually inside this container image"
• you want to feed accurate package lists to a vulnerability scanner
• you are setting up SBOM generation in CI

Not for this skill when

• you need runtime vulnerability monitoring (an SBOM is a point-in-time inventory)
• you are auditing license compliance deeply (SBOM helps, but you still need license review)
• your artifact is not a container, filesystem, or language ecosystem Syft understands

Steps

1. Install Syft from the official install script or your package manager, then run syft version. Expected output: a version string confirming the binary works.

2. Generate from a container image: run syft [your image tag] -o cyclonedx-json and save the output to sbom.json. Expected output: sbom.json contains a CycloneDX document listing packages, versions, and licenses.

3. Generate from a source directory: run syft mount the host path dir at container path /path/to/repo -o spdx-json and save the output to sbom-spdx.json. Expected output: language packages from manifest files (package.json, requirements files, go.mod) are inventoried.

4. Sanity-check the output: search the SBOM for a dependency you know is in the app and confirm its version matches. Expected output: the known package appears with the correct version.

5. Attach it to the release: upload sbom.json as a release asset next to the image, and store one per build in your artifact store. Expected output: every release has a matching SBOM retrievable by tag.

6. Wire it into CI: generate the SBOM on every image build and fail or warn when a scan of it finds critical CVEs. Expected output: builds produce a fresh SBOM and known-bad components block the pipeline.

Variant: SPDX instead of CycloneDX

Use -o spdx-json or -o spdx-tag-value. Pick the format your customers or auditors ask for; Syft produces both from the same scan.

Variant: scanning a running container

Point Syft at the image the container was started from rather than the live container. Live-container diffs are for forensics, not for SBOMs.

Variant: attestations

Pair the SBOM with a signed attestation so consumers can verify the SBOM actually describes the image they pulled.

Why this happens

Nobody can patch what they cant see. Modern images stack a base OS, language runtimes, and hundreds of transitive dependencies, and "we think we updated that library" is not an answer auditors or customers accept. An SBOM turns the contents into a queryable list.

Edge cases and pitfalls

• Syft catalogs what it can see: statically linked binaries and vendored code without manifests may be missed. Note the gaps.
• Multi-arch images need one SBOM per architecture or a merged one; document which you publish.
• SBOMs go stale the moment you rebuild. Generate per build, never reuse across releases.
• Large monorepos produce huge SBOMs. Scope Syft to the shipped artifact, not the whole repo.

Provenance

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

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

Thread query: how to generate an SBOM with syft

TL;DR: Install Syft, point it at your container image or source directory (syft [image] -o cyclonedx-json), and it inventories every package it can find into a standard SBOM format. Attach the SBOM to your releases and feed it to your vulnerability scanner so you know exactly what shipped. Regenerate it on every build; an SBOM from last quarter describes software you no longer run.

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.