我目前正在研究一个大型的遗留项目，并试图修复OpenSSL漏洞问题，如How to address OpenSSL vulnerabilities in your apps所述。如何确定哪些依赖性会导致Google Play OpenSSL警告？
问题是，有很多依赖关系，有些是开放源代码（我更新了所有没有打破兼容性的问题）作为Gradle导入添加，有些是由合作伙伴和公司承包商提供的自定义/关闭源作为JAR工作并附属于该项目。
有没有什么方法可以查明具有此漏洞的特定库？我使用了Google Play and OpenSSL warning message提供的bash脚本，它指向一个本地依赖项（实际上是.so文件）。有没有任何选项可以从那里查明实际的依赖关系？
有没有任何选项可以从那里查明实际的依赖关系？
是的，但你需要知道有问题的OpenSSL版本，你需要grep。 Windows find不会。
首先，注意违规的OpenSSL版本。为了争辩，说它的原因是OpenSSL 1.0.1h。
接下来，收集您的依赖关系及其顶级文件夹的列表。为了便于讨论，说其$HOME/Desktop/aosp-app，$HOME/sdk-a，/usr/local/sdk-b和/opt/local/sdk-c。
最后，对于顶级目录：
grep -R '1.0.1h' "$HOME/Desktop/aosp-app"
grep -R '1.0.1h' "$HOME/sdk-a"
grep -R '1.0.1h' /usr/local/sdk-b
grep -R '1.0.1h' /opt/local/sdk-c
你不需要grep -iR，这是一个不区分大小写（-i）递归（-R）搜索。您也不需要grep -IR，这是一个跳过二进制文件（-I）的递归（-R）搜索。
所有这些都是有效的，因为OpenSSL库将它的版本作为字符串嵌入数据部分。最终，你会遇到罪魁祸首，这可能是一个作为共享对象预先构建的SDK，但包含OpenSSL作为静态库。一个SDK似乎经常被识别出来，它使用的cURL是针对静态OpenSSL库构建的。
如果你有JAR files and suspect them，那么你可以执行以下的快速测试：
find <dir> -name '*.jar' -exec grep -R '1.0.1h' {} \;
该命令将查找的目录<dir>及其子目录。它将搜索扩展名为*.jar的文件。当它找到一个，它会运行grep上寻找字符串。 find会为它找到的每个*.jar。