You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
The text was updated successfully, but these errors were encountered:
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.
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.
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...
The text was updated successfully, but these errors were encountered: