Open-source dependencies are the libraries of open-source code that a program uses, but that its own developers did not write. A library is a ready-made piece of code that does one job, such as reading dates or writing log files. Open source means the code is published, and anyone may use it under the terms of its licence. Most of the code inside a modern app comes from such libraries, and so do many of the security flaws.
Here is how it works in general. A developer adds one library to the app with a single line. A tool called a package manager downloads it from a public repository. That library usually needs other libraries, and those need others again. These are called transitive dependencies, and an app can end up with hundreds of them. The build packs all of them into the finished app. When a flaw is later found in any one of them, and is given a CVE number, every app that contains that version is open to attack until it is updated.
The best-known case is Log4j, a widely used library that Java programs use to write log files. In December 2021, a flaw in it became public: an attacker could make it run their own code, just by sending it a specially written line of text to record. Log4j was inside thousands of products, often several layers down, as a dependency of a dependency. Many companies spent weeks just finding out where they used it.
Take, for example, a team that has to answer that question quickly. Software composition analysis reads the list of libraries in each app, and a software bill of materials, or SBOM, records every one of them.
Consider the packaged image that an app ships in. Container image scanning finds old libraries inside it, including ones the app never uses, so that the team can remove them and their flaws.
Say an AI coding assistant suggests a library. AI code governance checks that the library exists, is current and is free of known flaws, before the code is accepted.
How are open-source dependencies different from a supply chain attack? A flaw in a dependency is usually a mistake, which attackers later find and use. In a supply chain attack, the attacker deliberately plants harmful code, for example by publishing a fake package with a name close to a popular one. Open source as a way of earning money is a separate topic, covered in open source business model.
Appears in
- Software composition analysis (SCA) and SBOM↗ Enterprise cybersecuritySCA lists every open-source library inside an app, including the libraries that those libraries use.
- Container image scanning↗ Enterprise cybersecurityContainer image scanning finds open-source packages inside the image that the app does not even use.
- AI code governance↗ Enterprise cybersecurityAI code governance checks each open-source library that an AI assistant suggests, before the developer adds it.
- Artifact registry↗ DevOpsAn artifact registry stores approved copies of open-source libraries, so builds do not download them straight from the internet.