Component records: how a Nexus component is described, built, signed and traced

A component record is the linked set of records that lets someone other than its author answer five questions about a component: what it is, how it was built, what it depends on, for what it has been admitted, and what it must not be taken to be. A component can be a software package, a trained model, a dataset, a dashboard composition or an infrastructure image. In the Nexus Consortium, the public-good programme through which The Global Centre for Risk and Innovation (GCRI), The Global Risks Forum (GRF) and The Global Risks Alliance (GRA) help countries examine interconnected risk with shared methods, these records are kept by the Nexus systems that own each fact, and each record carries one identifier, a UNI under NS-1 ¹².

The earlier version of this page called this a "Stack Passport". The current model does not use a single passport document. It divides the record among systems, so that no one tool both builds a component and declares it fit: NXS-FAC (blueprints, builds and signing) builds and attests; NXS-NXQ (software, models and capability lifecycle) admits; NXS-GRX (canonical data, provenance and risk) holds data lineage; and NXS-NSF (trust, authorization and assurance) holds the trust root and the policy decisions ^1,2,3,4.

A component record is not a certificate, a conformity assessment, a procurement status or an endorsement of a supplier. It makes a component readable ^1,2.

Modern resilience work is assembled rather than written. A flood dashboard may combine public data, an open-source mapping library, a model trained elsewhere and a cloud image built by a third party. Each part may be sound; together they form a chain whose weakest link is often a component nobody chose deliberately.

The National Vulnerability Database records that CVE-2021-44228, published on 10 December 2021, allowed an attacker who could control log messages in Apache Log4j2 versions 2.0-beta9 to 2.15.0 to execute arbitrary code loaded from LDAP servers; NVD scored it 10.0 under CVSS 3.1 ⁵. The immediate question for every operator was not how the flaw worked but whether any of its systems contained an affected version. An inventory of components answers that question from a record; without one, the answer has to be searched for.

The second case is subtler. CVE-2024-3094, published on 29 March 2024, records malicious code in the upstream release tarballs of xz, starting with version 5.6.0, which modified the liblzma library during the build process; it too is scored 10.0 ⁶. Here the danger lay in the build, not in an ordinary bug, which is why the programme records how an artefact was built and approves the exact artefact rather than a name or a branch ¹.

The build record belongs to NXS-FAC. It pins the source snapshot, with commit, dependencies and generator versions; declares a build contract with the artefact kind, environment and reproducibility envelope; separates required from advisory checks and records actual results; and approves the exact artefact by its digest, not a mutable branch name ¹. It performs the signing act through a scoped signer identity and holds no key material: private keys stay in key custody under NXS-NSF, and signing and promotion credentials are kept outside the room and the browser ^1,4.

The admission record belongs to NXS-NXQ. It preserves each capability’s digest, provider identity and manifest version; binds admission evidence to a task, a data class, an evaluation suite and an expiry; keeps software, model weights, data and service terms separate in its licence constraints; and checks the dependency graph for incompatible, withdrawn or unpinned dependencies before a bundle is prepared ². It also handles revocation and recall ².

The data record belongs to NXS-GRX, which distinguishes absent, stale, disputed and measured quality and propagates a source correction to dependent products without rewriting old results ³. And the trust record belongs to NXS-NSF, which owns the trust root and key custody, with key rotation, revocation and compromise handling, and whose policy evaluation keeps deny, unknown and unavailable distinct ⁴.

The software bill of materials, or SBOM, is the most widely adopted part of such a record. Under Executive Order 14028, the US National Telecommunications and Information Administration published The Minimum Elements for a Software Bill of Materials on 12 July 2021, with seven data fields: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of SBOM data and timestamp ⁷.

On 29 July 2026 the Cybersecurity and Infrastructure Security Agency and partners released the 2026 Minimum Elements, which add fields such as component hash algorithm, component licence, SBOM tool name and SBOM generation context, and rename others: supplier name becomes component producer, version of the component becomes component version, and author of SBOM data becomes SBOM author ⁸. The direction of travel is clear: a minimal record now says not only what a component is but how the record about it was made.

Models and datasets need the same discipline. Model cards, proposed by Mitchell and colleagues, document a trained model’s performance characteristics and intended use; datasheets for datasets, proposed by Gebru and colleagues, document a dataset’s motivation, composition, collection process and recommended uses ^13,14. The programme’s proposed standard NS-12 covers software, models and AI and machine-learning artefacts, including supply chain, model cards and dataset sheets ¹⁵.

An SBOM lists ingredients; provenance records the kitchen. The SLSA specification, version 1.2, defines four levels on its Build track. Build L0 offers no guarantees. Build L1 requires provenance showing how the package was built, which helps against mistakes. Build L2 requires signed provenance generated by a hosted build platform, which protects against tampering after the build. Build L3 requires a hardened build platform, which protects against tampering during the build ¹⁶. Version 1.2 also reintroduces a Source track covering source code ¹⁶.

The programme’s build records follow the same logic without claiming a level. NXS-FAC requires pinned inputs, declared nondeterminism and independent rebuild comparisons for reproducibility, and its method boundary states that passing a fixture test is not production qualification ¹. Naming SLSA records a reference; no component of the programme is described as conforming to it.

Not every component is a package. Compute nodes, edge devices and images are components too, and their records belong to NXS-COR (compute, nodes and runtimes). It keeps each node observation with its capture time, trust state and desired versus observed configuration; requires workload requirements to state architecture, accelerators, memory, storage, residency and network assumptions; and rejects infeasible placements before any cost optimisation ¹⁷. Its method boundary is the infrastructure version of the same rule: a feasible simulation is not proof that a node is reachable or attested ¹⁷.

Compositions such as dashboards and workflow screens are components as well. NXS-STU binds each composition to its component tree and source references and validates data types, units, permissions and lifecycle compatibility, and it relies on NXS-NXQ for the capability and package registry, so that a dashboard is assembled only from admitted parts ^18,2. The record of a composition is therefore a record of records: it points to the admitted components it uses, each with its own digest and history.

The most important property of a component record is what it refuses to say. A research finding in NXS-LAB (research, experiments and simulations) does not automatically admit or deploy a capability; it becomes a promotion proposal ¹⁹. A signed build or release candidate in NXS-FAC is not permission to deploy to production ¹. Qualification in NXS-NXQ is task-, population- and version-specific, and admission cannot follow a generic success percentage alone ². And in NXS-APP (application catalogue and lifecycle) a requested installation, a health check and an observed healthy application are three different states, never one ²⁰.

Beyond the systems, the programme year adds a further separation: a configured or simulated capability remains a design state until a Nexus Universe mission has tested it and its evidence is sealed at gate G5, and a gate is a programme decision, never a public-authority approval, a certification or a deployment authorisation ^21,22. A record can also move backwards. An admitted capability can be revoked or recalled, and the record says when and why ².

The record follows instruments that already govern software supply chains, and cites them as references, not as claims of conformance. The EU Cyber Resilience Act entered into force on 10 December 2024; its reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027, and the Commission published practical guidance for manufacturers on 27 July 2026 ⁹.

Among the programme’s own standards, all proposed or open, NS-12 covers software, models and AI artefacts; NS-1 the identifier of every artefact; and, in the Nexus Risk Standards, NRS-T8 covers software and supply-chain integrity risk, with NRS-S16 and NRS-S5 the system profiles of NXS-FAC and NXS-NXQ ^15,1,2,24. The software and supply chain area of Nexus Standards gathers the related work. Statuses such as proposed or open describe drafting stages only; none records adoption or certification.

The vulnerability records are taken from the National Vulnerability Database’s own interface, with NVD’s CVSS 3.1 base scores ^5,6. The SBOM fields are those named by the issuing agencies; for the 2026 update, only the fields named in the agency’s release are listed, and the full list of changes is in the appendix of the 2026 document ^7,8. The SLSA levels and the Cyber Resilience Act dates come from the issuers’ pages ^16,9.

No figure on this page measures the programme. Nothing operates beyond service level R0: the programme is at R0, information and enquiries, as the claims and readiness register records ^11,10.

• Records about records. The 2026 SBOM minimum elements add the tool name and generation context, so that a reader can judge how a bill of materials itself was produced ⁸.
• Reporting duties in law. From 11 September 2026, manufacturers covered by the Cyber Resilience Act must report actively exploited vulnerabilities, which turns component inventories into a compliance need ⁹.
• Source as well as build. SLSA 1.2 reintroduces coverage of source code, after version 1.0 had focused on builds alone ¹⁶.
• Model and agent components. Models, agents and tools are admitted in NXS-NXQ with task, data class and expiry, the same discipline as software packages ².

Component records protect the people who contribute as much as those who rely on them. GCRI publishes the record design; a technology or infrastructure provider that offers a component enters through the technology providers route, and an offer is never counted as an allocation ¹⁰. GRF stewards Nexus Universe, where components are tested under exercise control and evidence published only as agreed ²⁵. GRA reads readiness evidence for the questions competent financial institutions ask through its Consortium finance interface, and promises no bankability rating ²⁶. Each institution sets out its own role on its site: The Global Centre for Risk and Innovation, The Global Risks Forum and The Global Risks Alliance.

The companion pages on sponsor and provider participation and on supply chain security take the subject further.

What this page does not claim: no component is recorded under this design, and the programme is at service level R0, information and enquiries. A component record is not a certificate, a conformity assessment, a procurement status or an endorsement of a supplier; a signed build is not permission to deploy, and admission is for a stated task and expiry. GCRI does not regulate or certify, GRF does not regulate, finance or procure, and GRA does not lend, underwrite, rate or invest. Naming an agency, instrument or standard is not a claim of partnership, conformance or endorsement.