4 ms·

There are essentially 2 approaches to SBOM. 1) scanning source code: it will generate also lot of false positive and a need to manually edit (ammend/correct) t

There are essentially 2 approaches to SBOM. 1) scanning source code: it will generate also lot of false positive and a need to manually edit (ammend/correct) the SBOM. This works best with containers. One Foss tool that does this is Anchore's syft/grype. Others have jumped onto the sbom bandwagon simply because they thought it's easy (they were already offering SAST/DAST) The other class of tools actually only looks at a binary artifact (firmware, executable, library etc) and then tries to extract the SBOM from that. I am not aware of any FOSS tool here and would br cool to learn of anything out there. But chances are some custom work is needed for each specific firmware. Only vendor I know today are Binare.io, cybellum) For firmware and embedded this really the only way that IMHO makes sense for embedded engineering. Because you can't just scan an SDK and say "yepp it has mbedtls xyz or c-json in it ...". It won't find it because there is no specfile or something that cam be parsed reliably. Your only option would be to strong-arm the silicon vendor into supplying a machine readable sbom along with the SDK. It also has less false positive and doesn't find vulnerabilities (or license issues D depending on what you match for) you don't care about. The NTIA envisions the SBOM as a key element in building a risk based approach to devsecops with Vuln Exchange (VEX) and much more. We're still far from thus. Fact though it's already becoming part of regulation (RED, CRA) in Europe and the US (Executive Order Biden signed not too long ago)

acdha 4y ago
> scanning source code: it will generate also lot of false positive and a need to manually edit (ammend/correct) the SBOM Can you give any examples of this? I’ve never seen a tool like this report a true-false positive but based on your mention of embedded tools I’m guessing you might be referring to something like a build dependency which is completely optimized out such as a debugging feature on a production build? In such cases I would be inclined to either prepare separate SBOMs or otherwise indicate when something is present but not reachable. My concern about editing the files is that these are intended in a somewhat legalistic context and if something blew up it’s not hard to imagine someone’s lawyer using those changes to argue that you were aware of a problem and tried to cover it up. Even if you could defend your policy, that’s not a conversation anyone wants to have.
- pseudotrash 4y ago
  example would be trying to create the sbom on a build server which is meant to produce the artifact. and you're only intersted in what your artifact needs (pulls in). How would any tool know what to include in an SBOM? because normally the sbom generation tool will try to query your package manager, whether thats rpm, dpkg or pypi and others to try to understand what it sees. so looking at the build stage might include a lot more (tool chain etc). most commercual tools eould cater for this b6 alliwing you to rectify incomplete or wrong information. the problem you mention, liability, is an important one. if the law requires the sbom to be correct then this is a problem humans need to verify. and tgats really annoying.
zvr 4y ago
There are actually more "types" of SBOMs than the two you mention. I don't think CISA has published the corresponding table yet, but depending on the point in the software lifecycle that you are, you can create "Design", "Source", "Build", "Deploy", or "Analysis" SBOMs -- and they are all for different use cases,

acdha 4y ago

> scanning source code: it will generate also lot of false positive and a need to manually edit (ammend/correct) the SBOM Can you give any examples of this? I’ve never seen a tool like this report a true-false positive but based on your mention of embedded tools I’m guessing you might be referring to something like a build dependency which is completely optimized out such as a debugging feature on a production build? In such cases I would be inclined to either prepare separate SBOMs or otherwise indicate when something is present but not reachable. My concern about editing the files is that these are intended in a somewhat legalistic context and if something blew up it’s not hard to imagine someone’s lawyer using those changes to argue that you were aware of a problem and tried to cover it up. Even if you could defend your policy, that’s not a conversation anyone wants to have.

pseudotrash 4y ago
example would be trying to create the sbom on a build server which is meant to produce the artifact. and you're only intersted in what your artifact needs (pulls in). How would any tool know what to include in an SBOM? because normally the sbom generation tool will try to query your package manager, whether thats rpm, dpkg or pypi and others to try to understand what it sees. so looking at the build stage might include a lot more (tool chain etc). most commercual tools eould cater for this b6 alliwing you to rectify incomplete or wrong information. the problem you mention, liability, is an important one. if the law requires the sbom to be correct then this is a problem humans need to verify. and tgats really annoying.

zvr 4y ago

There are actually more "types" of SBOMs than the two you mention. I don't think CISA has published the corresponding table yet, but depending on the point in the software lifecycle that you are, you can create "Design", "Source", "Build", "Deploy", or "Analysis" SBOMs -- and they are all for different use cases,