  Although using third-party libraries is common practice when writing
software, vulnerabilities may be found even in well-known libraries. Detected
vulnerabilities are often fixed quickly in the library code. The easiest way to
include these fixes in a dependent software application, is to update the used
library version. Package managers provide automated solutions for updating
library dependencies. However, library dependencies can have dependencies to
other libraries resulting in a dependency network with several levels of
indirections. Assessing vulnerability risks induced by dependency networks is a
non-trivial task for software developers. The library dependency network in the
Swift ecosystem encompasses libraries from CocoaPods, Carthage and Swift
Package Manager. We analysed how vulnerabilities propagate in the library
dependency network of the Swift ecosystem, how vulnerable dependencies could be
fixed via dependency upgrades, and if third party vulnerability analysis could
be made more precise given public information on these vulnerabilities. We
found that only 5.9% of connected libraries had a direct or transitive
dependency to a vulnerable library. Although we found that most libraries with
publicly reported vulnerabilities are written in C, the highest impact of
publicly reported vulnerabilities originated from libraries written in native
iOS languages. We found that around 30% of vulnerable dependencies could have
been fixed via upgrading the library dependency. In case of critical
vulnerabilities and latest library versions, over 70% of vulnerable
dependencies would have been fixed via a dependency upgrade. Lastly, we checked
whether the analysis of vulnerable dependency use could be refined using
publicly available information on the code location (method or class) of a
reported vulnerability. We found that such information is not available most of
the time.
