Why Dependency Records Matter

What a dependency record is

Most software is assembled, not written from nothing. A team writes some of the code and brings in components written by others. A dependency record is a list of those components. The formal version is called a software bill of materials. In 2021 the U.S. National Telecommunications and Information Administration defined it as "a formal record containing the details and supply chain relationships of various components used in building software."

The Centers for Medicare and Medicaid Services describes the same idea more plainly, as a list of all components, licenses and versions in a piece of software.

What the record is for

The NTIA report says a bill of materials is useful to those who produce, purchase and operate software. It says the data helps producers and operators assess the risk of a newly found vulnerability more quickly and accurately. It also notes that license management was an early use case.

The Centers for Medicare and Medicaid Services lists three benefits for its own systems: transparency, vulnerability tracking and auditing. Its page says that knowing the components helps confirm that only authorized dependencies are included in a software project.

We think the value is easiest to see on the day a flaw is announced in a widely used component. A team with a current record can look up whether it uses that component. A team without one has to search. We offer this as an illustration, not as a finding.

What a useful record contains

The NTIA report sets out seven baseline data fields: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of the data, and timestamp. It says the record should contain all top level components, with all their transitive dependencies listed. In plain terms, that includes the components that your components rely on in turn.

The report also says that when a component is updated, a new record must be created to reflect the new version of the software. We think a record written once and then left alone describes software that no longer exists.

What it does not do

The NTIA report is direct about the limits. It states that a bill of materials "will not solve all software security problems." We think that is right. A list tells you what is present. It does not tell you whether a component is safe, whether your use of it exposes a flaw, or whether a fix exists. Those questions need separate work.

Leopard Source and Leopard Ops are designed to serve outside customers as well as our own portfolio. We treat our own practice as a worked example of this habit, not the limit of it. We have described only the general idea here, and we have relied on two public documents, both linked below. If you read them and think we have misstated either, please tell us.