← 研踪 PaperTrailarXiv:2408.02846 · v3
What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls
首次提交 2024-08-06 06:01
版本更新 2026-10-26 11:53
雷达观测 2026-10-29 00:36
摘要
The Log4Shell vulnerability occurred because the JNDI (Java Naming and Directory Interface) lookup feature was used, even though it was not needed for log4j's core functionality. This case illustrates why developers may want visibility into the sensitive capabilities available through a dependency. The presence of a call alone does not establish that the call is unnecessary or risky. Security-sensitive APIs provide access to security-sensitive resources, such as filesystem, network, or process-related resources. If developers know which types of sensitive resources a dependency can access, they can control their dependencies at a finer grain, and they can consider an alternative dependency when a dependency makes unnecessary or suspicious security-sensitive API calls. However, prior work has not provided a documented, repeatable procedure for deriving an ecosystem-specific security-sensitive API list, so developers lack systematic visibility into the sensitive capabilities of their dependencies. The goal of this study is to aid developers in understanding sensitive resources accessible to their dependencies by identifying security-sensitive APIs in packages through an empirical study of Java packages. In this study, we present a novel and repeatable methodology to construct a security-sensitive API list for an ecosystem, and we apply it to Java. We then compare the security-sensitive API calls of functionally similar Java packages. The number of security-sensitive API calls (call level) ranges from 0 to 368 in one capability and from 0 to 429 in total among packages with similar functionality. These packages also differ in capability breadth, the number of the 15 capabilities that a package reaches. For example, capability breadth ranges from 0 to 10 in the "Dependency Injection" category and from 0 to 13 in the "Web Frameworks" category.
观测到的版本
相邻记录可能跳过中间版本；首次发现 v2 及以上也会标为版本更新。
v3 · 2026-10-26 11:53 · 最新观测版本
What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls
The Log4Shell vulnerability occurred because the JNDI (Java Naming and Directory Interface) lookup feature was used, even though it was not needed for log4j's core functionality. This case illustrates why developers may want visibility into the sensitive capabilities available through a dependency. The presence of a call alone does not establish that the call is unnecessary or risky. Security-sensitive APIs provide access to security-sensitive resources, such as filesystem, network, or process-related resources. If developers know which types of sensitive resources a dependency can access, they can control their dependencies at a finer grain, and they can consider an alternative dependency when a dependency makes unnecessary or suspicious security-sensitive API calls. However, prior work has not provided a documented, repeatable procedure for deriving an ecosystem-specific security-sensitive API list, so developers lack systematic visibility into the sensitive capabilities of their dependencies. The goal of this study is to aid developers in understanding sensitive resources accessible to their dependencies by identifying security-sensitive APIs in packages through an empirical study of Java packages. In this study, we present a novel and repeatable methodology to construct a security-sensitive API list for an ecosystem, and we apply it to Java. We then compare the security-sensitive API calls of functionally similar Java packages. The number of security-sensitive API calls (call level) ranges from 0 to 368 in one capability and from 0 to 429 in total among packages with similar functionality. These packages also differ in capability breadth, the number of the 15 capabilities that a package reaches. For example, capability breadth ranges from 0 to 10 in the "Dependency Injection" category and from 0 to 13 in the "Web Frameworks" category.
查看此版本解读 →查看此版本原文 ↗