3 ms·

Not sure if biggest pain point, but SBOM tools seem to be a wild mess. A tool that can generate a reliably complete SBOM in a heterogeneous landscape, consideri

Not sure if biggest pain point, but SBOM tools seem to be a wild mess. A tool that can generate a reliably complete SBOM in a heterogeneous landscape, considering the source as well as the end products (like containers) would be helpful. The only tool that seems to get this even partly right is syft but it is still far from being an acceptable solution.

JTbane 3y ago
We use BlackDuck for SBOM at my workplace and let me tell you, the false positives are driving me up a wall. Also, the binary tool seems very primitve (basically just takes a SHA1 hash of all your files and compares them to a database).
- mattkopecki 3y ago
  This is the problem my company solves. I won’t plug it here, but my email is in my HN profile if you want to reach out
robszumski 3y ago
As a fan of Syft, which parts are roughest for you? Agree that there is work to be done.
- weinzierl 3y ago
  I think that real potential of SBOMs can only be realized if they are reasonably complete. I think the only way to achieve that is to scan the source code as well as the container. The source code lacks information about things that get added later but the container lacks information about the components that comprise natively compiled binaries. Also package dependency info is mostly lost in the container but would be valuable to have in the SBOM. So both scans are necessary. 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 always prints the same generic help for all commands. I think syft is promising but still a far way from being a good solution.
  - robszumski 3y ago
    > 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.

JTbane 3y ago

We use BlackDuck for SBOM at my workplace and let me tell you, the false positives are driving me up a wall. Also, the binary tool seems very primitve (basically just takes a SHA1 hash of all your files and compares them to a database).

mattkopecki 3y ago
This is the problem my company solves. I won’t plug it here, but my email is in my HN profile if you want to reach out

robszumski 3y ago

As a fan of Syft, which parts are roughest for you? Agree that there is work to be done.

weinzierl 3y ago
I think that real potential of SBOMs can only be realized if they are reasonably complete. I think the only way to achieve that is to scan the source code as well as the container. The source code lacks information about things that get added later but the container lacks information about the components that comprise natively compiled binaries. Also package dependency info is mostly lost in the container but would be valuable to have in the SBOM. So both scans are necessary. 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 always prints the same generic help for all commands. I think syft is promising but still a far way from being a good solution.
- robszumski 3y ago
  > 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.