3 ms·

Sort of. The quality of the data this tooling generates varies GREATLY among languages, build systems and environments. For packaged software like Solarwinds, s

by dlor 6y ago

Sort of. The quality of the data this tooling generates varies GREATLY among languages, build systems and environments. For packaged software like Solarwinds, sure you can try to run an SCA tool. But is anyone claiming an SBOM or SCA tool could have prevented that attack? The bigger issue is services and hosted software. You can't crack open an API or website that stores your data to see what database they're using. You could ask that they publish an SBOM, but who knows if it's accurate.

fulafel 6y ago
I feel you're moving the goalposts a bit. Perfect is the enemy of good, etc. Also surely the tooling would get a lot of investment and improvement poured into it if the proposal went through. Anyway, if this kind of thing really took off, I could well imagine there being regulation for SaaS products having to do audits involving this, for example.
- dlor 6y ago
  I sort of see this as a situation where an imperfect SBOM is worse than nothing. It would do nothing but add false confidence. I still haven't seen an example of a single supply-chain attack that an SBOM would have prevented.
  - fulafel 6y ago
    Well, we were discussing tooling that could be used to check if the declared SBOM is correct, not producing the original SBOM. This kind of checking with today's practices is necessarily going to be imperfect, just like the BOMs in the physical manufacturing realm where the idea originates in. But if today's 99% solution turns out to be sufficiently useful, we could start making things in a way that are 100% verifiable (stuff like reproducible builds, etc) In security we've long ago let go of the idea of risk and turst as binary issues, the same thing applies here. Just about every other tool we have to improve security has bigger holes in it than this one.
  - jacques_chester 6y ago
    We already have false confidence problems. Security scanning is a billion-dollar industry based on looking up digests in a table. But because the table is maintained by third parties, their incentives are to always be over-cautious. If they give false positives, the burden falls on their customers or the upstream dependency. But false negatives fall on the vendor. So they create noise. SBOMs from the upstream push the cost back to the upstream and (sorry, investors and founders) vitiate the necessity of those third-party scanning vendors. The incentives change and so too, I expect, would the behaviour.

by dlor 6y ago

fulafel 6y ago

I feel you're moving the goalposts a bit. Perfect is the enemy of good, etc. Also surely the tooling would get a lot of investment and improvement poured into it if the proposal went through. Anyway, if this kind of thing really took off, I could well imagine there being regulation for SaaS products having to do audits involving this, for example.

dlor 6y ago
I sort of see this as a situation where an imperfect SBOM is worse than nothing. It would do nothing but add false confidence. I still haven't seen an example of a single supply-chain attack that an SBOM would have prevented.
- fulafel 6y ago
  Well, we were discussing tooling that could be used to check if the declared SBOM is correct, not producing the original SBOM. This kind of checking with today's practices is necessarily going to be imperfect, just like the BOMs in the physical manufacturing realm where the idea originates in. But if today's 99% solution turns out to be sufficiently useful, we could start making things in a way that are 100% verifiable (stuff like reproducible builds, etc) In security we've long ago let go of the idea of risk and turst as binary issues, the same thing applies here. Just about every other tool we have to improve security has bigger holes in it than this one.
- jacques_chester 6y ago
  We already have false confidence problems. Security scanning is a billion-dollar industry based on looking up digests in a table. But because the table is maintained by third parties, their incentives are to always be over-cautious. If they give false positives, the burden falls on their customers or the upstream dependency. But false negatives fall on the vendor. So they create noise. SBOMs from the upstream push the cost back to the upstream and (sorry, investors and founders) vitiate the necessity of those third-party scanning vendors. The incentives change and so too, I expect, would the behaviour.