Software bill of materials

I understand through my colleagues that some activities may require a software bill of materials to be included in future (https://www.ntia.gov/SBOM).

I wanted to know whether this data already exists for Octave or it’ll have to be done anew by each end user.

From curiosity, I looked at all the libraries loaded recursively by Octave with this command

less /proc/`pgrep octave`/maps

and there were some 168 different libraries loaded, many more than what’s returned by ldd. Most of them were recognizable like Qt and Openblas but some were unfamiliar like “libjasper” and “libarcher” and not in the Octave tree.

Is there a standard accepted way to get this information for Octave?

To my humble knowlege no complete list exists so far for Octave and I suspect this list might differ between Operating systems and even between Linux Distributions due to different packaging and dependencies.

The “real” dependencies are checked at configure time and a maybe incomplete list is in the wiki: Building - Octave

Is this really something for us to do? We provide the sources for Octave explicitly with no warranty. If it breaks, you get to keep all the pieces.

Is this concern for a SBOM prompted by the recent log4j thing? I’m curious to know why this particular vulnerability suddenly captured so much attention.

1 Like

I am not sure myself as to why the sudden emphasis from top down but evidently there was an executive order requiring SBOMs for certain US federal government projects, which is now making its effect felt on research proposals in the US. (The link I shared has some references). I think the log4j thing is a distraction with bad timing unfortunately, but it might have freaked the senior managers into action. I can see the overall benefit of SBOMs but the execution is going to be murky and none of the following options makes sense:

  • Have a person submitting a research proposal submit an SBOM for software they didn’t write. This sounds like it is asking for inaccurate data. There’s also no defined process that can be used.

  • Have a software maintainer create and maintain the SBOM, which is a giant timesink and a waste of developer time on what might be a bureaucratic exercise. Also if the developer or maintainer isn’t even in the US it’ll add an extra layer of annoyance.

  • Have some independent body or automated tools figure this out similar to how licenses are handled by SPDX identifiers. But there’s no such tool we can point to AFAIK.

So, overall at this point if I submit a proposal that requires an SBOM, the best I can do seems to be to list the dependencies from the software’s configure script or to run ldd or objdump on the executable, recognizing that if I run the same program on my personal machine vs running it on a cluster several months later, that SBOM won’t have any resemblance to what I submit in the proposal.

The take home from this discussion is that we (as in people who contribute to or maintain Octave) don’t have this data for Octave, there are too many user-specific variations to centralize it anyway, and it’s best left to end users for now, acknowledging the hazards there. Hopefully there will be some third party automated tools to figure all this out so we don’t have to.

1 Like