3 ms·

It's for the end user who purchases a lot of things which include software components to understand the total set of software they're running and be able to ask

It's for the end user who purchases a lot of things which include software components to understand the total set of software they're running and be able to ask questions about licensing, vulnerabilities, and establish policies. A developer (or even administrator of a single computer system) is not the user of something like this, typically. Here's an example: A small manufacturing business may have a dozen different machines. Each one has a set of software to control it, running on a computer embedded in the machine. The business also has a website (developed by a contractor), a bunch of software packages purchased from different vendors for accounting, inventory, payroll and scheduling. They probably have some internal home-grown tools too. 1. A new remotely exploitable CVE is announced in a widely-used open source library. Is the company vulnerable to it? Anywhere? If each one of the pieces of software was delivered with a SBOM along with the actual code, you can use tools like this to look at this globally. It starts to make more sense at the scale of "all the software in the business" is provided by tens to hundreds of different vendors or teams that not only don't communicate with each other but also don't even know that the others exist.

kreeben 4y ago
Is lying about your dependencies unheard of, in this scenario?
- er4hn 4y ago
  Before the government SBOM standard that kicked all this off was finalized, I'd asked about this and related items such as reproducible builds. The response I got is that getting honest information out of vendors would be a huge step forward for end customers. Being able to validate that information would require a lot more work. Things like SLSA levels 3+4 (https://slsa.dev/spec/v0.1/levels https://slsa.dev/spec/v0.1/levels) go further to prevent lying, at least in situations where all the code can be compiled by third parties.
aaaaaaaaaaab 4y ago
How does a “small manufacturing business” get notified of this CVE popping up? I don’t think they would even know what a CVE is…
- vladvasiliu 4y ago
  They could sign up for a CTI (Cyber Threat Intelligence) service with a security company. Basically, they send you notifications about CVEs and related stuff. My client isn't exactly a "small manufacturing business", but they do subscribe to such a service, and they did have the Java issue in a parent process. They have a security guy who's the main one expected to look at these, but he's not the one operating anything directly, so he can't be expected to know every last random lib that's used. So when the Log4j2 issue came up, for example, he was aware there was "a Java issue" but had no automated way of knowing which systems, if any, were affected.

kreeben 4y ago

Is lying about your dependencies unheard of, in this scenario?

er4hn 4y ago
Before the government SBOM standard that kicked all this off was finalized, I'd asked about this and related items such as reproducible builds. The response I got is that getting honest information out of vendors would be a huge step forward for end customers. Being able to validate that information would require a lot more work. Things like SLSA levels 3+4 (https://slsa.dev/spec/v0.1/levels https://slsa.dev/spec/v0.1/levels) go further to prevent lying, at least in situations where all the code can be compiled by third parties.

aaaaaaaaaaab 4y ago

How does a “small manufacturing business” get notified of this CVE popping up? I don’t think they would even know what a CVE is…

vladvasiliu 4y ago
They could sign up for a CTI (Cyber Threat Intelligence) service with a security company. Basically, they send you notifications about CVEs and related stuff. My client isn't exactly a "small manufacturing business", but they do subscribe to such a service, and they did have the Java issue in a parent process. They have a security guy who's the main one expected to look at these, but he's not the one operating anything directly, so he can't be expected to know every last random lib that's used. So when the Log4j2 issue came up, for example, he was aware there was "a Java issue" but had no automated way of knowing which systems, if any, were affected.