The review has examined the mechanisms that come nearest to the problem one at a time. This entry and the one that follows widen the lens to the two fields those mechanisms belong to, because a claim about a gap is stronger when it is set against a surveyed landscape rather than a handful of isolated specifications. The first field is software supply-chain security, the mature discipline for establishing that an artefact can be trusted not because it looks right but because its origin and integrity have been attested.
A field organized around three properties
Software supply-chain security has, in recent years, been systematized into a small and clarifying set of properties. A recent systematization of knowledge organizes the whole field around three (Okafor et al., 2024). Transparency is knowing what is in the chain, provided by bills of materials and by transparency logs that record signing events in an auditable ledger. Validity is the chain remaining correct, in the specific sense that components are unchanged by unauthorized parties and the actors who change them are authenticated. Separation is compartmentalizing the chain so that a compromise in one place cannot propagate to another. Against these three the field sets a four-stage picture of how supply-chain attacks unfold, from an initial compromise, through alteration and propagation, to eventual exploitation downstream, with the SolarWinds intrusion as the worked example.
This framing is useful here because it lets the field be judged on its own terms rather than through the narrow lens of a single tool. And judged on its own terms, it draws the line this work depends on.
What integrity establishes, and what it leaves open
The validity property is the one that matters, and it is worth being exact about what it does. It establishes that an artefact is the unchanged output of an authorized process. It does not establish that the artefact is correct, or safe, or fit for the use its recipient intends. Those are different questions, and the systematization is candid about the difference: it notes that heavy reliance on external components has decreased the confidence that systems only do what they are intended to do (Okafor et al., 2024). Signing and attestation restore confidence in provenance and integrity. The question of whether the thing then does what it should is left open.
That open question is admissibility, named in the supply-chain field's own words. The point is not a criticism of these mechanisms, which do their own job well. It is that their job is a different one. An attestation framework confirms that tampering has not occurred between the steps of a chain. It does not, and does not claim to, confirm that the output of a step is correct or that the artefact is fit to act on. Integrity is established; fitness is not. A perfectly attested component can still be the wrong thing to install, just as a perfectly signed claim can still be one that should not be acted upon. The supply-chain field has built an impressive apparatus for the first half of that sentence and has, by its own admission, left the second half open.
The software bill of materials, and where it stops
The transparency property has a flagship instrument worth examining in its own right, because it is the supply-chain field's most concrete answer to the question of what crosses a boundary, and because it is now mandated for software sold to the United States government under Executive Order 14028. A software bill of materials, in the defining government text, is "a formal record containing the details and supply chain relationships of various components used in building software" (NTIA, 2021). Its minimum elements are an inventory: for each component, the supplier, the component name, the version, unique identifiers, its dependency relationships, the author of the record, and a timestamp, expressed in a machine-readable format such as SPDX or CycloneDX. It is, in the guidance's own recurring phrase, an ingredients list.
What makes the bill of materials important for this review is that the field states its limit plainly, in the same document that defines it. An SBOM, the guidance says, "will not solve all software security problems, but will form a foundational data layer on which further security tools, practices, and assurances can be built" (NTIA, 2021). It provides "visibility and awareness", and it is "the necessary glue to allow the relevant external data to be mapped to the software products in question", but "external data may still be needed" and the judgement is made elsewhere, by a downstream tool or reasoner, on the strength of the inventory. This is the description-versus-adjudication line again, drawn by the transparency mechanism itself: the bill of materials records what is present; it does not judge whether what is present is fit for the use about to be made of it. Knowing that a component is in the product is not knowing that the product is safe to act on.
The bill of materials also inherits a trust problem the field has begun to measure. The first empirical study of SBOM practice, drawing on interviews and a survey of practitioners across fifteen countries, finds that the outstanding concerns cluster around trustworthiness, usability, and suitability, with practitioners uncertain whether an SBOM's contents can be relied upon, whether it is complete, and whether it is tamper-resistant (Xia et al., 2023). An inventory that may itself be incomplete or unverifiable is a weaker foundation than the mandate implies, which sharpens rather than softens the point: even the transparency the supply chain does provide is contested, and transparency was never the same thing as a judgement of fitness in any case.
The nearest the ecosystem comes to a judgement of fitness is a companion artefact, the Vulnerability Exploitability eXchange, and examining it shows exactly where the boundary falls. A VEX document "indicates the status of a software product or component with respect to a vulnerability", most commonly to state that the software "is or is not affected" by it (CISA, 2023). This is closer to admissibility than a bare inventory, because it is a statement about whether a known weakness actually matters in context rather than merely whether a component is present. But three features place it firmly on the descriptive side of the line. It is an assertion, authored by the supplier or a third party, whose author "is responsible for the content" and whose identity "SHOULD be cryptographically associated with the signature", so its trustworthiness rests on provenance of the claim, not on verification of the status. It is explicitly permitted to be partial: "VEX information may be incomplete", and it need not enumerate all products or components. And it conveys a status, affected or not, without carrying the basis on which that status was reached across to the receiver who must act. VEX is, in the precise vocabulary of this work, a conveyed claim of status backed by a signature over its origin, which is the very shape of object whose promotion to acted-upon fact this work exists to govern. The supply chain's closest approach to adjudication is itself an attestation of a claim, not an adjudication of its basis.
A principle worth carrying forward
One of the three properties deserves a note, because it recurs later in an unexpected place. Separation, the compartmentalizing of a chain so that compromise cannot propagate, is the same instinct that network security expresses as the demilitarized zone and that operational technology, examined next, expresses as zones and conduits. The supply-chain field arrives at it independently: trust should be attached and contained deliberately, never allowed to spread by proximity or assumption. That three separate disciplines reach the same conclusion is a thread this review picks up again, because it points at something the discipline this work proposes is built to honour.
References
NTIA (2021). The Minimum Elements for a Software Bill of Materials (SBOM), pursuant to Executive Order 14028. U.S. Department of Commerce. ntia.gov
Xia, B., Bi, T., Xing, Z., Lu, Q. and Zhu, L. (2023). An Empirical Study on Software Bill of Materials: Where We Stand and the Road Ahead. ICSE 2023. arXiv:2301.05362. arxiv.org/abs/2301.05362
CISA (2023). Minimum Requirements for Vulnerability Exploitability eXchange (VEX). Cybersecurity and Infrastructure Security Agency. cisa.gov
Okafor, C., Schorlemmer, T. R., Torres-Arias, S. and Davis, J. C. (2024). SoK: Analysis of Software Supply Chain Security by Establishing Secure Design Properties. arXiv preprint arXiv:2406.10109. arxiv.org/abs/2406.10109