75% of the problem is the detective work identifying among 1000 dependency trees running in your datacenter, and reporting the BOMs typically requires a bespoke step for each one. Every process should take a dump-BOM signal to make gathering the BOM from every cpu common , quick & instant.
[–] Normal_gaussian 2 days ago
[–] tonymet 2 days ago
[–] tonymet 2 days ago
[–] kg 2 days ago
i.e. if an app is written in javascript and running on mac there are potentially 4 different languages all running inside the executable that need to cooperate to handle the BOM signal and report their deps - C/ObjC, Swift, C++ and JS. Presumably you'd want to report not only the native libraries being used in the process but also things like npm packages.
[–] tonymet 2 days ago
Presumably the runtime would have the loaded symbol table, which could be used in lieu of a BOM summary.
Trying to respond to a signal is a nightmare of routing and lifecycle bugs. Never mind the fact that most dependencies won't be registered. Currently file/process signature matching is ok for major runtimes, and tends to fail on specific version detection. This would effectively formalise that.
I could see it being a successful standardisation for major runtimes and many libraries that wouldn't currently be detected - but take up would never be universal. A kind of CVE search stamp.