The email I got from security:
-------- Forwarded Message --------
Subject: Re: SBOM questions
Date: Mon, 2 Dec 2024 11:41:16 +0100
From: Arnout Engelen <enge...@apache.org>
To: Tilmann Zäschke <tilma...@apache.org>
CC: secur...@apache.org
Hi!
On Fri, Nov 29, 2024 at 7:13 PM Tilmann Zäschke <tilma...@apache.org> wrote:
I have some questions regarding SBOMs, if you could help me with some of
these questions that would be much appreciated:
Happy to!
1) Is it recommended to create SBOMs for pure library projects (or API
projects)?
Yes, I think having SBOMs for libraries is helpful.
The Wiki says "As such, for our purposes, an SBOM would typically be
restricted to run-time and embedded dependencies"
I am not sure what that means, dependencies are either run-time (loaded
during application run-time) or embedded (delivered together with the
application), is there another type?
Ah, what I meant there was that for our purposes it's not very helpful
to also include information about what tools and dependencies are used
at build time.
2) How are SBOMs used (especially for library projects)?
I somehow imagine, from the perspective of someone who wants to analyze
an application, it would be easier and much more secure to run a full
analysis of the dependency tree locally, rather than relying on SBOM
files that are downloaded separately? To verify that an SBOM matches the
used library, I have to download them anyway, or not?
I think the whole ecosystem is still rather in its infancy, and the
questions of 'how should we create SBOMs' and 'how can we use SBOMs'
will develop further in tandem.
Indeed some things are only 'finalized' when a library is used in a
particular context, and if you want to analyze an application, you
want to look at the dependency tree as it's realized for that
application. For example in the Java/Maven ecosystem, a library can
have a dependency on version X of a component, but if an application
uses that dependency and specifies version Y of the component, of
course you should be looking at version Y for the analysis.
SBOMs from libraries could be useful to collect and analyze in their
own right, though - for example for platform-agnotic tools like
https://sbom.security.apache.org/version-diff/ (quick prototype :) ).
Also having an SBOMs for the library might allow us to express things
that can be hard to determine 'after-the-fact'/'downstream'. For
example, when dependencies are shaded/embedded into the artifact
instead of specified as a 'regular' overridable dependency, perhaps
the SBOM is a good way to communicate that information. Early days
though (https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/472)
3) Is it recommended to create SBOMs for past releases?
I assume not, but if it is, is there s stand-alone tool to create such
SBOMs? (Our project is in Java, and using the Maven plugin requires
modifying the .pom, so doing that for existing releases is not really
possible, the Hash would be wrong).
I agree it's completely reasonable to just create SBOMs 'going
forward' and not going back for existing releases.
Also, our project (DB-JDO) is a bit special, it is essentially an API
standard, so vendors may stay with older versions for a longer time
before moving on.
That makes sense. I enjoyed your questions and will improve
https://cwiki.apache.org/confluence/display/SECURITY/SBOM+Software+Bill+of+Materials
based on them, LMK if you have any follow-ups!
Kind regards,
--
Arnout Engelen
ASF Security Response
Apache Pekko PMC member, ASF Member
NixOS Committer
Independent Open Source consultant
