> Also package dependency info is mostly lost in the container but would be valuable to have in the SBOM. Agreed on connecting code->container and I'd go one s

> Also package dependency info is mostly lost in the container but would be valuable to have in the SBOM. Agreed on connecting code->container and I'd go one step further with code->container->running server. I've helped folks work around the dependency metadata issue by adding the package-lock.json into the container for the explicit purpose of having syft pick it up. Not ideal but it works. > I think one product should have one single SBOM, with all components and without duplicates. Yes, and it's trickier than it sounds. My current line of thinking is to model components of an app (frontend, backend, queue worker, etc) as a stream of SBOMs per commit and use label queries to aggregate the SBOMs together dynamically as they change.