| Re: [open-regulatory-compliance] CRA Standardisation request |
On 2025-02-18 12:00:53 -0800 (-0800), Scott Lewis via open-regulatory-compliance wrote: [...] > Admittedly it's valuable...but it's also *static*. Just the fact that in > osgi/p2 acceptable version *ranges* constraints are given for dependencies > means that the target environment (i.e. what else is present at install time > as well as what repos are know/available) will determine the dependency > resolution....i.e. what version of a dependency is resolved dynamically at > install time. [...] Are these dependencies effectively invisible when installed? It seems like if the installer records what versions of which packages it installed, then you don't have a need to ship an SBOM which tries to predict things that will be installed. Shouldn't an SBOM be for when you have versions of other projects embedded inside what's directly shipped/packaged? This is where I think different ecosystems are getting confused on the point of SBOMs. Some seem to think an SBOM is for recording non-obvious things that are being shipped inside an otherwise opaque blob like a packaged application download or a container image, others seem to think an SBOM is for recording all your dependencies even if you're not distributing those and the end user is going to install them from somewhere else. Say I'm building a container image for my project, and that container image is going to include copies of my project's dependencies, the container image should include an SBOM that lists the dependencies which are actually inside that container image, not a prediction of what else might end up on the user's system. The tool which constructs the container image can accurately record those things into the accompanying SBOM, my project's developers shouldn't need to explicitly create that SBOM themselves (or even think about it at all really, any more than other kinds of metadata which end up recorded into that container images by the same build tool). Say I'm distributing a package of my application in an language ecosystem, but that package doesn't itself embed any of the application's dependencies, merely a list of their names and maybe some rough version ranges of what it can support, so that the language ecosystem package installer will retrieve and install compatible versions of those dependencies. My package doesn't need an SBOM, as it only contains the namesake application it includes. Some of its dependencies might themselves include an SBOM if they embed or vendor versions of other projects rather than letting the package installer fetch those. If my package *did* embed a copy of some dependency directly instead, then the package build tool is best placed to record an SBOM and again my project's developers still shouldn't need to care. It will just be there. So for the most part, from where I sit, upstream open source projects shouldn't need to mess with explicitly creating, tracking and publishing SBOMs. If consumers want an SBOM or similar record of what's in installable artifacts like container images or packages, then the build tools and installers are where that sort of functionality should be added. It should be basically transparent upstream. When it comes to being aware of vulnerabilities in components shipped in these artifacts and tracked in those auto-generated SBOMs, such scans can be performed on the artifacts post-build or in build dry-run processes, where the actual versions of included components are known and don't have to be predicted. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature