# Annex I #### I.1 SBOM minimums (required fields and formats) I.1.1 **Purpose.** This Annex specifies the minimum Software Bill of Materials (SBOM) requirements for NXOSI proof-carrying supply chains. The objective is not “having an SBOM,” but producing an SBOM that is (i) machine-verifiable, (ii) linkable to build provenance, (iii) usable for policy enforcement at multiple enforcement points, and (iv) portable across vendors without re-audit. I.1.2 **SBOM as a governed artefact.** An SBOM used for NXOSI reliance MUST be treated as a governed artefact with: a stable identifier, semantic versioning, handling class markers, signatures, and explicit status/supersession semantics (no silent edits). SBOMs MAY be stored in sovereign zones; receipts referencing them MUST remain verifiable without exfiltrating the SBOM contents unless required by the reliance tier. I.1.3 **Required SBOM fields (baseline).** At minimum, each SBOM MUST include: I.1.3.1 **SBOM identity.** SBOM ID, version, creation time, issuer identity, and cryptographic suite identifiers. I.1.3.2 **Subject binding.** A precise binding to the subject artefact(s) it describes (e.g., package, container image, firmware, model artifact), including immutable digests for each subject. I.1.3.3 **Component inventory.** A complete set of components with canonical names, versions, and unique references; components MUST include a resolvable identity pattern sufficient to support vulnerability and license matching. I.1.3.4 **Dependency relationships.** A dependency graph or explicit dependency edges sufficient to determine transitive exposure; relationship semantics MUST be explicit (e.g., “depends\_on,” “contains,” “bundles,” “generated\_from”). I.1.3.5 **Supplier/origin fields.** Where known and lawful, supplier identifiers and provenance pointers; where unknown, the SBOM MUST explicitly mark unknown/derived origins rather than leaving ambiguity. I.1.3.6 **License declarations.** License identifiers and notices for each component where applicable; unknown licenses MUST be marked as unknown and treated per profile policy. I.1.3.7 **Cryptographic hashes.** Digests for subject artefacts and, where feasible, for component artefacts; hash algorithms MUST be identified via crypto suite identifiers. I.1.3.8 **Build/provenance linkage pointers.** Pointers to build provenance artefacts (I.2) and to the execution context used to produce the SBOM (builder identity and environment claims). I.1.3.9 **Handling markers.** Handling class (Public/Controlled/Restricted) and disclosure tier marker; SBOMs containing sensitive supplier relationships MUST default to Controlled unless explicitly elected otherwise. I.1.3.10 **Status pointer.** A status endpoint pointer indicating revocation, supersession, or scope narrowing of the SBOM. I.1.4 **Required formats (baseline).** SBOMs MUST be exportable in at least one widely-supported machine-readable format (format choice is implementation-specific), but NXOSI compliance requires that the SBOM be translatable into the canonical NXOSI SBOM envelope and field semantics for verification and policy enforcement. Portability is defined by conformance surfaces, not by brand. I.1.5 **Minimum completeness rule.** If an SBOM intentionally omits classes of components (e.g., build tools, optional dependencies, system libraries), the omission MUST be explicitly declared and MUST trigger reliance downgrades or additional controls as defined by the active profile. *** #### I.2 Provenance minimums (build steps, dependency pinning, builder identity) I.2.1 **Purpose.** Provenance is the machine-verifiable history of how an artefact was produced. NXOSI requires provenance sufficient to reproduce trust, not merely to narrate a pipeline. I.2.2 **Provenance as an artefact.** Provenance used for NXOSI reliance MUST be expressed as a signed, versioned artefact with: unique ID, time binding, builder identity, build recipe references, environment claims, and pointers to inputs/outputs. I.2.3 **Required provenance fields (baseline).** I.2.3.1 **Builder identity and authorization.** Builder identity (service or human), role authorization proof, and the signing key identity used for provenance emission. I.2.3.2 **Build steps and recipe binding.** A declared sequence of build steps bound to an immutable build recipe definition (pipeline config digest, build scripts digest, or equivalent). “Build steps” MUST include sufficient metadata to evaluate policy gates. I.2.3.3 **Inputs.** Source references (repo URI reference or equivalent), commit digests, dependency manifests, and any external artefacts used as inputs, each bound by digest where possible. I.2.3.4 **Dependency pinning.** Pinning information for dependencies (versions and digests) sufficient to prevent ambiguous or floating dependencies; any unpinned dependency MUST be marked and treated as a policy failure or a governed exception. I.2.3.5 **Environment claims.** Build environment identity and integrity posture claims (e.g., runner identity, OS/runtime baseline digest, isolation posture). For high-impact reliance tiers, these claims SHOULD be attestation-bound per Annex H. I.2.3.6 **Outputs.** Output artefact identifiers and digests, including intermediate artefacts where necessary to support reproducibility and forensics. I.2.3.7 **Policy gates and results.** Evidence of policy gate evaluations during the build (pass/fail outcomes, waivers, exceptions with authority and expiry). I.2.3.8 **Timestamps and ordering.** Time binding for build start/end, step ordering, and nonces/challenges where needed to prevent replay. I.2.3.9 **Linkage pointers.** Pointers to the SBOM (I.1) and to any signing events for release bundles (I.4), plus status pointer for revocation/supersession of the provenance artefact. I.2.4 **Minimum provenance integrity rule.** Provenance MUST be tamper-evident, verifiable by a relying party, and resolvable to the artefact(s) it claims to describe. “Unverifiable provenance” MUST be treated as absent provenance for conformance purposes. *** #### I.3 Reproducible build requirements and verification procedure I.3.1 **Goal.** Reproducibility enables independent verification that the artefact corresponds to declared sources, dependencies, and build steps—reducing re-audit and enabling portable reliance. I.3.2 **Reproducible build requirements (baseline).** I.3.2.1 **Deterministic outputs.** Given the same inputs, pinned dependencies, and build recipe, the build SHOULD produce byte-identical outputs where feasible; where byte-identical reproducibility is not feasible, the implementation MUST provide an equivalence procedure that is deterministic and testable. I.3.2.2 **Pinned inputs.** All inputs that materially affect outputs MUST be pinned (source commit, dependencies, toolchain versions). Any non-pinned inputs MUST be explicitly declared and must trigger reliance downgrades or additional controls. I.3.2.3 **Controlled environment.** Build environment MUST be described and bounded; for higher reliance tiers the environment SHOULD be attestation-bound (Annex H). I.3.2.4 **Declared non-determinism.** Any source of non-determinism (timestamps, randomized ordering, host-specific paths) MUST be eliminated or normalized; if unavoidable, it MUST be declared and handled via equivalence testing. I.3.3 **Verification procedure (baseline).** I.3.3.1 **Input verification.** Verify source digests, dependency pins/digests, and build recipe digest match provenance artefact. I.3.3.2 **Environment verification.** Verify build environment claims and, when required, attestation appraisal results for the builder and runtime (Annex H). I.3.3.3 **Rebuild and compare.** Perform rebuild in a controlled environment using the pinned inputs. Compare output digests; if non-byte-identical equivalence is permitted, apply the defined equivalence procedure. I.3.3.4 **Policy gate replay.** Replay required policy gates where feasible to confirm that pass/fail outcomes are reproducible under the same inputs. I.3.3.5 **Emit verification evidence.** Produce a verification CRR and, where applicable, a PR indicating reproducible build verification success, scoped to the subject artefact and profile version. I.3.4 **Degraded verification.** In constrained or air-gapped contexts, the verification procedure MAY run against cached inputs and offline bundles, but must include explicit staleness bounds and reliance limits. *** #### I.4 Signing rules for provenance and SBOM artefacts I.4.1 **Signing principle.** SBOM and provenance artefacts MUST be signed to enable independent verification and non-repudiation. Signatures are not optional metadata; they are part of the conformance surface. I.4.2 **What MUST be signed (baseline).** I.4.2.1 SBOM envelopes and payload digests. I.4.2.2 Provenance artefacts, including step and input/output references. I.4.2.3 Release bundles that package artefacts (subject artefact + SBOM + provenance + conformance evidence), including checksums and manifest. I.4.2.4 Status objects that revoke, supersede, or scope-narrow SBOM/provenance artefacts. I.4.3 **Authorization proofs.** Signers MUST prove authorization to sign for the issuer role (role key / authority chain), and the relying party MUST be able to validate that authorization without privileged access. I.4.4 **Time binding and anti-replay.** Signatures MUST be time-bound; issuance MUST include anti-replay semantics appropriate to the environment. Expiry and validity windows MUST be explicit. I.4.5 **Crypto agility.** SBOM/provenance signing MUST support crypto suite identifiers and transition policies aligned to the NXOSI crypto agility baseline, including post-quantum transition hooks where required. I.4.6 **Handling-aware signing metadata.** Public logs MUST NOT leak sensitive metadata through signatures or certificate chains. Where required, NXOSI MUST support selective disclosure of identity attributes while preserving verifiability. *** #### I.5 Vulnerability disclosure and patch clock requirements I.5.1 **Objective.** Supply-chain trust requires not only build integrity but response discipline. NXOSI expresses this discipline using clocks, dockets, and verifiable outputs. I.5.2 **Vulnerability intake requirements (baseline).** I.5.2.1 **Intake channels.** Implementations MUST define channels for vulnerability intake (public and controlled), with handling rules and safe disclosure constraints. I.5.2.2 **Classification.** Vulnerabilities MUST be classified by severity and exposure scope, and mapped to ontology entities (components, products, deployments) to enable systemic impact analysis. I.5.2.3 **Acknowledgement clock.** Acknowledge receipt within a defined clock window (profile-parameterized), producing a docket entry and, where appropriate, a public-safe summary. I.5.3 **Patch clocks (baseline).** I.5.3.1 **Fix/mitigation clock.** Profiles MUST define time-to-mitigate requirements by severity and exposure class; failure MUST trigger escalation and status updates. I.5.3.2 **Retest clock.** After patch release or mitigation, a retest MUST be performed and evidenced via CRR/PR, with scope bound to impacted artefacts. I.5.3.3 **Disclosure clock.** Where disclosure is appropriate and lawful, the disclosure timeline MUST be explicit and recorded, with handling-aware publication rules. I.5.4 **Revocation and supersession.** When a release is vulnerable, NXOSI MUST support: (i) revoking affected receipts where reliance is unsafe, (ii) superseding SBOM/provenance artefacts, and (iii) issuing updated receipts after remediation. I.5.5 **Third-party dependencies.** Patch clocks MUST extend to third-party components and vendors where the relying party depends on their artefacts; vendor non-responsiveness MUST be representable as evidence and must affect reliance posture. *** #### I.6 Third-party component intake requirements (portable proofs) I.6.1 **Purpose.** Component intake must be decidable without re-audit: accept/deny/conditional accept based on portable proofs, status, and conformance reports. I.6.2 **Minimum intake decision inputs (baseline).** I.6.2.1 **Proof receipts (PR).** Receipts demonstrating that SBOM and provenance requirements were met under a named profile version, within a valid time window. I.6.2.2 **Status resolution.** Online/offline status checks verifying receipts, SBOMs, and provenance artefacts are not revoked or superseded beyond permitted migration rules. I.6.2.3 **Conformance report.** Signed conformance report indicating the supplier’s implementation/deployment meets required CL/EQL targets for the intake context. I.6.2.4 **Overlay compatibility.** Evidence that the supplier’s receipts are compatible with the consumer’s jurisdiction and sector overlays, or that incompatibilities are explicitly declared and accepted as governed exceptions. I.6.3 **Decision outputs (normative).** Intake decisions MUST produce docketed outputs with clocks: accepted, denied, accepted-with-conditions, or accepted-with-waiver (time-bound), each with traceable rationale and linkage to verification evidence. I.6.4 **Non-exfiltration default.** Intake MUST be possible using receipt-only verification for defined reliance tiers. Controlled evidence access (SBOM detail, provenance detail) MUST be requested explicitly via handling-aware workflows and logged. I.6.5 **Ongoing monitoring.** Intake is not one-time: status changes (revocation, supersession, new vulnerability) MUST trigger obligations, dockets, and remediation clocks. *** #### I.7 Conformance tests for provenance and SBOM profiles I.7.1 **Purpose.** Establish testable portability: different suppliers and verifiers should converge on the same pass/fail results for the same artefacts under the same profiles. I.7.2 **Mandatory test classes (baseline).** I.7.2.1 **Schema conformance tests.** Validate required fields, identifiers, signatures, handling markers, and status pointers for SBOM and provenance artefacts. I.7.2.2 **Binding tests.** Verify that SBOM and provenance bind to the same subject artefact digest and that references are consistent and resolvable. I.7.2.3 **Determinism and reproducibility tests.** * Gold vectors: artefacts with known-good reproducible outcomes * Negative vectors: missing pins, floating dependencies, mismatched digests * Equivalence vectors: permitted non-byte-identical cases with deterministic equivalence procedure I.7.2.4 **Signing and authorization tests.** Confirm authorization proofs, key validity, and correct failure behaviors when signatures are invalid or signers are unauthorized. I.7.2.5 **Status and revocation tests.** Validate relying party behavior under revoked/superseded SBOM/provenance and ensure reliance downgrades or denial behaviors occur as specified. I.7.2.6 **Vulnerability and patch clock tests.** Simulate vulnerability discovery and verify docket creation, acknowledgement, remediation clocks, retest outputs, and status transitions. I.7.2.7 **Third-party intake tests.** Cross-vendor scenarios where a consumer verifies supplier proofs, checks overlay compatibility, and produces the correct intake decision artefacts. I.7.2.8 **Degraded/offline tests.** Verify offline verification bundles for SBOM/provenance pointers, snapshot staleness constraints, and correct reliance limitation behavior. I.7.3 **Test outputs.** Conformance suites MUST emit machine-readable results and signed conformance reports, plus test receipts where applicable, enabling independent verification of the test run itself. I.7.4 **Regression lock discipline.** When the profile or schema changes, the conformance suite MUST include semantic regression tests to prevent silent weakening of SBOM/provenance requirements, and must publish migration guidance with status semantics where changes affect reliance. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-osi/annexes/annex-i.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.