Do not post inline comments on generated files or vendored copies. The author cannot sensibly edit them, so the comment is noise. Track findings there anyway, and route the fix to the generator, the template or the upstream project, where it can actually be made.
Why these files are different
A generated client, a compiled bundle or a lockfile is the output of a tool. Editing it by hand is wrong because the next generation overwrites the change. A comment that says "fix this line" points at the wrong place.
A vendored directory is a copy of someone else's code. A fix belongs upstream, or in a patch you maintain on purpose, not in a casual edit during an unrelated pull request.
What to do instead
| File type | Inline comment | Where the finding goes |
|---|---|---|
| Generated source | No | Summary, with a pointer to the generator or template |
| Lockfile | Dependency finding on the manifest | Version bump in the manifest or constraint |
| Vendored library | No | Upstream issue or a tracked patch, with owner |
| Minified bundle | No | Source package that produced it |
| Test fixtures | Usually no | Excluded with a recorded reason |
Note the lockfile row. Dependency findings are real even though the lockfile is generated, because the lockfile records what you ship. Comment where the author can act: the manifest line or the update that changed the resolved version.
Mark paths in configuration, not in people's heads
Keep a short list of generated and vendored paths in the scanner configuration, with a comment saying why each is there and who owns the source. A path exclusion without a reason becomes a place where real problems hide.
Use a convention that humans can see too, such as a folder name like generated or vendor, and mirror it in the scanner so the two agree.
Do not exclude what you ship
Excluding a vendored directory from comments is not the same as excluding it from scanning. If the vendored code runs in production, its vulnerabilities are yours. Keep scanning it, report findings in a separate view, and assign a person to look at them on a schedule.
This is where an SBOM helps: it lists the vendored components as dependencies so they are not forgotten. See how to review a vendored dependency update.
Review the exclusions
Once a quarter, read the exclusion list. Remove paths that no longer exist. Check that each remaining one has an owner and a reason. A stale exclusion list is a quiet way for unscanned code to grow.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components are listed in an inventory, and think about where vendored and generated code would appear.
Safeguard provides SBOM and dependency scanning, so vendored components can be tracked as inventory. Try a free scan.
Quick check
Is it safe to exclude generated code from scanning?
It is reasonable to exclude it from comments. Scanning is a separate decision, and shipped code should usually still be scanned somewhere.
Who owns a vendored library finding?
The team that vendored it, in practice. Record the owner next to the path so the finding has a home.
Last reviewed: 19 October 2026.
