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.