[Feature] Add option to resolve Pods that are actually Node-Modules

[malice00]

We are using Expo & React Native to build apps. We've been generating and importing our SBOMs for some time and kept finding it strange that Dependency-Track never showed any issues with the dependencies. Turns out, about 95% of the pod in our SBOM are unknown to the likes of OSS Index. After investigating this a bit more, we found out that all these unknown pod are actually 'locally' defined pods in the node_modules directory.

Now, we would like to know if it would be possible to add a feature that can resolve these pods to the node module and use its data in the SBOM, so that we can actually have vulnerability info on these modules? From what we have found, a lot of information is already correct (seeing it is retrieved from the package.json), but unfortunately the most important things, the name and purl, are not.
We also found that not all podspecs are for local pods, some modules have a directory called 'third-party-podspecs', which contain pod-definitions for pods newer than those in the cocoapods specs repo. These should, preferably, still be resolved to actual pods.

So, what we found (and hope will help), is that the pods that should be resolved to modules all contain a reference to the package.json similar to this: package = JSON.parse(File.read(File.join(__dir__, '..', 'package.json'))).

Could this maybe be added?

Edit:
I just noticed that there will be a lot less node modules than there are Pods, seeing that some modules define tens of pods... Imho, these pods can all be resolved to the same module and therefore be de-duped in the final SBOM. This might also mean that some modules depend on themselves, so care should be taken with circular references...

[macblazer]

It would be very helpful if you could include a simple Podfile file that includes some of these things. With a Podfile sample we can have a repeatable set of things to test against if the functionality is built out to include node modules being imported by CocoaPods.

[malice00]

Of course! I created a test-project for this, guess I forgot to put that in here...
You can use https://github.com/malice00/cdxgen-expo-test.git, branch 'ios'. You do need npm to build, use at least v18.18.0. Run npm i and, if needed, in the 'ios'-directory pod install.

[jeremylong]

You could use https://github.com/CycloneDX/cyclonedx-node-npm to cover the npm dependencies. Generate the cocoapods sbom with this project. Finally, use https://github.com/CycloneDX/cyclonedx-cli to merge the two sboms.

[malice00]

My problem is not the npm dependencies, I already have those in an SBOM (actually using the tool you mentioned).

This issue is a little more complex, apparently also in how to describe it... Let me try again:

When I generate an SBOM for the ios app we are building, there are several pods in there, that 'do not exist' according to eg OSS Index. This is because these pods are, for a lack of a better word, virtual pods. They do not exist in any CocoaPod repository, but are directly defined inside the NPM packages that the 'root' project depends on.
For example, in my project there is a pod 'EXApplication', which is resolved in the lock file to '../node_modules/expo-application/ios'.

What I would like is for cyclonedx-cocoapods to recognize that this is not only a local pod, but actually a node dependency (most likely by the fact the path contains 'node_modules') and then resolve it as such -- including an npm-purl so that it can be correctly recognized by other tooling and vulnerabilities and license information can be retrieved.

The worst part is that there can actually be some exceptions to the above, where the podspec is actually in the 'node_modules' folder and the pod actually is known in OSS Index, but not in the specific version used here... This is a construct that just baffles me -- why not simply release the actual version of the pod so security companies can verify them and have data available for us devs!?

This same problem also exists for the android side of Expo/React-Native projects, however in 'cdxgen' a solution was implemented (by myself actually, but I'm afraid I don't know ruby so am not much help here -- maybe I could give ruby a go during the holidays...).

I hope this explains the issue a bit better/more...