Preface: This is on the border of "enhancement" and "bug", depending on how you look at it.

Today, when looking for NPM-related lock files (package-lock.json and yarn.lock), Syft finds files with these names at any location in the file tree, and then it parses each found file for a list of packages and their versions.

According to the package-lock.json docs and the yarn.lock docs, lock files found for a project's dependencies (i.e. not for the project itself) should be ignored entirely. In other words, only a project's top-level lock file will ever be used by the tooling, and, of particular importance for Syft, during installations and builds for that project.

Today these lock files are used during directory scans and not during image scans. This fact may change in the future, but still, it's worth considering a possible relationship between the implementation of this issue and the implementation of configurable cataloging methods.

Lock files are used for directory scans because the primary use case for directory scans is to scan a software project, typically from the root of a repository.

With this in mind, it could easily be considered more correct to surface only the top-level lock files' contents, both for SBOM generation and for downstream vulnerability matching. That is, a project's dependencies — even in the exhaustive sense — would not include packages found in lower-level lock files but not found in the top-level lock file. This is important when it comes to creating an SBOM (answering "what software ships with this project?") and identifying vulnerabilities (answering "what vulnerabilities would be present when this code is packaged up and published?").

IMPORTANT: While various implementations are possible, implementers should strongly consider the potential for their solution to cause Syft not to find valid packages. The intent of this bug is to reduce false positives, but it would be easily possible to produce a solution that introduces false negatives, which should be avoided if possible.