Re: [open-regulatory-compliance] CRA Standardisation request

["Olle E. Johansson" <oej@xxxxxxxxxx>]

On 18 Feb 2025, at 21:37, Jeremy Stanley via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

Signed PGP part

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.

They are still dependencies. The CycloneDX team is right now discussing

an extension to be able to specify external not included dependencies

within the SBOM. This is required by some standards.

/O

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

_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org