Modern software applications are stitched together from thousands of third-party components fetched from public repositories. This reuse of code has major benefits for the software industry, reducing development time and costs and allowing developers to add functionality faster, but it also generates major vulnerability management problems due to the complex system of dependencies that are often hard to track.
Vulnerabilities inherited from third-party code have plagued applications for years, but in the age of government-sponsored software supply chain attacks, the problem is more relevant than ever. Software composition analysis tools can help uncover some of these risks, but subtle dependency blindspots still exist that make it hard for even security-conscious developers to catch all inherited flaws.
A recent scan of the NuGet repository by security researchers from ReversingLabs uncovered 50,000 packages that were using an outdated and vulnerable version of a popular library called zlib. Many of them did not explicitly list it as a dependency.
Dependency tracking is hit and miss
In order to discover all vulnerabilities, developers need to track not only which components they use in their own applications, but also the third-party libraries and packages those components are based on. The dependency chains can go many layers deep. An analysis performed in 2019 by researchers at Darmstadt University on the npm repository found that on average importing a JavaScript package introduced implicit trust for 79 other packages from 39 different maintainers. At the time, the researchers also found almost 40 percent of packages relied on code with at least one publicly known vulnerability.
