Dependency Manifest
A dependency manifest is a text file in a software project that lists which external building blocks the project needs and in which version. It ensures that a program is built with exactly the same building blocks on every computer.
Almost no program is written entirely from scratch. Developers incorporate ready-made building blocks written by other people, such as a collection of mathematical functions or a tool for drawing charts. Such external building blocks are called dependencies, because the program itself won’t run without them. So that nobody has to keep track by hand of which ones are needed, there is a dedicated file for this purpose: the dependency manifest. It lists, line by line, which building block is needed in which version. A helper program reads this list and automatically downloads everything named from the internet.
Why a list decides on security
A medium-sized project can quickly accumulate several hundred dependencies. That’s because each included building block often brings along dependencies of its own. Without a manifest, nobody would know anymore what actually ends up in the finished program. This overview is precisely the foundation for everything that follows.
If a security vulnerability is found in a widely used building block, every company must immediately know whether it is affected. In the case of the Java library Log4j at the end of 2021, companies worldwide searched for days to find out. Those with well-maintained manifests could answer the question within minutes. Others needed weeks.
For this reason, authorities and large customers now frequently demand what is known as a Software Bill of Materials, or SBOM for short. This is a kind of ingredient list for software, generated from the manifests. AI projects are affected too, since they depend on many libraries for mathematics and graphics-card computation.
What’s in the file, and who reads it
Every programming language has its own format. In JavaScript, the file is called package.json; in Python, it’s usually requirements.txt or pyproject.toml. The content, however, is similar everywhere: a name and a version specification per line. An entry like “numpy 1.26.4” means that exactly this version is desired.
Often no fixed version is given, but rather a range. “At least 1.26, but under 2.0” allows small updates without risk. The downside: two people could end up with slightly different versions on different days. That’s why there is additionally a lockfile. It records which versions were actually installed, down to the last digit.
You can think of the manifest as a shopping list and the lockfile as a receipt. The list says what’s needed. The receipt says what actually ended up in the basket. A common mistake is to consider the lockfile unnecessary and not save it along with the project. Then the program runs on one’s own machine, but suddenly stops working on the server.
From school projects to supply chain attacks
Anyone looking at an open-source project on the GitHub platform will almost always find the manifest right in the main directory. A single command in the terminal is then enough to get the project running. The principle also comes up constantly when trying out AI models. Instructions typically begin with a line that downloads all the necessary libraries at once.
In the news, the term usually appears in connection with supply chain attacks. Attackers smuggle malicious code into a popular building block or publish a package with a deliberate typo in its name. Anyone who mistypes the entry in the manifest then installs the wrong package. This trick is called typosquatting and has already hit major companies.
For this reason, automated scanning tools are now part of everyday practice. They continuously scan a company’s manifests and report known security vulnerabilities. For investors, this is a market of its own, since entire companies make their living from this kind of software. The simple shopping list has thus become a central document of IT security.
