The interesting thing about the eMudhra issue is that it's not just your cloud environments that you need to be worried about. Think about this scenario:
Developer runs `pip install ruff` with pip < 26.2.2 on a public wifi network at their local coffee shop. Wifi network is spoofed, forwards all traffic except pip. Intercepts the pip requests and returns a malicious package. Machine is instantly compromised.
So any local development environment is also very susceptible to this kind of attack until pip, certifi, node, etc. get upgraded.
We've got good tools for finding this kind of issue CI/CD and our cloud environments. But good luck finding and patching every virtual environment on your local machine.
we need more standardized BOM reporting. a common signal "kill -s BOM <PID>" that has the process dump it's BOM to /dev/ttys3 . the lowest-level most common / primitive interface. no APIs, exec()s needed.
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.
Its probably better to embed clearer strings in the binary that conform to some spec. Then searching over binaries would find them.
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.
You'd still need a spec for this because of cross-language considerations, but that doesn't make it a bad idea.
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.
The interesting thing about the eMudhra issue is that it's not just your cloud environments that you need to be worried about. Think about this scenario:
Developer runs `pip install ruff` with pip < 26.2.2 on a public wifi network at their local coffee shop. Wifi network is spoofed, forwards all traffic except pip. Intercepts the pip requests and returns a malicious package. Machine is instantly compromised.
So any local development environment is also very susceptible to this kind of attack until pip, certifi, node, etc. get upgraded.
We've got good tools for finding this kind of issue CI/CD and our cloud environments. But good luck finding and patching every virtual environment on your local machine.
we need more standardized BOM reporting. a common signal "kill -s BOM <PID>" that has the process dump it's BOM to /dev/ttys3 . the lowest-level most common / primitive interface. no APIs, exec()s needed.
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.
Its probably better to embed clearer strings in the binary that conform to some spec. Then searching over binaries would find them.
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.
You'd still need a spec for this because of cross-language considerations, but that doesn't make it a bad idea.
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.
Good point on that. The bom signal could be relayed. E.g. for a runtime, or multi tenant app, the parent runtime would relay the bom signal.
Presumably the runtime would have the loaded symbol table, which could be used in lieu of a BOM summary.