Follow the Product: Provenance, Dependencies, and Tiers
For a software buyer, provenance is not a sentence about where a product was written. It is a time-bound account of how the product and its components originated, changed, moved through suppliers, and became the release under consideration. This chapter follows that chain from development to release and then below the direct supplier, showing what an SBOM, a signature, or a dependency record can establish—and what each leaves unresolved. The practical goal is to choose a useful depth of investigation without confusing an inventory with proof.
The distinction matters because a product can cross several boundaries before it reaches an acquirer. A company may sell the product, another organization may maintain an upstream component, a build system may assemble the release, and a third party may host or distribute it. Each boundary can introduce a new owner, location, change process, or dependency. The evidence needs to preserve those transitions instead of compressing them into the reassuring phrase “built in-house.”
Provenance is a chain of changes, not an origin label
NIST defines provenance as the chronology of the origin, development, ownership, location, and changes to a system or system component, together with associated data, personnel, and services. It includes analyses of component and subcomponent inventories, such as hardware and software bills of materials. For software, the relevant scope includes open-source and third-party source code, proprietary development, and the supply chain of vendors or resellers.
That definition has a useful consequence: provenance is not one field. It is a relationship among an object, its transitions, and the evidence that records those transitions. “This product comes from our engineering team” may be a reasonable description, but it does not answer who owns the code, which external components enter the build, which organization publishes the release, or what changed between the reviewed source and the delivered artifact.
NIST makes the evidentiary standard explicit in its discussion of pedigree: under the related control, pedigree is the validation of provenance with evidence. The difference is between an origin story and a supported chronology. A buyer may begin with a supplier's statement, but the statement becomes more useful when it can be connected to source repositories, component inventories, release records, and verifiable relationships. The evidence does not have to be public in every case; it does have to be specific enough to support the claim being made.
For a software product, it helps to separate several questions that are often merged:
- Origin: Where and by whom did the relevant code or component begin?
- Development: Which people or organizations could modify it, and through what process?
- Ownership: Which legal or organizational entity controls the component or release?
- Location: Where do important development, storage, build, or service activities occur?
- Change: What was added, removed, or replaced before the version under review was published?
These questions are related, but evidence for one does not automatically answer the others. A public source repository may reveal development activity and some history. It may not establish the legal ownership of a company or the location of every build operation. A release page may identify an artifact. It may not prove that the artifact came from the source revision a buyer inspected. A product-specific review should keep those claims separate.
An SBOM is one way to make the component relationship visible. NIST describes a software bill of materials as a formal record of the details and supply-chain relationships among components used to build software, including open-source and third-party dependencies. Machine-readable formats such as CycloneDX, SPDX, and SWID allow automated ingestion, validation, and analysis. That makes an SBOM valuable because it can turn an implicit dependency into an object that can be searched, prioritized, and compared with vulnerability information.
But visibility is not the same as assurance. NIST states directly that having an SBOM does not automatically mean the software is secure. The record enables a more tailored risk assessment; it does not complete that assessment. A buyer still has to ask whether the inventory describes the product and release in scope, whether important components are missing or unknown, whether the listed versions are current, and whether the relationships are supported by the producer of the artifact.
The distinction can be expressed as a ladder:
- Presence: An SBOM or release file exists.
- Coverage: It describes the relevant product, version, and component relationships with enough completeness to use.
- Integrity: The record and artifact can be checked as the producer's unaltered outputs.
- Linkage: The artifact, source revision, build process, and component inventory are connected.
- Interpretation: The acquirer understands which vulnerabilities, end-of-life components, or concentrated maintainers could affect the intended system.
Each step answers a stronger question. Evidence at the first step should not be written up as if it reached the fifth. OpenSSF Scorecard's documentation reflects this distinction. Its SBOM check looks for an SBOM in source, pipeline, or release contexts and treats a release-artifact SBOM as the preferred form. That is useful visibility into whether an inventory is published, but it does not by itself prove completeness or security.
Release signatures create a similar trap. A signature or provenance file beside an artifact is more informative than no corresponding file, but the filename alone is only a presence signal. Scorecard's Signed-Releases check looks for recognized signature and provenance asset names across releases; the documentation explicitly says that the check does not verify the signatures. Verification requires a trusted key or identity, a valid cryptographic relationship, and a clear answer to what was signed. It also requires knowing whether the signed object is the artifact the acquirer will use.
The relationship model is deliberately unfinished. The unresolved link is part of the evidence. A component may be listed without a clear supplier relationship; a release may be signed without a verified identity; a product may depend on a service or subcomponent that is not represented in the available record. An honest product map shows those gaps rather than drawing a solid line where the source only suggests one.
For the acquirer, the useful record is therefore not “SBOM: yes” or “signed release: yes.” It is closer to: an inventory was found for this release; it names these component relationships; this source supports the claim; the signature artifact is present or verified to this extent; and the following linkage or coverage remains unknown. That form can drive a precise next question. It can also prevent a supplier from receiving credit for an artifact that belongs to another version or product.
Go deeper only when the next relationship can change the decision
Provenance does not stop at the direct supplier. NIST organizes suppliers into tiers based on their relationship to the end user. A first-tier supplier provides products or services directly to the end user. A second-tier supplier provides products or services to a first-tier supplier, and the chain can continue to a depth the organization chooses.
The point of tier analysis is not to create an impressive diagram. It is to discover relationships that alter the risk of the product or the system that depends on it. Several direct suppliers may rely on the same sub-tier component. A small project may depend on a single maintainer for updates. A reseller may obscure which organization actually develops or hosts a component. A dependency that appears minor in a product description can become significant when it is shared across many systems or has no practical substitute.
This is why software dependencies and commercial tiers should be connected but not conflated. A package name in a manifest can show that one project consumes another software component. It may not identify the component's ultimate legal owner, hosting arrangement, development location, or operational dependency. Conversely, a supplier relationship chart may identify a subcontractor without exposing the exact library or build input that crosses the technical boundary. The acquirer needs both views when the relationship could change the decision.
Scorecard can contribute to the software side of that view. Its dependency-related checks can reveal unpinned inputs, known vulnerabilities, and some release or component signals. Its raw result structures can preserve dependency locations and package or release observations for later review. Those outputs may help an analyst ask which components are critical, which are shared, and which have credible update paths. They do not automatically map the complete commercial, legal, or operational supply chain. A repository observation is evidence about the observed repository and detection method, not a finished tier map.
NIST also identifies a tension in sub-tier diversity. As the investigation moves farther from the end user, the supplier portfolio becomes larger, which can increase visibility into concentration but also increase the chance of encountering a supplier on a watchlist, exclusion list, or regulatory noncompliance list. More suppliers are not automatically safer. Diversity can reduce dependence on one source, while a large and poorly understood portfolio can make governance harder. The relevant question is how the particular relationship affects the system's exposure and the organization's tolerance for it.
The cost of visibility is therefore part of the mechanism. NIST warns that going farther down the tier structure increases understanding but makes the difficulty and cost increase exponentially. That means “investigate every dependency” is not a neutral instruction. It can consume time without improving the decision, delay a useful procurement, and create a false impression of completeness when the map is still changing.
A defensible stopping rule asks four questions about the next relationship:
Could it change the decision? Continue when the next tier might reveal a prohibited entity, a common single source, a critical vulnerability, an unsupported component, or a concentration that the current decision does not tolerate. Stop or defer when the relationship is demonstrably immaterial to the intended use and no applicable concern level is crossed.
Is the relationship technically or commercially material? For logic-bearing components, NIST suggests considering whether they store, send, save, assess, or transmit data; in a software review, that question can help distinguish a component with direct system impact from an incidental development utility. A supplier that can alter the delivered artifact deserves more attention than a distributor with no control over the build. The available evidence should state which assumption makes the relationship material.
What evidence would resolve the uncertainty? If the public record identifies a dependency but not its maintainer, ask for a signed inventory, release linkage, or an explanation of the build boundary. If the concern is about ownership or jurisdiction, a source-control scan is the wrong instrument; the acquirer needs corporate or legal evidence. If the concern is product performance or continuity, a repository result cannot substitute for operational evidence.
What will be lost by going deeper? Research depth has opportunity costs. It can postpone a needed decision, overwhelm reviewers with low-value detail, or encourage the team to treat an ever-growing map as its objective. Record why the investigation stopped and what event would reopen it. A stopping point is defensible when it is tied to criticality and risk tolerance, not when it is merely convenient.
These questions also explain why a deeper tier review may be necessary even when the direct supplier looks strong. Suppose the direct supplier has good source-control practices and publishes an SBOM. If several products all depend on the same sub-tier library, the common dependency may still be a systemic exposure. If the SBOM lists a component but the release cannot be linked to the listed source, the inventory has not completed the provenance chain. If the supplier's product is mission-critical, the cost of investigating those relationships may be justified even when no immediate failure is visible.
The reverse case matters too. A low or incomplete technical signal does not automatically mean that a product must be rejected. It may reflect an implementation that the tool does not recognize, a release model outside the check's scope, or an evidence gap that a supplier can resolve. The appropriate response depends on whether the missing evidence is material, whether an independent artifact can corroborate the claim, and whether the organization can accept the remaining uncertainty. This is why evidence-first diligence needs an escalation path rather than a single green-or-red result.
At the end of provenance and tier analysis, the acquirer should be able to answer a narrower question than “is this vendor secure?” The question is: what product and release are we evaluating; what components and supplier relationships are visible; which transitions are supported by evidence; where does the chain become uncertain; and which unresolved relationship could change our decision? The answer can be incomplete and still be useful, provided the incompleteness is explicit.
That is the point at which the initial research becomes an evidence packet rather than a pile of artifacts. Identity, criticality, provenance, dependencies, tiers, source strength, and unresolved gaps can now be reviewed together. The packet is still not a verdict. It is a map of what is known and what deserves the next unit of attention—before a technical evidence tool is asked to add more detail.