Vulnerable Open Source Dependencies: Counting Those That Matter

[PRE-PRINT]

• The pre-print identifies the paper as appearing in the 2018 proceedings of the 12th International Symposium on Empirical Software Engineering and Measurement.Source: [PRE-PRINT] · p. 1

ABSTRACT

• The proposed methodology combines code-based patch analysis with repository information on build, test, update dates, and group.Source: ABSTRACT · p. 2
• The study examined 200 popular OSS Java libraries used by SAP, covering 10,905 distinct GAVs across library versions.Source: ABSTRACT · p. 2
• 20% of vulnerable dependencies are non-deployed, while developers of the analyzed libraries are responsible for fixing 82% of deployed vulnerable dependencies.The study also reports that 81% may be fixed by updating to a new version, while 1% are halted and may require costly mitigation.Source: ABSTRACT · p. 2

KEYWORDS

• The listed keywords are vulnerable dependency, open-source software, and mining software repositories.Source: KEYWORDS · p. 2

1 INTRODUCTION

• Existing approaches may miss deployment scope, transitive vulnerabilities, halted dependencies, and libraries maintained and released together, distorting vulnerability measurements.The introduction notes prior work on dependency scopes, direct dependencies, and transitive security issues [9].Source: §1 · p. 2
• The paper contributes a measurement methodology, a Maven-based analysis tool, and a study reporting 20% non-deployed vulnerable dependencies and 82% directly fixable by analyzed developers.Source: §1 · p. 2
• Under a conservative model, 14% of dependencies are halted and receive no updates, so their vulnerabilities may require costly mitigation.Source: §1 · p. 3

2 TERMINOLOGY

• A deployed dependency is delivered with the application or system, while a halted library has passed its estimated next release time by a wide margin.The terminology also distinguishes direct from transitive dependencies and own from third-party dependencies.Source: §2 · p. 3

3 PROBLEM STATEMENT

• A complete bill of materials is a necessary preliminary step to determining which project dependencies are vulnerable and assessing their risk and mitigation effort.Source: §3 · p. 3
• Existing approaches may miscount risk by including development-only dependencies, treating own libraries like third-party ones, or overlooking halted libraries.Source: §3 · p. 3

RQ1: How many actually vulnerable dependencies does a library have?

• Non-deployed test or development dependencies cannot be exploited in the released product, and including them can inflate vulnerable-dependency counts.Prior studies do not always state explicitly whether they exclude non-deployed dependencies.Source: RQ1: How many actually vulnerable… · p. 3

RQ2: Who is responsible for vulnerable dependencies?

• A project's own libraries are maintained and released together, so fixing vulnerable own code belongs in that project's development rather than being treated as an external dependency update.The paper warns that failing to distinguish own from third-party libraries can make a project appear to have a broader ecosystem problem.Source: RQ2: Who is responsible for vulnerable… · p. 4
• M can control transitive y2 by choosing a suitable version of its direct dependency y1, because both belong to project Y.Source: RQ2: Who is responsible for vulnerable… · p. 4
• Project Y is responsible for keeping z1 current when it enters M transitively through Y; making z1 direct would break black-box dependency management.Source: RQ2: Who is responsible for vulnerable… · p. 4
• A halted x1 has no later version to fix a vulnerability in x1 or adopt a fix for its dependency u1.Source: RQ2: Who is responsible for vulnerable… · p. 4

RQ3: How many direct dependencies can be actually fixed?

• Updating a vulnerable direct dependency is usually the simplest mitigation, but becomes impossible when its library is inactive and no fixing version will appear.The paper treats halted dependencies separately because their users may need to contribute to or fork the library.Source: RQ3: How many direct dependencies can… · p. 4
• A halted direct dependency may have no fixed release and can keep an outdated transitive dependency vulnerable, even when the direct dependency is current.Mitigations may require contributing a new release or forking the halted library.Source: RQ3: How many direct dependencies can… · p. 4

Observation: Name-Based vs Code-Based vulnerability matching

• CPE names are coarser than Maven coordinates, so mapping vulnerabilities by name can produce false positives and false negatives, including when only one artifact is affected [12].The NVD may also over-approximate vulnerable versions as a component and all previous versions [12].Source: Observation: Name-Based vs Code-Based… · pp. 4–5

4 METHODOLOGY

• The methodology is language-independent when a dependency-management mechanism is available, and the paper demonstrates it using Java and Maven.The authors chose Maven as the demonstration system while noting that the concepts can extend to other dependency managers.Source: §4 · p. 5

4.1 Dependency resolution

• Maven dependency:tree and dependency:resolve construct each library instance’s dependency tree and resolve conflicts and duplications.The corresponding POM files must first be installed in the local repository.Source: §4.1 · p. 5

4.2 Post-processing of the results

• Post-processing excludes provided and test dependencies because they are not shipped, then aggregates results from vulnerable dependencies back to analyzed libraries.Within each path, GAVs sharing a groupId are grouped and represented by the GAV closest to the vulnerable one.Source: §4.2 · p. 5
• The halted-library estimate uses smoothed release intervals to estimate the next release date, classifying a library as halted when that date precedes TIME.The model uses α = 0.6; for libraries with fewer than three releases, the last release interval is set to three months.Source: §4.2 · pp. 5–6, §4.3 · p. 6
• Because release intervals vary with release strategy and library maturity, the release-date model is conservative and may classify a still-developed library as halted.A manual check of 100 libraries identified as halted found no cases falsely reported as halted.Source: §4.2 · pp. 5–6

4.3 Identification of vulnerabilities

• Code-based matching identifies vulnerable code from manually analyzed fixing commits, then checks whether those code fragments occur in a project’s dependencies.This addresses the coarse granularity of standard vulnerability sources such as the NVD.Source: §4.3 · p. 6

4.4 Dependency resolution tool

• The tool wraps Maven’s dependency commands, annotates resolved trees with vulnerability information and dependency paths, and produces simplified human-readable reports.Source: §4.4 · p. 6

• Counting direct dependent library instances as a popularity proxy over-represented Scala and Spring Framework projects and omitted Apache Tomcat from the initial top-100 list.The authors note that projects with many own libraries could inflate a library instance’s usage count.Source: §5 · pp. 6–7
• Vulnerable dependencies that are not deployed cannot be exploited in the analyzed library instances and therefore introduce no danger to them.Source: §5 · p. 7
• The final sample comprised 200 OSS libraries used across more than 500 SAP Java projects, representing 10,905 library instances across versions.Examples included slf4j-api and Apache HttpClient.Source: §5 · p. 7

6 RESULTS AND DISCUSSION

• 148 of 10,905 analyzed library instances included own dependencies, which were not vulnerability-affected but could add noise to resource planning.The paper notes that such dependencies can introduce noise when creating a bill of materials.Source: §6 · pp. 7–8
• Grouping dependencies by software projects revealed that developers of analyzed libraries could directly fix 82% of deployed vulnerable dependencies, specifically direct vulnerable dependencies.Source: Table 2 · p. 8, §6 · p. 8
• 20% of direct and 22% of transitive vulnerable dependencies are non-deployed; non-deployed dependencies also comprise 45% of direct and 34% of transitive dependencies overall.The study argues these vulnerable dependencies do not endanger the analyzed library because they are not deployed.Source: §6 · p. 7, Table 2 · p. 8
• Grouping reveals up to eight additional vulnerable dependencies under the direct control of an analyzed library's developers.The grouping procedure identifies vulnerabilities in own libraries and direct dependencies.Source: §6 · pp. 7–8
• Five library instances had vulnerable transitive dependencies through halted direct dependencies, requiring developers to make those dependencies direct to mitigate the vulnerabilities.Safe versions existed but would not be adopted by the halted libraries.Source: §6 · p. 8
• 14% of dependencies in the sample are halted, and 1% are both halted and affected by known vulnerabilities, requiring costly mitigation.Among halted dependencies, 13% of direct and 16% of transitive dependencies are halted; 69 direct and 5 transitive halted dependencies were vulnerable.Source: §6 · p. 8
• In the simulation, an average library had a 9.5% chance of a vulnerable halted dependency, with at most two such dependencies.The simulation assumed 12 direct dependencies per typical industrial library and constructed dependency trees for 100 software projects.Source: §6 · p. 8

7 IMPLICATIONS ON INDUSTRIAL PRACTICE

• Incorrect vulnerability assessments can waste audit and development effort across products with long support periods and increase the chances of security incidents and financial loss.SAP continuously monitors third-party dependencies during products' operational lifetimes and must audit, assess, and mitigate findings.Source: §7 · p. 9
• About 20% of vulnerable dependencies are non-deployed, so filtering them avoids treating components absent from the deployed product as exploitable risks.The paper says this distinction supports pre-filtering and avoids misallocating development and audit resources.Source: §7 · p. 9
• Grouping dependencies by software project can reveal which vulnerable components the analyzed library's developers can update, including when the vulnerable node is deeper in the tree.Without grouping, the needed update may appear to require action on a deeper node even when a shallower dependency can be updated.Source: §7 · p. 9
• For a maintained dependency without a fixed release, mitigation may need to be urgent and temporary; for an unmaintained dependency, fixing it may require a costly, long-term internal fork.The eventual upgrade to a non-vulnerable release is described for the maintained case.Source: §7 · pp. 9–10

8.1 Dependency Studies

• Earlier studies reported vulnerable dependencies in Maven libraries and npm modules, but the npm study did not distinguish deployed from non-deployed dependencies.The paper notes that omitting this distinction may include low-priority findings.Source: §8.1 · p. 10
• Lauinger et al. [9] found transitive dependencies more likely to be vulnerable in JavaScript projects; the paper cautions that this pattern may not transfer directly to Maven's single-version resolution.Kula et al. also report outdated dependencies and owner unawareness, while discussing developers' motivations for keeping dependencies.Source: §8.1 · p. 10
• Cox et al. analyze direct dependencies from pom.xml without Maven resolution or an explicit non-deployed filter, while this study includes transitive dependencies and code-level matching.The authors also note that name-based CVE matching can produce false positives.Source: §8.1 · p. 10

8.2 Identification of Vulnerable Dependencies

• OWASP Dependency Check matches library names to CPE versions in NVD vulnerability descriptions, relying on the information available in NVD.The tool automatically extracts project dependencies and checks them against known vulnerabilities.Source: §8.2 · p. 10
• VAS inherits name-to-CPE matching's false positives and was limited to direct dependencies, although vulnerabilities can also enter transitively.Source: §8.2 · p. 10
• The semantic-web mapping approach of Alqahtani et al. had 5% lower precision than OWASP Dependency Check, while this paper relies on patch-based vulnerability mapping [14] [15].Source: §8.2 · p. 10

9 THREATS TO VALIDITY

• Libraries were selected by usage within SAP, which may not represent those most relevant to other companies or OSS developers, though external popularity checks led the authors to view this threat as minimal.Source: §9 · p. 11
• The vulnerability database may omit known vulnerabilities; an internal check found coverage of 90% of NVD vulnerabilities for Java OSS projects and closer to 100% for projects most relevant to SAP.Source: §9 · p. 11
• The tool currently supports Maven projects, although the authors state that the methodology itself may extend to other build systems such as Ant or Gradle.Source: §9 · p. 11
• Using Maven groupIds as project proxies may merge distinct projects or split components of one project; additional attributes such as Repository or ProjectID could distinguish ambiguous cases.Source: §9 · p. 11

10 CONCLUSIONS AND FUTURE WORK

• The tool uses Apache Maven to extract dependencies, code-level matching to identify known vulnerabilities, and post-processing to filter non-deployed components, group projects, and identify halted dependencies.Source: §10 · p. 11
• Every fifth vulnerable dependency was non-deployed; grouping identified 82% of vulnerable dependencies as developers' responsibility to fix, 45% more than a regular approach.The study also found 14% of dependencies halted, and simulation showed a positive impact on resolving one industrial library's analysis results.Source: §10 · p. 11
• Future work includes studying npm and pip, analyzing all Maven Central libraries, automating halted-library identification, and investigating developers' security-update behavior.Source: §10 · p. 11