The only tool that seems to get this even partly right is syft but it is still far from being an acceptable solution.
syft does get this right because it can scan both but it falls short in combining the results. I think one product should have one single SBOM, with all components and without duplicates.
Even if syft can scan the source it does not seem to write the package dependencies into the SBOM.
Also licenses are missing. I'm not sure it that falls in the scope of syft but I wish it would and it would also detect and report licenses.
It's nice that syft supports many output formats, because conversion was so far a big disappointment, regardless of the tool, including syft.
Lastly I find the command line interface is a mess. The useful but undocumented and deprecated power-user command doesn't seem to have a successor and the other commands seem inconsequential and buggy, for example
syft [command] --help
I think syft is promising but still a far way from being a good solution.
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.