Its listed as a signature transparency log, but they support some sort of custom manifest system, so you can set your own schema in your prefered format (xml, json, yaml) - the only thing is they require the manifest / material file is signed (I guess as it then brings a level of non-repudation). I am hoping someone works on an SBOM type.
I heard some of the in-toto folks are working on the project as well. This is a good step towards a SBOM recorded supply chain.
Doesn't something like FDA approval of medical systems already require this? I believe you're required to maintain a list, and risk analysis of third party software you incorporate into medical products: https://en.wikipedia.org/wiki/Software_of_unknown_pedigree
Solution is different. Decriminalize software errors exploitation / hacking. Reliance on justice system is a fools' errand in a global economy anyway. There are two tiers of software operations. Global (FAANG etc) and local. First are rather good with security - because they pay attention. Local live in a fantasy world where people who should care are afraid to poke.
Incentives for local services (government, municipal, local companies) are misaligned. This is why their security is in such a bad shape and this is why they fail spectacularly.
Wouldn't having to advertise your out of date dependencies help to shame companies into upgrading on a reasonable schedule? So that upgrades are actually a priority and not just a thing that happens when literally everything else is already done?
If that became a problem, companies intending to skirt the disclosure would fork and “maintain” private branches of dependencies such that it couldn’t be determined if they were out of date.
True story: They already do. I know one company that forked Ruby, and would likely claim every library they run under it is thereby forked for the sake of reporting.
The rekor project under sigstore is interesting in this regard: https://github.com/sigstore/rekor Its listed as a signature transparency log, but they support some sort of custom manifest system, so you can set your own schema in your prefered format (xml, json, yaml) - the only thing is they require the manifest / material file is signed (I guess as it then brings a level of non-repudation). I am hoping someone work…
Maintainer here! That's exactly the idea. We're working with intoto and others to get metadata that we can actually verify, directly from build systems.
Rekor is a place to put and find that metadata that's globally visible and can't be tampered with.
We're hoping to add support for the ITE-6 in-toto link format soon, which I see as kind of like an SBOM that can be produced directly from your build system.
At least on first reading, I find this unpersuasive. He correctly lists a variety of problems. But he doesn't explain how his proposed solution, listing all the components of a technological product, would make a practical difference. Creating a list is valuable only if people a) read the list, b) recognize problems, and c) do something based on that. And for some of the examples he gives, it seems pretty obvious to…
Without reading the article, I can imagine that listing the components of a technological product (i.e., an SBOM) is a _first step_ towards the goal of solving all those problems. Once you have a standardized way of communicating what a software product is made of, you can start thinking of automatically upgrading dependencies (Maven's pom.xml does this to some extent, and Dependabot and Renovatebot leverage this semi-standard to automatically upgrade your dependencies). If you take this one step (or two steps) further, you can start to automatically rebuild the code, automatically deploy the code, patch running systems, detect when CVEs are actively being abused, and so on. Basically, automate the heck out of this so that the "they just didn't do it" will not happen. And for automation, you need standards.
My big problem with all the SBOM efforts is that any kind of compliance/accuracy will be best effort and most likely wrong, leading to more problems and blame. This is not as simple as writing down your dependencies. Most people don't even know what their full set of transitive dependencies is, or how to even go about finding it. How do you know the SBOM you get is even accurate? You can't just crack open a binary an…
You can, in fact, crack open the binaries and look at what's inside. The field of tooling for it is called SCA (software composition analysis).
If that became a problem, companies intending to skirt the disclosure would fork and “maintain” private branches of dependencies such that it couldn’t be determined if they were out of date.
True story: They already do. I know one company that forked Ruby, and would likely claim every library they run under it is thereby forked for the sake of reporting.
Ok, but there would still be some point of contact where an SBOM would show “company X fork of Ruby, company X fork of package Z” etc, right?
And then the choice gets back to how much to trust company X and package Z, weighed against alternative solutions.
At least on first reading, I find this unpersuasive. He correctly lists a variety of problems. But he doesn't explain how his proposed solution, listing all the components of a technological product, would make a practical difference. Creating a list is valuable only if people a) read the list, b) recognize problems, and c) do something based on that. And for some of the examples he gives, it seems pretty obvious to…
In my mind SBOM is similar to food ingredients being listed on the packaging. FDA or someone requires them, very few read them or cares what is in there. BUT now that they are listed on every food product, those who care can read them and make informed decisions. And raise alarm when it is found that someone uses unhealthy amounts of whatever in their cakes or sausages.
As for software, if I had up to date reliable SBOMs for everything I run, it would certainly give me piece of mind. And maybe, even if unlikely, I might be able to do purchasing decisions based on used components, their CVE/etc. history, or sheer amount (in less being generally better, unless there is a reason to suspect the vendor e.g. rolled their own TLS instead of using one of the usual suspects).