Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
malice00 opened this issue Sep 14, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@malice00
Copy link

malice00 commented Sep 14, 2024

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
Copy link
Contributor

macblazer commented Oct 13, 2024

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
Copy link
Author

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.

@macblazer macblazer added the enhancement New feature or request label Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants