# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-26T09:17:09Z", "synthesisSha256": "7236cf7639493d752d08d65d833fa95a757faed3aa573bec2828d67df61707c3", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-SFT-001", "registryId": "vr.wm-sft-001", "name": "Software Product", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.SFT.PRD" ], "tags": [ "software", "product", "inf.sft.prd" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-sft-001-software-product/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-sft-001", "model": { "registry_id": "vr.wm-sft-001", "model_id": "WM-SFT-001", "name": "Software Product", "entry_kind": "aggregate", "purpose": "Describe a software product in full context so an agent can identify it, know what it is made of, what rights and obligations attach to it, where it actually runs, how long it is supported, and what evidence backs every claim.", "scope_statement": "This model is the host aggregate for software regarded simultaneously as a published offering (product line, releases, distributable artifacts, licences) and as an operated system (deployed instances, environments, effective configuration, advisories). It is an aggregate rather than a plain entity because release, deployment and advisory records have independent lifecycles yet are only meaningful when anchored to one product identity. It is format-neutral: SPDX, CycloneDX, CSAF, JSON, Git, MongoDB and MCP are projections of these findings, not their semantics. Component-internal and package-ecosystem detail is delegated to WM-SFT-007 by COMPOSE and is not restated here.", "in_scope": [ "Product identity, classification, producer accountability and identifier coordinates (purl, CPE, SWID, content identifiers)", "Release lineage: version strings, versioning scheme, publication events, channels, withdrawal and supersession", "Product-level composition: the bill of materials document, declared dependency constraints and their recorded resolution", "Build provenance, artifact integrity, signatures and secure-development assurance claims", "Licence declaration, third-party attribution obligations, use and export restrictions", "Deployed instances, hosting environments, effective configuration and exposed interfaces", "Support lifecycle, end-of-life milestones, update delivery, advisories and exploitability assessment", "Quality characteristics, verification evidence and regulatory conformity documentation" ], "out_of_scope": [ "Internal structure, ecosystem metadata and package-manager semantics of individual components and packages (WM-SFT-007)", "Organization records for producers, suppliers and operators beyond a reference to them", "Rights-holder, patent and trademark records as subject matter in their own right", "Dataset and AI training-corpus records consumed or produced by the software", "Source-control history, issue tracking, requirements engineering and project management processes", "Vulnerability records themselves as governed objects (CVE/CWE registry content), as opposed to this product's exposure to them", "Hardware devices and physical assets except as the hosting platform of a deployed instance", "Commercial contracts, pricing and entitlement fulfilment mechanics" ], "boundary_notes": [ { "neighbor": "WM-SFT-007 Software Component and Package", "distinction": "This model records that a release is composed of components and the resolution that satisfied each declared dependency; it does not model a component's own identity, ecosystem metadata or internal files. SPDX distinguishes the Sbom/Bom collection from the Package and File elements it contains, and CycloneDX separates the BOM document from the component objects; the seam is drawn at that same line.", "source_refs": [ "SRC-001", "SRC-002", "SRC-015" ] }, { "neighbor": "Organization model (producer, supplier, distributor, operator)", "distinction": "SPDX models Agent, Person and Organization as first-class elements referenced by artifacts. This model holds only the reference plus the role that party plays for this product; legal identity, addresses and corporate hierarchy belong to the organization model.", "source_refs": [ "SRC-001", "SRC-006" ] }, { "neighbor": "Vulnerability registry (CVE Program) and advisory publishers", "distinction": "CVE records and CVSS scores are governed by the CVE Program and its record format. This model stores the exposure mapping and the product's exploitability assessment, referencing the CVE identifier rather than restating the vulnerability record.", "source_refs": [ "SRC-008", "SRC-014" ] }, { "neighbor": "Intellectual property and rights model", "distinction": "The licence expression, copyright holder reference and obligation classes attached to a release are in scope; the underlying rights instruments, assignments and disputes are not.", "source_refs": [ "SRC-001" ] }, { "neighbor": "Identifier and naming scheme model", "distinction": "purl types, CPE dictionary governance and SWID tag-issuer rules are governed elsewhere. This model records which coordinates denote this product and how conflicts between schemes are resolved for a given use.", "source_refs": [ "SRC-003", "SRC-013" ] }, { "neighbor": "Service and hosted-offering model", "distinction": "CycloneDX separates components from services and supports a SaaSBOM. Where software is delivered only as a hosted service with no distributable artifact, the release and integrity layers degrade to service-version records; that degradation is recorded explicitly rather than by forcing artifact semantics.", "source_refs": [ "SRC-002" ] }, { "neighbor": "Software life cycle process model", "distinction": "ISO/IEC/IEEE 12207 defines processes for acquiring, supplying, developing, operating, maintaining and disposing of software. This model describes the product and system as objects with states and evidence; it does not define or govern the processes themselves.", "source_refs": [ "SRC-004" ] } ] }, "sources": [ { "id": "SRC-001", "title": "SPDX Specification 3.0.1", "organization": "The Linux Foundation (SPDX Project)", "url": "https://spdx.github.io/spdx-spec/v3.0.1/", "version_or_date": "Version 3.0.1, December 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:05:00Z", "relevance": "Defines the core classes (Element, Artifact, Package, File, Snippet, Relationship, Agent, Annotation, Hash/IntegrityMethod, ExternalIdentifier, ExternalRef, CreationInfo, Bom) and the profile set (Core, Software, Security, Licensing, Build, AI, Dataset, Extension) that ground identity, composition, provenance and licensing findings." }, { "id": "SRC-002", "title": "CycloneDX v1.6 JSON Reference", "organization": "OWASP Foundation / Ecma International (ECMA-424)", "url": "https://cyclonedx.org/docs/1.6/json/", "version_or_date": "v1.6; ECMA-424 1st edition, June 2024", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:06:00Z", "relevance": "Normative field set for BOM metadata, component types, services, dependencies, compositions, vulnerabilities, formulation, declarations and lifecycle phases (design, pre-build, build, post-build, operations, discovery, decommission); grounds composition, service-interface and lifecycle findings." }, { "id": "SRC-003", "title": "ECMA-427 Package-URL (PURL) specification", "organization": "Ecma International", "url": "https://ecma-international.org/publications-and-standards/standards/ecma-427/", "version_or_date": "1st edition, December 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:08:00Z", "relevance": "Governed syntax pkg:type/namespace/name@version?qualifiers#subpath for identifying software packages independently of ecosystem; grounds the governed-global-identifier tier of the identity priority and the coordinate crosswalk finding." }, { "id": "SRC-004", "title": "ISO/IEC/IEEE 12207:2026 Systems and software engineering — Software life cycle processes", "organization": "ISO / IEC / IEEE", "url": "https://www.iso.org/standard/90219.html", "version_or_date": "Edition 2, published 2026-04-29 (cancels and replaces ISO/IEC/IEEE 12207:2017)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:12:00Z", "relevance": "Authoritative frame for acquisition, supply, development, operation, maintenance and disposal of software products and services; grounds lifecycle, support-status and disposal boundaries. Full text is paywalled, so only catalogue-level scope statements are relied upon." }, { "id": "SRC-005", "title": "ISO/IEC 25010:2023 Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model", "organization": "ISO / IEC (JTC 1/SC 7)", "url": "https://webstore.iec.ch/en/publication/90024", "version_or_date": "Edition 2.0, 2023-11-15", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:15:00Z", "relevance": "Defines a product quality model of nine characteristics with subcharacteristics for ICT and software products, usable for specification, measurement and evaluation; grounds the quality characteristics and measures finding." }, { "id": "SRC-006", "title": "2026 Minimum Elements for a Software Bill of Materials (SBOM)", "organization": "CISA, NSA, FBI and international partner agencies", "url": "https://www.ic3.gov/CSA/2026/260729.pdf", "version_or_date": "2026-07-29 (updates and replaces the 2021 NTIA minimum elements)", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:20:00Z", "relevance": "Current baseline for SBOM data fields (component name, version, supplier, unique identifier, dependency relationships, SBOM author, timestamp, component hash, licence and related additions) plus automation and practice requirements for depth, known unknowns, distribution and access control." }, { "id": "SRC-007", "title": "Cyber Resilience Act — Regulation (EU) 2024/2847", "organization": "European Commission (DG CONNECT)", "url": "https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act", "version_or_date": "In force 2024-12-10; reporting obligations from 2026-09-11; main application 2027-12-11", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:24:00Z", "relevance": "Binding EU obligations for products with digital elements: cybersecurity requirements across planning, design, development and maintenance; vulnerability handling across the lifecycle; CE marking and conformity assessment; reporting of actively exploited vulnerabilities. Grounds regulatory-conformity and support-period findings." }, { "id": "SRC-008", "title": "Common Security Advisory Framework Version 2.0 (OASIS Standard)", "organization": "OASIS", "url": "https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html", "version_or_date": "Version 2.0, approved 2022-11-18", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:28:00Z", "relevance": "Machine-readable advisory structure: /document tracking (id, initial and current release dates, revision history, status, version), /product_tree with product_identification_helper (cpe, purl, hashes, sbom_urls), /vulnerabilities with product_status, remediations, scores and threats, and the VEX profile. Grounds advisory and exploitability findings." }, { "id": "SRC-009", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:30:00Z", "relevance": "Normative timestamp grammar: hours, minutes and seconds are mandatory, offset is either Z or +/-HH:MM, and -00:00 signals a known UTC instant with unknown local offset. Grounds the model timestamp rule and the event-time versus observation-time separation." }, { "id": "SRC-010", "title": "NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/218/final", "version_or_date": "Version 1.1, February 2022", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:33:00Z", "relevance": "Recommended practices for preparing the organization, protecting software, producing well-secured software and responding to vulnerabilities; grounds the development-practice assurance and vulnerability-response findings." }, { "id": "SRC-011", "title": "SLSA Security Levels (specification v1.1)", "organization": "Open Source Security Foundation (OpenSSF)", "url": "https://slsa.dev/spec/v1.1/levels", "version_or_date": "v1.1 (retired; superseded by v1.2)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:36:00Z", "relevance": "Build track levels L0-L3 and the requirement that provenance identify the building entity, the build process and top-level inputs, with signing and tenant isolation at higher levels; grounds the build-provenance attestation finding and its assurance-level element." }, { "id": "SRC-012", "title": "Semantic Versioning 2.0.0", "organization": "Semantic Versioning project", "url": "https://semver.org/", "version_or_date": "2.0.0", "source_type": "schema", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-25T09:38:00Z", "relevance": "One widely adopted but non-universal versioning scheme with explicit precedence rules and the rule that build metadata is ignored for precedence; grounds the version-scheme finding and the warning that ordering rules must be declared rather than assumed." }, { "id": "SRC-013", "title": "Common Platform Enumeration (CPE) and the official CPE Dictionary", "organization": "NIST National Vulnerability Database", "url": "https://nvd.nist.gov/products/cpe", "version_or_date": "CPE Dictionary, accessed 2026-08-25", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:41:00Z", "relevance": "Structured naming scheme for IT systems, software and packages maintained as an official public NIST dictionary to which organizations may submit names; grounds the CPE coordinate element and the identifier-conflict question." }, { "id": "SRC-014", "title": "CVE Services and the CVE Record Format", "organization": "CVE Program (CISA / MITRE)", "url": "https://www.cve.org/AllResources/CveServices", "version_or_date": "CVE Record Format JSON 5.x", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:44:00Z", "relevance": "Defines cveMetadata (cveId, assignerOrgId, state, datePublished, dateUpdated) and the CNA/ADP containers with affected products expressed by vendor, product, versions, versionType, status, defaultStatus, cpes and packageName; grounds the exposure-mapping data elements." }, { "id": "SRC-015", "title": "SPDX 3.0.1 Software Profile", "organization": "The Linux Foundation (SPDX Project)", "url": "https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Software/", "version_or_date": "Version 3.0.1", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:47:00Z", "relevance": "Software profile classes (SoftwareArtifact, Package, File, Snippet, Sbom, ContentIdentifier) and properties (primaryPurpose, additionalPurpose, packageUrl, packageVersion, downloadLocation, sbomType, contentIdentifier, sourceInfo, copyrightText, attributionText); grounds purpose classification, coordinates and attribution elements." }, { "id": "SRC-016", "title": "RFC 9393: Concise Software Identification Tags", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc9393.html", "version_or_date": "RFC 9393, June 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Tag identity, tag types, entity roles, links, hashes, software-meta fields, evidence versus payload and installed-presence lifecycle." }, { "id": "SRC-017", "title": "ISO/IEC 19770-2:2015 Information technology — IT asset management — Part 2: Software identification tag", "organization": "ISO/IEC JTC 1/SC 7", "url": "https://www.iso.org/standard/65666.html", "version_or_date": "ISO/IEC 19770-2:2015, confirmed 2021, corrected 2017-03", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "SWID tag standard underlying CoSWID; source of the ISO software identification tag alignment and of the SWID/CoSWID divergence caveat." }, { "id": "SRC-018", "title": "2026 Minimum Elements for a Software Bill of Materials (SBOM)", "organization": "Cybersecurity and Infrastructure Security Agency with NSA, FBI and international partners", "url": "https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom", "version_or_date": "29 July 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Current SBOM baseline: Component Producer, hashes, licenses, SBOM Author, tool, generation context, coverage and explicit unknowns; replaces NTIA 2021." }, { "id": "SRC-019", "title": "CycloneDX Specification Overview (v1.7 / ECMA-424)", "organization": "OWASP Foundation and Ecma International TC54", "url": "https://cyclonedx.org/specification/overview/", "version_or_date": "CycloneDX 1.7 (2025-10-21); ECMA-424 published 2025-12-10", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Interchange alignment for BOM metadata, components, services, dependency graphs, compositions, formulation and citations." }, { "id": "SRC-020", "title": "Package-URL (PURL) Specification / ECMA-427", "organization": "Ecma International TC54 and package-url maintainers", "url": "https://github.com/package-url/purl-spec", "version_or_date": "ECMA-427; specification repository main at retrieval", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Governed cross-ecosystem package identifier used in SBOM and advisory identifier crosswalks." }, { "id": "SRC-021", "title": "Software Identification (SWID) Tagging — NIST CSRC project and NISTIR 8060", "organization": "National Institute of Standards and Technology", "url": "https://csrc.nist.gov/projects/software-identification-swid/guidelines", "version_or_date": "NISTIR 8060, April 2016; project page current at retrieval", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Corpus, primary, patch and supplemental tag types with their lifecycle placement, and endpoint discovery practice." }, { "id": "SRC-022", "title": "SPDX 3.0.1 Software Package, Sbom, SoftwareArtifact and SbomType", "organization": "The Linux Foundation and Object Management Group", "url": "https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Classes/Package/", "version_or_date": "SPDX 3.0.1 model, Software profile", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Field-level source for packageVersion, releaseTime, downloadLocation, verifiedUsing, supportLevel, validUntilTime, sbomType and originatedBy/suppliedBy." } ], "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity and Classification", "description": "Fixes what the product is, who is accountable for it, how it is typed, and which external coordinates denote it.", "rationale": "No downstream statement about composition, exposure or support can be joined or refuted until the product has a stable, non-date identifier and a declared namespace. SPDX makes every Element identifiable and attributable to an Agent; the SBOM minimum elements make supplier, name and unique identifier mandatory; purl and CPE supply the governed external coordinates.", "source_refs": [ "SRC-001", "SRC-003", "SRC-006", "SRC-013", "SRC-015" ], "layers": [ { "id": "product-identity", "name": "Product Identity", "description": "The stable identity of the product as an offering, independent of any single release, package or deployment.", "source_refs": [ "SRC-001", "SRC-003", "SRC-006", "SRC-013" ], "findings": [ { "id": "product-identity-record", "name": "Product Identity Record", "description": "The authoritative record that fixes the product's master-system identifier, canonical name, issuing namespace, producer of record and the criterion separating it from adjacent offerings.", "source_refs": [ "SRC-001", "SRC-006", "SRC-015" ], "questions": [ { "id": "pir-master-id", "text": "Which identifier is the authoritative master-system identifier for this product, and which system issued it?", "kind": "identity", "answer_data": [ "issuing system name", "identifier value", "identifier scheme reference", "assignment timestamp" ] }, { "id": "pir-name-namespace", "text": "Within which namespace is the canonical product name unique, and which marketing or legacy names alias it?", "kind": "definition", "answer_data": [ "canonical name", "namespace reference", "alternate and legacy names" ] }, { "id": "pir-producer-accountable", "text": "Which organization is accountable as producer or supplier of record for this product?", "kind": "ownership", "answer_data": [ "producer organization reference", "role code (producer, supplier, distributor)", "accountability start time" ] }, { "id": "pir-product-boundary", "text": "Where does this product stop, and which adjacent offerings are separate products rather than editions of this one?", "kind": "composition", "answer_data": [ "sibling product references", "edition list", "stated separation criterion" ] } ], "data_elements": [ { "id": "product-key", "name": "Product master key", "description": "Authoritative identifier for the product issued by the producer's system of record, stored with the issuing system so its authority is auditable.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "canonical-name", "name": "Canonical product name", "description": "The name under which the product is offered, as published by the producer.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-015" ] }, { "id": "producer-ref", "name": "Producer reference", "description": "Reference to the organization record for the producing or supplying party, not an embedded copy of it.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "product-namespace", "name": "Identity namespace", "description": "Namespace or registry in which the canonical name and master key are unique.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "alternate-names", "name": "Alternate names", "description": "Marketing, legacy and internal names that alias the canonical name, each with the context in which it is used.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [ { "id": "product-identity-card", "name": "Product identity card", "description": "The canonical record instance carrying the master key, namespace, canonical and alternate names, producer reference and separation criterion.", "media_or_form": [ "structured record", "document projection", "registry entry" ], "serial": false, "identity_strategy": "Keyed by the authoritative master-system identifier plus its issuing system; a Dimension-assigned ULID is minted only when no master system exists and is flagged as Dimension-assigned.", "source_refs": [ "SRC-001", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "identifier-coordinates-and-crosswalk", "name": "Identifier Coordinates and Crosswalk", "description": "Ecosystem-facing coordinates that let external systems match this product and its releases (Package URL, CPE, SWID, download location, content identifiers), plus the mapping and precedence between them.", "source_refs": [ "SRC-003", "SRC-013", "SRC-015", "SRC-002" ], "questions": [ { "id": "icc-purl-form", "text": "What Package URL type, namespace, name and qualifiers identify the distributed form of this product?", "kind": "identity", "answer_data": [ "purl type", "purl namespace and name", "qualifier set", "canonical purl string" ] }, { "id": "icc-cpe-assertion", "text": "Which CPE names are asserted to denote this product, and who asserted them?", "kind": "interoperability", "answer_data": [ "CPE name", "dictionary status", "asserting party", "assertion time" ] }, { "id": "icc-scheme-precedence", "text": "Where two identifier schemes disagree about the product boundary, which scheme is authoritative for which use?", "kind": "decision", "answer_data": [ "use case", "authoritative scheme", "precedence rationale" ] }, { "id": "icc-coordinate-verification", "text": "How is a claimed coordinate verified against the published artifact before it is trusted?", "kind": "validation", "answer_data": [ "verification method", "verifier identity", "verification outcome" ] } ], "data_elements": [ { "id": "purl-string", "name": "Package URL", "description": "Canonical purl identifying the distributed package form, per the governed syntax.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-015" ] }, { "id": "cpe-name", "name": "CPE name", "description": "Formatted CPE string asserted to denote this product for vulnerability applicability matching.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "content-identifier", "name": "Content identifier", "description": "Content-derived identifier for a specific artifact, such as a source or artifact content hash identifier.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-002" ] }, { "id": "coordinate-assertion", "name": "Coordinate assertion", "description": "Who asserted a coordinate, when, and on what evidence; separates producer declaration from third-party attribution.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-006" ] } ], "artifacts": [ { "id": "identifier-crosswalk-table", "name": "Identifier crosswalk table", "description": "Mapping between the product master key and each external coordinate, with asserting party, validity window and precedence for matching.", "media_or_form": [ "structured table", "registry export" ], "serial": false, "identity_strategy": "Keyed by product master key plus coordinate scheme; each row carries the asserting party so competing assertions coexist rather than overwrite.", "source_refs": [ "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "product-family-edition-and-sku", "name": "Family, edition, channel and SKU", "description": "CoSWID software-meta separates product, product-family, edition, channel-type, colloquial-version and revision from the exact software-version. CSAF product trees use vendor/product/version branches, product groups and relationships among products. These group commercial variants (enterprise versus standard, OEM versus academic, LTS line) without treating each SKU as an unrelated product or collapsing them into a single version.", "source_refs": [ "SRC-016", "SRC-008" ], "inline_only_rationale": null, "data_elements": [ { "id": "product-family-edition-and-sku-data01", "name": "Product family", "description": "Family spanning client, server or related capabilities", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "product-family-edition-and-sku-data02", "name": "Edition", "description": "Functional variation such as standard or enterprise", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "product-family-edition-and-sku-data03", "name": "Channel type", "description": "Sales or licensing channel such as OEM, retail, academic or volume", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "product-family-edition-and-sku-data04", "name": "Colloquial version", "description": "Informal line label such as a year or major train", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "product-family-edition-and-sku-data05", "name": "Product group identifier", "description": "CSAF product group id when variants are grouped for advisory status", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "product-family-edition-and-sku-artifact01", "name": "Product tree branch", "description": "Family/edition/channel branch locating this offering inside a producer product tree.", "media_or_form": [ "CSAF product tree branch", "structured record" ], "serial": false, "identity_strategy": "Keyed by the CSAF product id or product group id within the producer product tree.", "source_refs": [ "SRC-016", "SRC-008" ] } ], "questions": [ { "id": "product-family-edition-and-sku-q01", "text": "Which product family, edition and colloquial version line does this offering belong to, and which sibling editions share the same code base?", "kind": "composition", "answer_data": [ "product-family", "edition", "colloquial-version" ] }, { "id": "product-family-edition-and-sku-q02", "text": "Which distribution or licensing channel (OEM, academic, retail, volume or other) applies to this offering?", "kind": "classification", "answer_data": [ "channel-type" ] }, { "id": "product-family-edition-and-sku-q03", "text": "Which CSAF product group, if any, collects this product with related products for common advisory or remediation status?", "kind": "relationship", "answer_data": [ "product-group-id" ] } ] } ] }, { "id": "classification-and-stewardship", "name": "Classification and Stewardship", "description": "How the product is typed and what purpose it serves, and who is entitled to speak for each slice of its record.", "source_refs": [ "SRC-002", "SRC-015", "SRC-007", "SRC-006" ], "findings": [ { "id": "software-classification-and-purpose", "name": "Software Classification and Purpose", "description": "Controlled typing of the software (component type, primary and additional purpose, delivery model, regulatory class) that determines which downstream profiles and obligations apply.", "source_refs": [ "SRC-002", "SRC-015", "SRC-007" ], "questions": [ { "id": "scp-component-type", "text": "Which component type from the governing BOM vocabulary applies to this product?", "kind": "classification", "answer_data": [ "component type code", "governing vocabulary and version", "assigning party" ] }, { "id": "scp-purpose", "text": "What primary purpose and additional purposes does the released artifact serve?", "kind": "definition", "answer_data": [ "primary purpose code", "additional purpose codes", "purpose rationale" ] }, { "id": "scp-delivery-model", "text": "Is the product delivered as an installable artifact, an appliance image, or a hosted service, and does that change which BOM type applies?", "kind": "interoperability", "answer_data": [ "delivery model code", "applicable BOM type", "degradation notes where no artifact exists" ] }, { "id": "scp-regulatory-class", "text": "Is the product classified as important or critical under an applicable product-security regime?", "kind": "requirement", "answer_data": [ "regime reference", "class assigned", "classifying authority or self-assessment flag" ] } ], "data_elements": [ { "id": "component-type-code", "name": "Component type code", "description": "Type drawn from a declared controlled vocabulary such as application, library, framework, container, operating-system, firmware, device-driver, machine-learning-model.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "primary-purpose-code", "name": "Primary purpose code", "description": "Declared primary purpose of the artifact, with any additional purposes recorded separately.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "delivery-model-code", "name": "Delivery model code", "description": "How the product reaches the consumer: downloadable artifact, image, embedded firmware, or hosted service.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "regulatory-class-code", "name": "Regulatory class", "description": "Class assigned under a named product-security or market regime, with the regime reference.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "classification-assignment-record", "name": "Classification assignment record", "description": "Record of each classification assigned, the vocabulary and version used, the assigning party and the time of assignment.", "media_or_form": [ "structured record", "audit entry" ], "serial": false, "identity_strategy": "Keyed by product master key plus vocabulary identifier; superseded assignments are retained with an end time rather than overwritten.", "source_refs": [ "SRC-002", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "producer-and-stewardship", "name": "Producer Accountability and Record Stewardship", "description": "The split of ownership and authority over the record: producer-side release facts versus operator-side deployment facts, who may publish binding statements, and what happens when stewardship lapses.", "source_refs": [ "SRC-006", "SRC-001", "SRC-007", "SRC-010" ], "questions": [ { "id": "ps-slice-owner", "text": "Which role owns each slice of this record: producer, supplier, distributor or operator?", "kind": "ownership", "answer_data": [ "record slice reference", "owning role", "owner package reference" ] }, { "id": "ps-binding-authority", "text": "Who is authorised to publish a binding statement about this product, and under what delegation?", "kind": "authority", "answer_data": [ "authorised party", "delegation reference", "statement classes covered" ] }, { "id": "ps-author-vs-producer", "text": "Is the author of a given record the same party as the software producer, and how is the difference recorded?", "kind": "provenance", "answer_data": [ "author reference", "producer reference", "relationship flag" ] }, { "id": "ps-succession", "text": "What becomes of stewardship if the producing organization is acquired, dissolved or abandons the product?", "kind": "exception", "answer_data": [ "succession rule", "fallback steward", "abandonment state code" ] } ], "data_elements": [ { "id": "steward-assignment", "name": "Steward assignment", "description": "Binding of a record slice to an owning role and owner package, with validity window.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "authority-delegation-ref", "name": "Authority delegation reference", "description": "Reference to the delegation that entitles a party to publish binding statements about the product.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "record-author-ref", "name": "Record author reference", "description": "The party that authored a given record or document, kept distinct from the producer reference.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-001" ] }, { "id": "succession-rule", "name": "Stewardship succession rule", "description": "Declared rule for reassigning stewardship on acquisition, dissolution or abandonment.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "stewardship-assignment", "name": "Stewardship assignment", "description": "The governing record of who owns, may write to, and may publish from each slice of the product record.", "media_or_form": [ "structured record", "policy document projection" ], "serial": false, "identity_strategy": "Keyed by product master key plus record-slice reference; changes are appended with effective-from times, never edited in place.", "source_refs": [ "SRC-006", "SRC-007" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "release-and-distribution", "name": "Release and Distribution", "description": "The published version lineage of the product and the channels, conditions and cryptographic evidence under which each release reaches a consumer.", "rationale": "A software product exists in the world as a series of dated, versioned, immutable publications. SBOM minimum elements require component version and a creation timestamp; SPDX and CycloneDX carry download location, hashes and signatures; RFC 3339 fixes how the times are written.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006", "SRC-009", "SRC-012" ], "layers": [ { "id": "release-lineage", "name": "Release Lineage", "description": "Individual published releases, their version strings, states, publication events and the scheme that makes versions comparable.", "source_refs": [ "SRC-002", "SRC-006", "SRC-009", "SRC-012" ], "findings": [ { "id": "release-record", "name": "Release Record", "description": "One published version of the product: its version string, publication event time and observation time, distribution channel, state and supersession links.", "source_refs": [ "SRC-002", "SRC-006", "SRC-009" ], "questions": [ { "id": "rr-version-identity", "text": "What exact version string identifies this release, and is that string immutable once published?", "kind": "identity", "answer_data": [ "version string", "immutability flag", "issuing system" ] }, { "id": "rr-publication-time", "text": "When was the release published, and is that time distinct from when this record observed it?", "kind": "temporal", "answer_data": [ "publication event time", "observation or ingestion time", "time source" ] }, { "id": "rr-current-state", "text": "What is the release's current state: pre-release, generally available, superseded, withdrawn or yanked?", "kind": "state", "answer_data": [ "release state code", "state effective time", "state-setting party" ] }, { "id": "rr-withdrawal-event", "text": "Which event withdrew or re-published this release, and what release replaced it?", "kind": "event", "answer_data": [ "event type", "event time", "reason code", "replacing release reference" ] } ], "data_elements": [ { "id": "version-string", "name": "Version string", "description": "The producer's exact version label for the release, stored verbatim alongside a derived ordering key.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-002" ] }, { "id": "released-at", "name": "Publication event time", "description": "The time the release was made available, recorded as an RFC 3339 date-time with seconds and an explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-006" ] }, { "id": "release-observed-at", "name": "Observation time", "description": "The time this record observed or ingested the release fact, held separately from publication time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "release-state-code", "name": "Release state", "description": "Current lifecycle state of the release within the producer's publication process.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "supersedes-ref", "name": "Supersession reference", "description": "Reference to the release this one replaces, and to any release that replaces it.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "release-manifest", "name": "Release manifest", "description": "The published description of a release: version, publication time, channel, contained distributable artifacts and release notes.", "media_or_form": [ "structured manifest", "release notes document", "registry entry" ], "serial": true, "identity_strategy": "Keyed by product master key plus verbatim version string; the version string is an identity component, while the release date is metadata and never an identifier.", "source_refs": [ "SRC-002", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "version-scheme-and-ordering", "name": "Version Scheme and Ordering", "description": "The declared versioning scheme and precedence rules that make version comparison, dependency ranges and affected-range statements decidable rather than guessed.", "source_refs": [ "SRC-012", "SRC-014", "SRC-002" ], "questions": [ { "id": "vso-scheme-declared", "text": "Which versioning scheme governs this product line, and is it declared by the producer or inferred by a consumer?", "kind": "classification", "answer_data": [ "version scheme code", "declared or inferred flag", "scheme specification reference" ] }, { "id": "vso-precedence-rule", "text": "How is precedence determined between two versions, including pre-release identifiers and build metadata?", "kind": "constraint", "answer_data": [ "ordering algorithm", "pre-release handling", "build-metadata handling" ] }, { "id": "vso-compatibility-promise", "text": "What change classes force a major increment, and what compatibility promise attaches to minor and patch increments?", "kind": "requirement", "answer_data": [ "change class to increment mapping", "compatibility promise text", "exceptions" ] } ], "data_elements": [ { "id": "version-scheme-code", "name": "Version scheme", "description": "Identifier of the versioning scheme in force, such as a semantic scheme, a calendar scheme or an ecosystem-specific scheme.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "version-ordering-key", "name": "Ordering key", "description": "Derived comparable key used for range evaluation, computed by the declared scheme and recomputed when the scheme changes.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-014" ] }, { "id": "compatibility-promise", "name": "Compatibility promise", "description": "Stated contract about what consumers may rely on across increments of each version component.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "version-scheme-declaration", "name": "Version scheme declaration", "description": "Producer statement of the scheme, its precedence rules and its compatibility promise for a product line.", "media_or_form": [ "policy statement", "structured record" ], "serial": false, "identity_strategy": "Keyed by product master key plus product-line reference; a scheme change opens a new declaration with an effective-from time rather than mutating the prior one.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "patch-upgrade-and-tag-types", "name": "Patch versus upgrade and tag types", "description": "CoSWID and NISTIR 8060 define four tag types used at different lifecycle points: corpus (pre-install media), primary (installed component), patch (incremental fix that MUST NOT change software-version) and supplemental (site-added metadata). Patch tags MUST link with rel=patches to the patched software. Upgrade replaces primary tags and changes version metadata. This distinction is a frequent omission in product catalogues that only store version strings.", "source_refs": [ "SRC-016", "SRC-021" ], "inline_only_rationale": null, "data_elements": [ { "id": "patch-upgrade-and-tag-types-data01", "name": "Tag type", "description": "corpus, primary, patch or supplemental", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-021" ] }, { "id": "patch-upgrade-and-tag-types-data02", "name": "Patched release reference", "description": "Release this patch applies to", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "patch-upgrade-and-tag-types-data03", "name": "Patch changes version flag", "description": "Must be false for a CoSWID patch tag", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "patch-upgrade-and-tag-types-data04", "name": "Corpus installation media", "description": "Pre-install package or installer location", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-021" ] } ], "artifacts": [ { "id": "patch-upgrade-and-tag-types-artifact01", "name": "SWID or CoSWID tag", "description": "Lifecycle-typed software identification tag for corpus, primary, patch or supplemental state.", "media_or_form": [ "SWID XML tag (ISO/IEC 19770-2)", "CoSWID concise tag (RFC 9393)" ], "serial": true, "identity_strategy": "Keyed by the globally unique tag-id, which must not contain a double underscore, with tag-version as the metadata revision serial.", "source_refs": [ "SRC-016", "SRC-017" ] } ], "questions": [ { "id": "patch-upgrade-and-tag-types-q01", "text": "Is the current identification record a corpus, primary, patch or supplemental tag, and where is it supposed to reside (media versus endpoint versus operator overlay)?", "kind": "state", "answer_data": [ "tag-type" ] }, { "id": "patch-upgrade-and-tag-types-q02", "text": "If this is a patch, which release does it patch, and does the patch illegally change the software-version?", "kind": "relationship", "answer_data": [ "patches-release-ref", "patch-changes-version" ] }, { "id": "patch-upgrade-and-tag-types-q03", "text": "If this is a pre-install corpus record, which installation media or package installer does it describe?", "kind": "process", "answer_data": [ "corpus-media-ref" ] } ] } ] }, { "id": "distribution-and-integrity", "name": "Distribution and Integrity", "description": "Where a release may legitimately be obtained, under what access conditions, and the cryptographic evidence that a fetched artifact is the released artifact.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006", "SRC-011", "SRC-015" ], "findings": [ { "id": "distribution-channel-and-availability", "name": "Distribution Channel and Availability", "description": "Authoritative download locations and registries for a release, the access conditions attached to them, and how long prior releases stay retrievable.", "source_refs": [ "SRC-015", "SRC-002", "SRC-006" ], "questions": [ { "id": "dca-locations", "text": "From which authoritative download locations or registries is this release distributed?", "kind": "provenance", "answer_data": [ "download location", "registry reference", "mirror list", "authoritative flag" ] }, { "id": "dca-access-conditions", "text": "What access conditions apply to obtaining this release: public, entitled, embargoed or jurisdictionally restricted?", "kind": "access", "answer_data": [ "access condition code", "entitlement requirement", "jurisdiction restriction" ] }, { "id": "dca-retention-policy", "text": "How long are prior releases retained at the distribution point, and what is the removal policy?", "kind": "retention", "answer_data": [ "retention period", "removal trigger", "archival location after removal" ] } ], "data_elements": [ { "id": "download-location", "name": "Download location", "description": "Resolvable location from which the distributable artifact may be obtained, flagged as authoritative or mirror.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "distribution-condition", "name": "Distribution condition", "description": "Condition governing who may obtain the release from the location.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "distribution-retention-period", "name": "Distribution retention period", "description": "Declared period for which the release remains retrievable at the distribution point.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "distribution-point-registration", "name": "Distribution point registration", "description": "Record binding a release to each distribution location with its access conditions, authoritativeness and retention commitment.", "media_or_form": [ "structured record", "registry entry" ], "serial": false, "identity_strategy": "Keyed by release reference plus location reference; superseded locations retain an end time so historical fetch provenance stays resolvable.", "source_refs": [ "SRC-015", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "artifact-integrity-and-signature", "name": "Artifact Integrity and Signature", "description": "Hashes, signatures and signing identities that let a consumer verify a fetched artifact, together with the verification outcome and any reproducibility claim.", "source_refs": [ "SRC-001", "SRC-006", "SRC-011", "SRC-002" ], "questions": [ { "id": "ais-hash-values", "text": "Which hash algorithms and digest values are published for each distributable artifact of this release?", "kind": "evidence", "answer_data": [ "hash algorithm", "digest value", "artifact reference", "publishing party" ] }, { "id": "ais-signing-identity", "text": "Which signing identity signed the release, and how is that identity's authority established?", "kind": "security", "answer_data": [ "signing identity", "key or certificate reference", "trust anchor", "authority evidence" ] }, { "id": "ais-verification-procedure", "text": "What verification procedure must a consumer run before accepting the artifact, and what does a failure trigger?", "kind": "validation", "answer_data": [ "verification steps", "required tooling", "failure handling rule" ] }, { "id": "ais-reproducibility", "text": "Is the build reproducible, such that an independent rebuild yields a bit-identical digest?", "kind": "quality", "answer_data": [ "reproducibility claim", "rebuild evidence", "known sources of nondeterminism" ] } ], "data_elements": [ { "id": "hash-entry", "name": "Hash entry", "description": "Algorithm plus lowercase hexadecimal digest for a named distributable artifact.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "signature-block", "name": "Signature block", "description": "Detached or embedded signature over the artifact or its digest, with the signature scheme identified.", "value_kind": "binary", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "signing-identity-ref", "name": "Signing identity reference", "description": "Reference to the key, certificate or workload identity that produced the signature.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "verification-outcome", "name": "Verification outcome", "description": "Result of a verification attempt, with verifier identity and observation time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] } ], "artifacts": [ { "id": "integrity-and-signature-record", "name": "Integrity and signature record", "description": "The bundle of digests, signatures and verification outcomes attached to a release's distributable artifacts.", "media_or_form": [ "checksum file", "detached signature", "structured record" ], "serial": false, "identity_strategy": "Keyed by the artifact content digest itself, which is the strongest available identity for a binary; the digest is bound to the release reference rather than replacing it.", "source_refs": [ "SRC-001", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "composition-and-supply-chain", "name": "Composition and Supply Chain", "description": "What the release is made of as declared in a bill of materials, how declared dependencies were resolved, and what provenance and development-practice evidence stands behind the build.", "rationale": "SBOM minimum elements make component name, version, supplier, unique identifier and dependency relationships mandatory, with declared depth and known unknowns; SLSA defines what provenance must state; SSDF defines the practice claims that condition how much weight that evidence carries.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006", "SRC-010", "SRC-011", "SRC-015" ], "layers": [ { "id": "declared-composition", "name": "Declared Composition", "description": "The bill of materials as a governed document about a release, and the dependency constraints and resolutions it records.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006", "SRC-015" ], "findings": [ { "id": "bill-of-materials-document", "name": "Bill of Materials Document", "description": "The SBOM treated as a dated, authored document about one release: its format and specification version, author, creation time, declared depth and explicitly declared known unknowns.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006", "SRC-015" ], "questions": [ { "id": "bom-author-identity", "text": "Who authored this bill of materials, and is that party the same as the software producer?", "kind": "provenance", "answer_data": [ "SBOM author reference", "producer reference", "generating tool name and version", "generation context" ] }, { "id": "bom-declared-depth", "text": "What depth does this bill of materials claim: top level only, direct dependencies, or complete transitive closure?", "kind": "measurement", "answer_data": [ "depth code", "component count", "closure completeness statement" ] }, { "id": "bom-known-unknowns", "text": "Which parts of the composition are declared known unknowns rather than silently omitted?", "kind": "quality", "answer_data": [ "known unknown entries", "reason code", "expected resolution" ] }, { "id": "bom-format-conformance", "text": "Which bill-of-materials format and specification version does the document conform to, and was that conformance verified?", "kind": "interoperability", "answer_data": [ "format name", "specification version", "validation tool and result" ] } ], "data_elements": [ { "id": "bom-format-code", "name": "BOM format", "description": "Named bill-of-materials format used for the document.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-002" ] }, { "id": "bom-spec-version", "name": "BOM specification version", "description": "Exact specification version the document claims to conform to.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-001" ] }, { "id": "bom-created-at", "name": "BOM creation time", "description": "RFC 3339 timestamp with seconds and offset recording when the document was generated, distinct from the release publication time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "bom-depth-code", "name": "Declared depth", "description": "The claimed traversal depth of the composition described.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "known-unknown-entry", "name": "Known unknown entry", "description": "Explicit declaration that a portion of the composition could not be determined, with reason.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "sbom-document", "name": "Bill of materials document", "description": "The machine-readable SBOM for a release, in whichever governed format the producer publishes, retained as an immutable versioned document.", "media_or_form": [ "machine-readable BOM document", "attached release asset", "registry-hosted document" ], "serial": true, "identity_strategy": "Keyed by the document's own governed identifier (document namespace or serial number) plus its creation timestamp; revisions create new documents linked to the same release rather than editing the prior document.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "dependency-graph-and-resolution", "name": "Dependency Graph and Resolution", "description": "Declared dependency constraints with scope and optionality, the concrete releases that satisfied them at build time, and the pinning that makes the resolution reproducible.", "source_refs": [ "SRC-002", "SRC-001", "SRC-006", "SRC-003" ], "questions": [ { "id": "dgr-declared-constraint", "text": "What constraint range and scope does the release declare for each dependency?", "kind": "composition", "answer_data": [ "constraint range expression", "dependency scope code", "optionality flag" ] }, { "id": "dgr-resolution", "text": "Which concrete component release satisfied each constraint at build time, and which resolver produced that resolution?", "kind": "relationship", "answer_data": [ "resolved component reference", "resolver identity and version", "resolution time" ] }, { "id": "dgr-resolution-drift", "text": "How is a later re-resolution distinguished from the resolution recorded at build time?", "kind": "temporal", "answer_data": [ "build-time resolution set", "current resolution set", "drift delta", "observation times" ] }, { "id": "dgr-pinning", "text": "Is the resolved dependency set pinned by a lockfile or digest so that the build can be reproduced?", "kind": "validation", "answer_data": [ "pinning mechanism", "lock digest", "reproduction evidence" ] } ], "data_elements": [ { "id": "dependency-declaration", "name": "Dependency declaration", "description": "A declared need on another component expressed as a constraint range with scope and optionality.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "resolved-component-ref", "name": "Resolved component reference", "description": "Reference into the component and package model for the release that actually satisfied a declared constraint.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "dependency-scope-code", "name": "Dependency scope", "description": "Whether the dependency is required, optional or excluded at the stated stage such as build, runtime or test.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "resolution-lock-digest", "name": "Resolution lock digest", "description": "Digest over the pinned resolution set that makes a rebuild verifiable.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "dependency-resolution-record", "name": "Dependency resolution record", "description": "The build-time snapshot binding each declared constraint to the concrete release that satisfied it, with resolver identity and lock digest.", "media_or_form": [ "lockfile", "structured record", "BOM dependency section" ], "serial": true, "identity_strategy": "Keyed by release reference plus resolution sequence number; each re-resolution is a new record so historical resolutions remain auditable.", "source_refs": [ "SRC-002", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "composition-coverage-and-completeness", "name": "Coverage, completeness and known unknowns", "description": "CISA 2026 replaces NTIA Depth with Coverage (horizontal and vertical breadth) and requires explicitly identifying unknown information. CycloneDX compositions aggregate completeness as complete, incomplete, incomplete first-party only, incomplete third-party only or unknown. SPDX Sbom may carry multiple sbomTypes. An SBOM that omits unknowns is less operable than one that marks them. Completeness is a quality measurement of the composition evidence, not of the software.", "source_refs": [ "SRC-018", "SRC-019" ], "inline_only_rationale": null, "data_elements": [ { "id": "composition-coverage-and-completeness-data01", "name": "Coverage statement", "description": "Horizontal and vertical coverage claimed", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "composition-coverage-and-completeness-data02", "name": "Completeness aggregate", "description": "CycloneDX composition aggregate value", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "composition-coverage-and-completeness-data03", "name": "Known unknowns", "description": "Explicit unknown component, license or dependency slots", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "composition-coverage-and-completeness-data04", "name": "First-party completeness", "description": "Whether first-party content is complete", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "composition-coverage-and-completeness-data05", "name": "Third-party completeness", "description": "Whether third-party content is complete", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [ { "id": "composition-coverage-and-completeness-artifact01", "name": "Completeness declaration", "description": "Machine-readable coverage and known-unknown statement for an SBOM or composition.", "media_or_form": [ "machine-readable completeness statement" ], "serial": false, "identity_strategy": "Keyed by the SBOM or composition it qualifies, carrying the aggregate value and explicit known-unknown slots rather than omissions.", "source_refs": [ "SRC-018", "SRC-019" ] } ], "questions": [ { "id": "composition-coverage-and-completeness-q01", "text": "What completeness aggregate applies to this composition, and is first-party or third-party content incomplete?", "kind": "measurement", "answer_data": [ "completeness-aggregate", "first-party-complete", "third-party-complete" ] }, { "id": "composition-coverage-and-completeness-q02", "text": "Which component, dependency, license or identifier fields are explicitly unknown rather than omitted?", "kind": "evidence", "answer_data": [ "known-unknowns" ] }, { "id": "composition-coverage-and-completeness-q03", "text": "What horizontal and vertical coverage does the producer claim relative to CISA 2026 Coverage, and what is out of that claim?", "kind": "constraint", "answer_data": [ "coverage-statement" ] } ] } ] }, { "id": "build-provenance", "name": "Build Provenance and Development Assurance", "description": "Verifiable statements about what built the release from which inputs, and about the producer's secure development practices.", "source_refs": [ "SRC-010", "SRC-011", "SRC-001" ], "findings": [ { "id": "build-provenance-attestation", "name": "Build Provenance Attestation", "description": "Machine-verifiable provenance identifying the build platform and builder, the top-level inputs and source revision, the parameters used, and the build-integrity level the provenance supports.", "source_refs": [ "SRC-011", "SRC-001", "SRC-010" ], "questions": [ { "id": "bpa-builder", "text": "Which build platform and builder identity produced this release?", "kind": "provenance", "answer_data": [ "builder identity", "build platform reference", "hosted or self-hosted flag" ] }, { "id": "bpa-inputs", "text": "What top-level inputs, parameters and source revision entered the build?", "kind": "process", "answer_data": [ "source revision reference", "build parameters", "external input digests" ] }, { "id": "bpa-level", "text": "What build-integrity level does the provenance support, and who verified that claim?", "kind": "evidence", "answer_data": [ "assurance level code", "verifying party", "verification time and result" ] }, { "id": "bpa-forgery-resistance", "text": "How is the provenance protected from forgery by the tenant whose build it describes?", "kind": "security", "answer_data": [ "signing arrangement", "tenant isolation controls", "key custody description" ] } ], "data_elements": [ { "id": "builder-id", "name": "Builder identity", "description": "Identity of the entity that executed the build, as asserted in the provenance.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "source-revision-ref", "name": "Source revision reference", "description": "Reference to the exact source revision consumed by the build, held as a reference to the source-control model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "provenance-predicate-type", "name": "Provenance predicate type", "description": "The attestation predicate type and version, so consumers know how to interpret the payload.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "assurance-level-code", "name": "Build assurance level", "description": "Claimed build track level, recorded with whether it is self-claimed or independently verified.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "provenance-attestation", "name": "Build provenance attestation", "description": "Signed attestation describing the build of a specific artifact, bound to that artifact by digest.", "media_or_form": [ "signed attestation envelope", "structured predicate document" ], "serial": false, "identity_strategy": "Keyed by the subject artifact digest plus predicate type; the attestation is never keyed by build date, and re-issued attestations are appended.", "source_refs": [ "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "development-practice-assurance", "name": "Secure Development Practice Assurance", "description": "Claims about the producer's secure development practices, the evidence for each claim, and whether the claim is self-attested, customer-audited or third-party assessed.", "source_refs": [ "SRC-010", "SRC-007" ], "questions": [ { "id": "dpa-claimed-practices", "text": "Which secure development framework practices does the producer claim, and over what organizational and product scope?", "kind": "requirement", "answer_data": [ "framework reference", "claimed practice identifiers", "scope statement" ] }, { "id": "dpa-evidence", "text": "What evidence substantiates each claimed practice, and who attested to it?", "kind": "evidence", "answer_data": [ "evidence artifact reference", "attesting party", "attestation time" ] }, { "id": "dpa-assurance-basis", "text": "Is each claim self-attested, customer-audited or assessed by an independent third party?", "kind": "authority", "answer_data": [ "attestation type code", "assessor reference", "assessment validity window" ] } ], "data_elements": [ { "id": "practice-claim", "name": "Practice claim", "description": "A single claimed practice with its framework identifier and scope.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "attestation-type-code", "name": "Attestation type", "description": "Basis of the claim: self-attestation, customer audit or third-party assessment.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "assessor-ref", "name": "Assessor reference", "description": "Reference to the party that assessed or audited the claim, where not self-attested.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-007" ] } ], "artifacts": [ { "id": "secure-development-attestation", "name": "Secure development attestation", "description": "The producer's statement of secure development practices with supporting evidence references and validity window.", "media_or_form": [ "attestation document", "structured record" ], "serial": true, "identity_strategy": "Keyed by producer reference plus framework reference plus attestation sequence number; a new attestation supersedes rather than edits the prior one.", "source_refs": [ "SRC-010" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "rights-and-licensing", "name": "Rights and Licensing", "description": "The licence under which a release is offered, the obligations inherited from third-party components, and the restrictions on who may use, receive or re-export it.", "rationale": "SPDX separates declared from concluded licensing and carries copyright and attribution text; SBOM minimum elements now include licence at component level. Obligations and restrictions determine whether a lawful deployment is possible at all, which no other layer answers.", "source_refs": [ "SRC-001", "SRC-006", "SRC-015" ], "layers": [ { "id": "license-identification", "name": "Licence Identification", "description": "What licence applies to a release, how it was determined, and who may change it.", "source_refs": [ "SRC-001", "SRC-006", "SRC-015" ], "findings": [ { "id": "license-declaration-and-expression", "name": "Licence Declaration and Expression", "description": "The licence expression applying to a release, distinguishing what the producer declared from what an analyst concluded, with the copyright holder and any licence change across releases.", "source_refs": [ "SRC-001", "SRC-015", "SRC-006" ], "questions": [ { "id": "lde-expression", "text": "What licence expression applies to this release as a whole, and in which expression syntax is it written?", "kind": "definition", "answer_data": [ "licence expression", "expression syntax and version", "scope of application" ] }, { "id": "lde-declared-vs-concluded", "text": "Where do the declared and the concluded licences differ, and on what evidence was the conclusion drawn?", "kind": "evidence", "answer_data": [ "declared expression", "concluded expression", "evidence reference", "concluding party" ] }, { "id": "lde-rights-holder", "text": "Who holds copyright in the product and who is empowered to relicense it?", "kind": "ownership", "answer_data": [ "copyright holder reference", "relicensing authority", "contributor agreement reference" ] }, { "id": "lde-license-change", "text": "Has the licence changed between releases, and does the change apply retroactively to prior releases?", "kind": "lifecycle", "answer_data": [ "change event time", "prior and new expression", "retroactivity statement" ] } ], "data_elements": [ { "id": "license-expression", "name": "Licence expression", "description": "Governed licence expression for the release, using a declared expression syntax and identifier list.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "license-determination-basis", "name": "Determination basis", "description": "Whether the expression is declared by the producer or concluded by analysis, with the determining party.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "copyright-text", "name": "Copyright text", "description": "Copyright statement as published with the artifact.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "copyright-holder-ref", "name": "Copyright holder reference", "description": "Reference to the rights-holder record in the intellectual property model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "license-declaration-record", "name": "Licence declaration record", "description": "Per-release record of the licence expression, its determination basis, evidence and rights holder.", "media_or_form": [ "licence file", "structured record", "BOM licensing section" ], "serial": false, "identity_strategy": "Keyed by release reference plus determination basis, so a declared and a concluded expression for the same release coexist without one silently overwriting the other.", "source_refs": [ "SRC-001", "SRC-015" ] } ], "inline_only_rationale": null } ] }, { "id": "obligations-and-restrictions", "name": "Obligations and Restrictions", "description": "What the product must ship or make available because of what it contains, and who may lawfully receive and use it.", "source_refs": [ "SRC-015", "SRC-006", "SRC-007" ], "findings": [ { "id": "third-party-attribution-obligations", "name": "Third-Party Attribution Obligations", "description": "Obligations inherited from bundled third-party components: attribution notices that must ship, reciprocal obligations and their reach, and corresponding-source availability duties with their duration.", "source_refs": [ "SRC-015", "SRC-001", "SRC-006" ], "questions": [ { "id": "tao-notices", "text": "Which attribution notices must ship with the product, and in what form must they be delivered?", "kind": "requirement", "answer_data": [ "notice text entries", "delivery form", "component references" ] }, { "id": "tao-reciprocal-reach", "text": "Which contained components impose reciprocal obligations, and how far do those obligations reach into the product?", "kind": "constraint", "answer_data": [ "component references", "obligation class", "reach determination and rationale" ] }, { "id": "tao-source-availability", "text": "Where is corresponding source made available for components that require it, and for how long must it stay available?", "kind": "retention", "answer_data": [ "source offer location", "availability period", "responsible party" ] } ], "data_elements": [ { "id": "attribution-notice-entry", "name": "Attribution notice entry", "description": "A single notice that must be reproduced, bound to the component that requires it.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "obligation-class-code", "name": "Obligation class", "description": "Classification of the obligation such as notice-only, reciprocal or source-availability.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "source-offer-location", "name": "Corresponding source location", "description": "Where corresponding source is offered, with the period for which the offer stands.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [ { "id": "attribution-notice-set", "name": "Attribution notice set", "description": "The compiled set of notices and offers shipped with a release to satisfy inherited obligations.", "media_or_form": [ "notice file", "document projection", "release asset" ], "serial": true, "identity_strategy": "Keyed by release reference plus notice-set sequence number; regenerated sets are new artifacts because the shipped notice is itself evidence of compliance at a point in time.", "source_refs": [ "SRC-015", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "use-and-export-restrictions", "name": "Use and Export Restrictions", "description": "Restrictions on who may obtain, run or re-export the product, including entitlement requirements, field-of-use exclusions, jurisdictional controls and documented waivers.", "source_refs": [ "SRC-007", "SRC-006", "SRC-001" ], "questions": [ { "id": "uer-entitlement", "text": "What entitlement is required to obtain and run this release lawfully?", "kind": "access", "answer_data": [ "entitlement type", "issuing party", "verification method" ] }, { "id": "uer-field-of-use", "text": "Which fields of use or deployment contexts are excluded by licence, contract or regulation?", "kind": "constraint", "answer_data": [ "excluded field of use", "source of the exclusion", "effective period" ] }, { "id": "uer-export-classification", "text": "Which export-control or sanctions classifications apply to this release, and who determined them?", "kind": "authority", "answer_data": [ "classification code", "determining party", "jurisdiction", "determination time" ] }, { "id": "uer-waiver", "text": "Under what documented exception may a restriction be waived, and who approves the waiver?", "kind": "exception", "answer_data": [ "waiver scope", "approving authority", "waiver validity window", "conditions" ] } ], "data_elements": [ { "id": "entitlement-requirement", "name": "Entitlement requirement", "description": "What a recipient must hold to obtain or run the release.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "field-of-use-exclusion", "name": "Field-of-use exclusion", "description": "A deployment context excluded by licence, contract or regulation.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "export-classification", "name": "Export classification", "description": "Jurisdiction-specific export control classification with the determining party.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "waiver-record", "name": "Waiver record", "description": "Documented exception to a restriction, with approver and validity window.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "restriction-register", "name": "Restriction register", "description": "Register of entitlement requirements, field-of-use exclusions, export classifications and approved waivers for a product or release line.", "media_or_form": [ "structured register", "compliance document" ], "serial": false, "identity_strategy": "Keyed by product master key plus jurisdiction; entries carry effective-from and effective-to times so lapsed restrictions remain auditable.", "source_refs": [ "SRC-007", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "deployment-and-operation", "name": "Deployment and Operation", "description": "Where releases actually run: deployed instances, their hosting environments, the configuration in effect and the interfaces they expose or consume.", "rationale": "Software has a second life as an operated system, and exposure questions are unanswerable from producer-side records alone. CycloneDX recognises operations and decommission lifecycle phases and separates services from components; CSAF product trees and SBOM access-control practice both presuppose an operator-held inventory.", "source_refs": [ "SRC-002", "SRC-006", "SRC-008", "SRC-004" ], "layers": [ { "id": "deployed-system-inventory", "name": "Deployed System Inventory", "description": "Concrete running installations and the environments that host them.", "source_refs": [ "SRC-002", "SRC-004", "SRC-006" ], "findings": [ { "id": "deployed-instance-record", "name": "Deployed Instance Record", "description": "One running installation of a specific release: its operator-side identifier, the version observed running, the window over which it ran, its purpose and its criticality.", "source_refs": [ "SRC-002", "SRC-004", "SRC-009" ], "questions": [ { "id": "dir-instance-identity", "text": "Which identifier denotes this deployed instance in the operator's authoritative inventory?", "kind": "identity", "answer_data": [ "instance identifier", "issuing inventory system", "operator reference" ] }, { "id": "dir-running-version", "text": "Which release is actually running on this instance, as observed rather than as intended?", "kind": "state", "answer_data": [ "running release reference", "observation method", "observation time", "intended release reference" ] }, { "id": "dir-run-window", "text": "Over which time window did this instance run this release, with event time and observation time recorded separately?", "kind": "temporal", "answer_data": [ "go-live event time", "decommission or upgrade event time", "observation timestamps" ] }, { "id": "dir-criticality", "text": "What business criticality and exposure does this instance carry?", "kind": "measurement", "answer_data": [ "criticality level", "exposure rating", "assessing party", "assessment time" ] } ], "data_elements": [ { "id": "instance-key", "name": "Instance key", "description": "Operator's authoritative identifier for the deployed instance.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "running-release-ref", "name": "Running release reference", "description": "Reference to the release observed running on the instance.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "deployment-observed-at", "name": "Deployment observation time", "description": "RFC 3339 timestamp with seconds and offset for when the running state was observed, distinct from the go-live event time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "deployment-window", "name": "Deployment window", "description": "Interval over which the instance ran the referenced release, bounded by go-live and change events.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "criticality-level", "name": "Criticality level", "description": "Operator's assessment of the instance's business criticality, used to prioritise advisory response.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "deployment-inventory-entry", "name": "Deployment inventory entry", "description": "Operator-owned record of one instance, its running release, observation evidence and criticality.", "media_or_form": [ "inventory record", "configuration item entry" ], "serial": false, "identity_strategy": "Keyed by the operator's authoritative instance identifier; where none exists, a Dimension-assigned ULID is minted and marked as such, never derived from a hostname or a date.", "source_refs": [ "SRC-004", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "hosting-environment-and-platform", "name": "Hosting Environment and Platform", "description": "The environment class, platform stack, jurisdictional location and network exposure of the host on which instances run.", "source_refs": [ "SRC-002", "SRC-007", "SRC-004" ], "questions": [ { "id": "hep-environment-class", "text": "Which environment class does this host: development, test, staging, production or disaster recovery?", "kind": "classification", "answer_data": [ "environment class code", "classifying party", "promotion path" ] }, { "id": "hep-platform-stack", "text": "What platform, operating system and runtime constitute the hosting stack for this instance?", "kind": "composition", "answer_data": [ "platform descriptor", "operating system reference", "runtime reference", "container or image digest" ] }, { "id": "hep-hosting-location", "text": "In which jurisdiction and region does hosting occur, and does that location constrain what may be processed there?", "kind": "spatial", "answer_data": [ "region identifier", "jurisdiction", "processing constraints" ] }, { "id": "hep-network-exposure", "text": "Is this instance reachable from the public internet, and through which controlled boundary?", "kind": "security", "answer_data": [ "exposure code", "boundary control description", "last verification time" ] } ], "data_elements": [ { "id": "environment-class-code", "name": "Environment class", "description": "Class of the hosting environment within the operator's promotion model.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "platform-descriptor", "name": "Platform descriptor", "description": "Operating system, runtime and image identification for the hosting stack, referencing component records rather than restating them.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "hosting-location", "name": "Hosting location", "description": "Region and jurisdiction in which the instance is hosted.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "network-exposure-code", "name": "Network exposure", "description": "Whether and how the instance is reachable from untrusted networks.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "environment-profile", "name": "Environment profile", "description": "Description of a hosting environment: class, platform stack, location and exposure posture, referenced by the instances it hosts.", "media_or_form": [ "structured profile", "infrastructure descriptor" ], "serial": false, "identity_strategy": "Keyed by the operator's environment identifier; profiles are versioned with effective-from times because platform stacks change under the instances that reference them.", "source_refs": [ "SRC-002", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "runtime-configuration-and-interfaces", "name": "Runtime Configuration and Interfaces", "description": "What the deployed software is actually doing: effective configuration and drift, and the external services and data flows it touches.", "source_refs": [ "SRC-002", "SRC-008", "SRC-007" ], "findings": [ { "id": "effective-configuration-state", "name": "Effective Configuration State", "description": "The configuration actually in effect on an instance, its deviation from the released default or hardened baseline, and the change events that produced it. This matters because exploitability assessments are frequently conditional on configuration.", "source_refs": [ "SRC-002", "SRC-008", "SRC-010" ], "questions": [ { "id": "ecs-effective-values", "text": "Which security-relevant configuration values are actually in effect on this instance, and when were they last observed?", "kind": "state", "answer_data": [ "configuration item values", "observation time", "collection method" ] }, { "id": "ecs-baseline-drift", "text": "How does the effective configuration differ from the release default or the hardened baseline?", "kind": "validation", "answer_data": [ "baseline reference", "deviation list", "risk annotation" ] }, { "id": "ecs-change-authorisation", "text": "Which change event last altered this configuration, and who authorised it?", "kind": "event", "answer_data": [ "change event time", "actor identity", "authorisation reference", "prior value" ] } ], "data_elements": [ { "id": "configuration-item", "name": "Configuration item", "description": "A single security-relevant configuration key and its effective value, with collection method.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "baseline-deviation", "name": "Baseline deviation", "description": "Difference between an effective value and its baseline value, with an annotation of consequence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "config-change-event", "name": "Configuration change event", "description": "Recorded change to configuration with actor, authorisation and RFC 3339 event time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] } ], "artifacts": [ { "id": "configuration-baseline-snapshot", "name": "Configuration baseline snapshot", "description": "Point-in-time capture of the effective configuration of an instance against a named baseline.", "media_or_form": [ "structured snapshot", "assessment report" ], "serial": true, "identity_strategy": "Keyed by instance key plus snapshot sequence number; snapshots are immutable observations and are never edited to reflect later reality.", "source_refs": [ "SRC-010", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "external-interfaces-and-data-flows", "name": "External Interfaces and Data Flows", "description": "Services, endpoints and data flows a deployed instance exposes or consumes, including third-party services that are dependencies but never shipped as components.", "source_refs": [ "SRC-002", "SRC-007" ], "questions": [ { "id": "eid-external-services", "text": "Which external services does this instance call, and are they recorded as services rather than as shipped components?", "kind": "composition", "answer_data": [ "service reference", "provider reference", "criticality of the call path" ] }, { "id": "eid-data-categories", "text": "What categories of data cross each interface, and is any of it personal or otherwise regulated?", "kind": "privacy", "answer_data": [ "data category codes", "regulated flag", "applicable regime reference" ] }, { "id": "eid-interface-authorisation", "text": "How is each interface authenticated and authorised, and where are its credentials held?", "kind": "access", "answer_data": [ "authentication mechanism", "authorisation model", "credential custody location" ] } ], "data_elements": [ { "id": "interface-descriptor", "name": "Interface descriptor", "description": "An exposed or consumed endpoint with protocol, direction and trust boundary crossed.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "service-dependency-ref", "name": "Service dependency reference", "description": "Reference to an external service the instance depends on, modelled as a service rather than a component.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "data-category-code", "name": "Data category", "description": "Category of data crossing an interface, flagged where it is personal or regulated.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "interface-and-flow-register", "name": "Interface and data-flow register", "description": "Operator-owned register of interfaces, service dependencies and data categories per instance or environment.", "media_or_form": [ "structured register", "service BOM section" ], "serial": false, "identity_strategy": "Keyed by instance or environment key plus interface identifier; entries carry validity windows because interfaces are added and retired independently of releases.", "source_refs": [ "SRC-002", "SRC-007" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "lifecycle-support-and-security-response", "name": "Lifecycle, Support and Security Response", "description": "How long the product is maintained, how fixes are delivered, and how published vulnerabilities are mapped to versions, instances and exploitability judgements.", "rationale": "The Cyber Resilience Act obliges manufacturers to handle vulnerabilities across the lifecycle and to report actively exploited vulnerabilities; CSAF supplies the machine-readable advisory and VEX structure; ISO/IEC/IEEE 12207 frames maintenance and disposal. These are distinct decision surfaces from composition.", "source_refs": [ "SRC-004", "SRC-007", "SRC-008", "SRC-010", "SRC-014" ], "layers": [ { "id": "support-lifecycle", "name": "Support Lifecycle", "description": "Support status, end-of-life milestones and the mechanics by which fixes reach deployed instances.", "source_refs": [ "SRC-004", "SRC-007", "SRC-010" ], "findings": [ { "id": "support-status-and-end-of-life", "name": "Support Status and End of Life", "description": "The producer's binding statement about how long a product line or release receives fixes, the dated milestones that end that obligation, and what happens to instances that outlive it.", "source_refs": [ "SRC-007", "SRC-004", "SRC-009" ], "questions": [ { "id": "ssl-current-status", "text": "What support status applies to this release line today, and who set it?", "kind": "state", "answer_data": [ "support status code", "status effective time", "setting party" ] }, { "id": "ssl-milestones", "text": "What are the announced end-of-support and end-of-life dates, and when were they announced?", "kind": "temporal", "answer_data": [ "end-of-support date", "end-of-life date", "announcement event time", "announcement reference" ] }, { "id": "ssl-regulatory-minimum", "text": "Does the declared support period satisfy the applicable regulatory minimum for the expected product lifetime?", "kind": "requirement", "answer_data": [ "regime reference", "required minimum period", "declared period", "gap assessment" ] }, { "id": "ssl-post-support", "text": "What happens to deployed instances that remain in service after end of support, and who accepts the residual risk?", "kind": "exception", "answer_data": [ "continuation policy", "risk acceptance record", "extended support option" ] } ], "data_elements": [ { "id": "support-status-code", "name": "Support status", "description": "Current support state of a release line such as full support, maintenance only, security fixes only, or ended.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "end-of-support-date", "name": "End-of-support date", "description": "Announced date after which fixes cease, stored as a date and never used as an identifier.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "lifecycle-announcement-event", "name": "Lifecycle announcement event", "description": "The announcement that set or changed a lifecycle milestone, with RFC 3339 event time and publisher.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-007" ] }, { "id": "support-period-declared", "name": "Declared support period", "description": "Length of the committed support period for the product, used to test against regulatory minimums.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "lifecycle-statement", "name": "Product lifecycle statement", "description": "The producer's published statement of support status and end-of-life milestones for a product or release line.", "media_or_form": [ "published policy page", "structured record" ], "serial": true, "identity_strategy": "Keyed by product master key plus release-line reference plus statement sequence number; each revision is a new statement so prior commitments remain provable.", "source_refs": [ "SRC-007", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "update-and-patch-delivery", "name": "Update and Patch Delivery", "description": "How fixes reach deployed instances: channels, mechanism, default automation, separability of security fixes from feature change, and evidence that an update was actually applied.", "source_refs": [ "SRC-007", "SRC-010", "SRC-002" ], "questions": [ { "id": "upd-mechanism", "text": "By what mechanism are security updates delivered, and are they applied automatically by default?", "kind": "process", "answer_data": [ "update mechanism code", "default automation flag", "opt-out conditions" ] }, { "id": "upd-separability", "text": "Are security fixes separable from feature changes so that an operator can apply one without the other?", "kind": "requirement", "answer_data": [ "separability statement", "security-only channel reference", "exceptions" ] }, { "id": "upd-application-evidence", "text": "What record proves that a given instance received and applied a given update?", "kind": "evidence", "answer_data": [ "update application record", "applying actor", "application time", "verification method" ] } ], "data_elements": [ { "id": "update-channel", "name": "Update channel", "description": "Named channel through which updates are published to consumers.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "auto-update-default", "name": "Automatic update default", "description": "Whether updates are applied automatically unless the operator opts out.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "update-application-record", "name": "Update application record", "description": "Evidence that a specific instance applied a specific update, with actor and RFC 3339 event time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-009" ] } ], "artifacts": [ { "id": "update-delivery-record", "name": "Update delivery record", "description": "Record of an update's publication and of its application to specific instances.", "media_or_form": [ "structured record", "operations log projection" ], "serial": true, "identity_strategy": "Keyed by release reference plus instance key plus application sequence number; publication and application are separate events with separate times.", "source_refs": [ "SRC-010", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "vulnerability-and-advisory", "name": "Vulnerability and Advisory", "description": "Published notices affecting the product and the product-specific judgement of whether a contained vulnerability is actually exploitable.", "source_refs": [ "SRC-008", "SRC-014", "SRC-007" ], "findings": [ { "id": "advisory-and-exposure-mapping", "name": "Advisory and Exposure Mapping", "description": "Notices of defects or vulnerabilities and the mapping from each notice to affected version ranges, contained components and deployed instances, with severity and any authority-reporting duty.", "source_refs": [ "SRC-008", "SRC-014", "SRC-007" ], "questions": [ { "id": "aem-advisory-identity", "text": "Which advisory and vulnerability identifiers apply, who published them, and at which tracking version?", "kind": "provenance", "answer_data": [ "advisory identifier", "vulnerability identifier", "publisher reference", "tracking version and current release time" ] }, { "id": "aem-affected-ranges", "text": "Which version ranges of this product are declared affected, fixed, or under investigation?", "kind": "relationship", "answer_data": [ "affected version ranges", "fixed version references", "range expression syntax" ] }, { "id": "aem-severity", "text": "What severity or exploitability scores are asserted, by which scoring system and which scoring party?", "kind": "measurement", "answer_data": [ "score value and vector", "scoring system version", "scoring party", "score time" ] }, { "id": "aem-authority-reporting", "text": "When must an actively exploited vulnerability in this product be reported, and to which authority?", "kind": "requirement", "answer_data": [ "reporting trigger", "reporting deadline", "recipient authority", "submission evidence" ] } ], "data_elements": [ { "id": "advisory-id", "name": "Advisory identifier", "description": "Publisher-issued advisory identifier with its tracking version and current release time.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "vulnerability-id", "name": "Vulnerability identifier", "description": "Reference to the governed vulnerability record, not a copy of it.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "affected-version-range", "name": "Affected version range", "description": "Version range declared affected, with the range expression syntax and default status.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-008" ] }, { "id": "severity-score", "name": "Severity score", "description": "Asserted score with vector, scoring system version and asserting party.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "advisory-publish-time", "name": "Advisory publication time", "description": "Initial and current release times of the advisory, recorded as RFC 3339 date-times with seconds and offset.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] } ], "artifacts": [ { "id": "security-advisory", "name": "Security advisory document", "description": "Machine-readable advisory identifying affected products, remediations, scores and threats.", "media_or_form": [ "machine-readable advisory document", "published notice page" ], "serial": true, "identity_strategy": "Keyed by publisher namespace plus advisory tracking identifier plus tracking version; revisions increment the tracking version rather than replacing the document identity.", "source_refs": [ "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "exploitability-assessment", "name": "Exploitability Assessment", "description": "The product-specific determination of whether a vulnerability present in a contained component is actually exploitable in this product or deployment, with a recognised justification and its conditions.", "source_refs": [ "SRC-008", "SRC-006", "SRC-010" ], "questions": [ { "id": "exa-status", "text": "What is this product's status for the vulnerability: affected, not affected, fixed, or under investigation?", "kind": "state", "answer_data": [ "status code", "status setting party", "status time" ] }, { "id": "exa-justification", "text": "If the product is not affected, which recognised justification applies and what evidence supports it?", "kind": "evidence", "answer_data": [ "justification code", "supporting evidence reference", "analysing party" ] }, { "id": "exa-conditions", "text": "Does the assessment hold for all deployments, or only under stated configuration or environment conditions?", "kind": "constraint", "answer_data": [ "applicability conditions", "configuration references", "environment class scope" ] }, { "id": "exa-reassessment", "text": "What triggers re-assessment, and how is a superseded assessment retained?", "kind": "lifecycle", "answer_data": [ "re-assessment trigger", "superseding statement reference", "retention rule for prior statements" ] } ], "data_elements": [ { "id": "exploitability-status-code", "name": "Exploitability status", "description": "Product status for a specific vulnerability, drawn from the governing exchange vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "justification-code", "name": "Justification code", "description": "Recognised reason for a not-affected status, from the governing vocabulary rather than free text.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "applicability-condition", "name": "Applicability condition", "description": "Configuration or environment conditions under which the assessment holds.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "assessment-revision", "name": "Assessment revision", "description": "Revision number and time of the assessment, with the superseded statement retained.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] } ], "artifacts": [ { "id": "vex-statement", "name": "Exploitability exchange statement", "description": "Published statement of product status and justification for a specific vulnerability, consumable alongside the SBOM.", "media_or_form": [ "machine-readable exchange document", "advisory profile section" ], "serial": true, "identity_strategy": "Keyed by product reference plus vulnerability reference plus statement revision; statements are versioned and never overwritten, because a withdrawn not-affected claim is itself material evidence.", "source_refs": [ "SRC-008", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "remediation-and-fix-access", "name": "Remediation, entitlements and restart", "description": "CSAF remediations carry category, date, details, product or group ids, URL, restart-required and entitlements. Entitlements here are access gates on a remediation (who may obtain the fix), not the intellectual-property license of the software. CoSWID activation-status and entitlement-key similarly record install-time activation without storing unprotected license secrets. Restart-required is an operational constraint on deployed systems.", "source_refs": [ "SRC-008", "SRC-016" ], "inline_only_rationale": null, "data_elements": [ { "id": "remediation-and-fix-access-data01", "name": "Remediation category", "description": "vendor_fix, workaround, mitigation, none_available or no_fix_planned", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "remediation-and-fix-access-data02", "name": "Remediation URL", "description": "Locator of the fix or guidance", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "remediation-and-fix-access-data03", "name": "Restart required", "description": "Whether and how a restart is required", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "remediation-and-fix-access-data04", "name": "Remediation entitlements", "description": "Who is entitled to obtain the fix", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "remediation-and-fix-access-data05", "name": "Activation status", "description": "trial, licensed, unlicensed or similar CoSWID activation-status", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "remediation-and-fix-access-artifact01", "name": "Remediation record", "description": "Fix, workaround or mitigation bound to products, with entitlement and restart constraints.", "media_or_form": [ "structured remediation record" ], "serial": false, "identity_strategy": "Keyed by advisory tracking id plus remediation category and the product or product group ids it addresses.", "source_refs": [ "SRC-008" ] } ], "questions": [ { "id": "remediation-and-fix-access-q01", "text": "What remediation category and URL are offered for the affected products, and on which date was that remediation published?", "kind": "process", "answer_data": [ "remediation-category", "remediation-url" ] }, { "id": "remediation-and-fix-access-q02", "text": "Does applying the remediation require a restart, and of what kind?", "kind": "constraint", "answer_data": [ "restart-required" ] }, { "id": "remediation-and-fix-access-q03", "text": "Which entitlements gate access to the fix, and what activation status applies to the installed product?", "kind": "access", "answer_data": [ "remediation-entitlements", "activation-status" ] } ] } ] } ] }, { "id": "quality-conformance-and-regulatory", "name": "Quality, Conformance and Regulatory", "description": "What quality the product is specified and measured against, what verification evidence exists, and what regulatory documentation must be produced and retained to place it on a market.", "rationale": "ISO/IEC 25010 supplies a governed quality model for specification and evaluation; the Cyber Resilience Act attaches conformity assessment, CE marking and technical documentation duties to products with digital elements. Both are decision surfaces an agent must be able to interrogate and neither is covered by composition or operations layers.", "source_refs": [ "SRC-005", "SRC-007", "SRC-004", "SRC-010" ], "layers": [ { "id": "quality-and-verification", "name": "Quality and Verification", "description": "Specified quality characteristics with their measures, and the evidence that a release was verified against them.", "source_refs": [ "SRC-005", "SRC-004", "SRC-010" ], "findings": [ { "id": "quality-characteristics-and-measures", "name": "Quality Characteristics and Measures", "description": "The quality characteristics selected for this product from a governed quality model, the measure and target defined for each, and the values actually measured on a named release.", "source_refs": [ "SRC-005", "SRC-004" ], "questions": [ { "id": "qcm-model-selection", "text": "Which quality model and which of its characteristics are used to specify this product's quality requirements?", "kind": "classification", "answer_data": [ "quality model reference and version", "selected characteristics and subcharacteristics", "selection rationale" ] }, { "id": "qcm-measure-definition", "text": "What measure, measurement method and target value are defined for each selected characteristic?", "kind": "measurement", "answer_data": [ "measure definition", "measurement method", "target value and unit" ] }, { "id": "qcm-measured-values", "text": "What values were actually measured, on which release, and under which stated conditions?", "kind": "quality", "answer_data": [ "measured value", "release reference", "measurement conditions", "measurement time" ] } ], "data_elements": [ { "id": "quality-characteristic-code", "name": "Quality characteristic", "description": "Characteristic or subcharacteristic selected from the declared quality model.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "quality-measure", "name": "Quality measure", "description": "Definition of the measure and method used to evaluate a characteristic.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "quality-target-value", "name": "Target value", "description": "Target or acceptance threshold for a measure, with unit.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "quality-measured-value", "name": "Measured value", "description": "Observed value for a measure on a named release, with measurement time and conditions.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "quality-measurement-report", "name": "Quality measurement report", "description": "Report of measures, targets and measured values for a release against the declared quality model.", "media_or_form": [ "measurement report", "structured record" ], "serial": true, "identity_strategy": "Keyed by release reference plus quality model reference plus report sequence number; reports are immutable observations tied to the release they measured.", "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "verification-and-test-evidence", "name": "Verification and Test Evidence", "description": "Evidence that a release was verified: which activities were performed, how each result binds to the exact artifact digest tested, and which defects were knowingly accepted at release.", "source_refs": [ "SRC-010", "SRC-011", "SRC-004" ], "questions": [ { "id": "vte-activities", "text": "Which verification activities were performed against this release, and by whom?", "kind": "process", "answer_data": [ "activity type", "performing party", "activity time", "scope covered" ] }, { "id": "vte-artifact-binding", "text": "How is each verification result bound to the exact artifact digest it was run against?", "kind": "validation", "answer_data": [ "subject artifact digest", "binding method", "result reference" ] }, { "id": "vte-accepted-defects", "text": "Which known defects were accepted as open at release, and who accepted the residual risk?", "kind": "decision", "answer_data": [ "defect references", "acceptance rationale", "accepting party", "acceptance time" ] } ], "data_elements": [ { "id": "verification-activity", "name": "Verification activity", "description": "A performed verification activity with its type, scope and performing party.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "evidence-artifact-digest", "name": "Evidence subject digest", "description": "Digest of the artifact the evidence describes, binding evidence to a specific build.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "accepted-defect", "name": "Accepted defect", "description": "Known open defect accepted at release, with accepting party and rationale.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "verification-evidence-package", "name": "Verification evidence package", "description": "The collected verification results for a release, each bound to the artifact digest it describes.", "media_or_form": [ "evidence package", "test report", "attestation set" ], "serial": true, "identity_strategy": "Keyed by subject artifact digest plus evidence package sequence number, so evidence cannot silently migrate to a different build of the same version.", "source_refs": [ "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "regulatory-conformity", "name": "Regulatory Conformity", "description": "Which market regimes apply, which conformity route was taken, and what documentation must exist and be retained.", "source_refs": [ "SRC-007", "SRC-004" ], "findings": [ { "id": "conformity-and-technical-documentation", "name": "Conformity Assessment and Technical Documentation", "description": "The regulatory regimes in scope for placing the product on each target market, the conformity assessment route used, the declaration or marking issued, and the technical documentation with its retention duty.", "source_refs": [ "SRC-007", "SRC-004", "SRC-006" ], "questions": [ { "id": "ctd-applicable-regimes", "text": "Which product-regulation regimes apply to this product in each target market, and from which date?", "kind": "requirement", "answer_data": [ "regime reference", "market or jurisdiction", "applicability date", "applicability determination party" ] }, { "id": "ctd-conformity-route", "text": "Which conformity assessment route was used, and who performed the assessment?", "kind": "authority", "answer_data": [ "route code", "assessing body reference", "assessment outcome and date" ] }, { "id": "ctd-documentation-retention", "text": "What technical documentation must exist, and for how long must it be retained after the product is placed on the market?", "kind": "retention", "answer_data": [ "documentation inventory", "retention period", "custodian", "storage location" ] }, { "id": "ctd-declaration", "text": "What declaration of conformity or marking is issued, and against exactly which release does it hold?", "kind": "evidence", "answer_data": [ "declaration reference", "marking applied", "covered release references", "signatory" ] } ], "data_elements": [ { "id": "regulatory-regime-ref", "name": "Regulatory regime reference", "description": "Reference to an applicable product-regulation regime and the market it governs.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "conformity-route-code", "name": "Conformity assessment route", "description": "The assessment procedure used, including whether a third party was involved.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "declaration-of-conformity-ref", "name": "Declaration of conformity reference", "description": "Reference to the issued declaration and the exact releases it covers.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "documentation-retention-period", "name": "Documentation retention period", "description": "Period for which technical documentation must be kept available to authorities.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "technical-documentation-file", "name": "Technical documentation file", "description": "The dossier a manufacturer must be able to produce for market surveillance, assembled from identity, composition, provenance, verification and lifecycle findings.", "media_or_form": [ "dossier", "document set", "structured export" ], "serial": true, "identity_strategy": "Keyed by product master key plus regime reference plus dossier sequence number; each release covered is referenced explicitly, and superseded dossiers are retained for the full statutory period.", "source_refs": [ "SRC-007" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "register-product", "name": "Register software product", "description": "Create the product identity record, binding a master-system identifier, namespace, canonical name and producer reference before any release, licence or deployment statement may attach to it.", "inputs": [ "Producer organization reference", "Proposed canonical name and namespace", "Master-system identifier and issuing system, or a declaration that none exists" ], "outputs": [ "Product identity card", "Assigned product key with its identity tier recorded" ], "preconditions": [ "The producer organization reference resolves in the organization model", "No existing product record already claims the same master key in the same namespace" ], "effects": [ "Product becomes addressable for release, licensing, deployment and advisory records", "Identity tier (master-system, governed global, or Dimension-assigned) is fixed and auditable" ], "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "publish-release", "name": "Publish release", "description": "Record a published version of the product with its publication event time, observation time, channel, state and at least one integrity value.", "inputs": [ "Product key", "Verbatim version string", "Publication event time", "Distribution locations", "Artifact digests" ], "outputs": [ "Release manifest", "Release state set to the declared publication state", "Ordering key derived from the declared version scheme" ], "preconditions": [ "A version scheme declaration exists for the product line", "At least one hash entry is supplied for each distributable artifact" ], "effects": [ "Release facts become immutable; later corrections must be new superseding statements", "Dependency, advisory and deployment records may now reference this release" ], "source_refs": [ "SRC-002", "SRC-006", "SRC-009" ] }, { "id": "attach-bill-of-materials", "name": "Attach bill of materials", "description": "Associate a versioned, authored bill-of-materials document with a specific release, recording format, specification version, author, creation time, declared depth and known unknowns.", "inputs": [ "Release reference", "BOM document", "BOM author reference", "Declared depth" ], "outputs": [ "Stored SBOM document with its own governed identifier", "Extracted dependency declarations and component references" ], "preconditions": [ "The release exists and is not in a withdrawn state without an explicit override", "The BOM document validates against its claimed specification version" ], "effects": [ "Composition becomes queryable and joinable to component records in WM-SFT-007", "Known unknowns are surfaced positively rather than presenting the SBOM as complete" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-006" ] }, { "id": "verify-artifact-integrity", "name": "Verify artifact integrity", "description": "Check a fetched artifact against its published digests, signatures and provenance attestation, and record the verification outcome with the verifier identity and time.", "inputs": [ "Artifact bytes or fetched reference", "Published hash entries", "Signature and trust anchor", "Provenance attestation where available" ], "outputs": [ "Verification outcome record", "Pass or fail decision with reasons" ], "preconditions": [ "At least one published hash entry exists for the artifact", "A trust anchor is configured for signature validation where signatures are claimed" ], "effects": [ "A failing verification blocks promotion of the artifact and raises an exception record", "A passing verification binds downstream evidence to the artifact digest" ], "source_refs": [ "SRC-001", "SRC-011", "SRC-010" ] }, { "id": "resolve-dependency-set", "name": "Resolve dependency set", "description": "Evaluate declared dependency constraints against available component releases, record the concrete resolution with resolver identity and lock digest, and preserve the build-time resolution distinctly from any later re-resolution.", "inputs": [ "Release reference", "Declared dependency constraints", "Component release catalogue reference", "Resolver identity and version" ], "outputs": [ "Dependency resolution record", "Lock digest over the pinned resolution set" ], "preconditions": [ "Each constraint uses a range syntax compatible with the declared version scheme", "Component references resolve in WM-SFT-007" ], "effects": [ "Resolution becomes reproducible and comparable across time", "Drift between build-time and current resolution can be computed" ], "source_refs": [ "SRC-002", "SRC-003", "SRC-011" ] }, { "id": "record-deployment-observation", "name": "Record deployment observation", "description": "Record that a specific instance was observed running a specific release in a specific environment, with the observation method and time kept separate from the go-live event time.", "inputs": [ "Instance key", "Observed release reference", "Environment reference", "Observation method and time" ], "outputs": [ "Deployment inventory entry or a new observation on an existing entry", "Updated running-release state with provenance" ], "preconditions": [ "The operator owner package holds write authority for the instance", "The referenced release exists in the release lineage" ], "effects": [ "Exposure queries from advisories to instances become answerable", "Discrepancy between intended and observed release is made visible rather than reconciled silently" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-009" ] }, { "id": "assess-vulnerability-exposure", "name": "Assess vulnerability exposure", "description": "Map an advisory to affected releases through the bill of materials, then to deployed instances, then record a product-specific exploitability status with a recognised justification and its applicability conditions.", "inputs": [ "Advisory document", "Affected version ranges", "Bill-of-materials index", "Deployment inventory" ], "outputs": [ "Exposure set of releases and instances", "Exploitability exchange statement with status, justification and conditions" ], "preconditions": [ "Affected ranges are expressed in a syntax evaluable against the declared version scheme", "The assessing party holds authority to publish a binding product status" ], "effects": [ "A prior assessment is superseded, not overwritten, and remains retrievable", "Cross-operator instance reads are time-boxed and logged as an access exception" ], "source_refs": [ "SRC-008", "SRC-014", "SRC-006" ] }, { "id": "declare-end-of-support", "name": "Declare end of support", "description": "Publish or revise a lifecycle statement setting support status and end-of-support or end-of-life milestones for a product or release line, and test the declared period against applicable regulatory minimums.", "inputs": [ "Product key and release-line reference", "Proposed support status and milestone dates", "Applicable regulatory regime references" ], "outputs": [ "New lifecycle statement", "Gap assessment against the required minimum support period" ], "preconditions": [ "The declaring party holds binding authority for the product", "Milestone dates are stated as dates and the announcement carries an RFC 3339 event time" ], "effects": [ "Instances running affected releases are flagged for post-support risk acceptance", "Prior lifecycle statements are retained so earlier commitments remain provable" ], "source_refs": [ "SRC-007", "SRC-004", "SRC-009" ] }, { "id": "compile-conformity-dossier", "name": "Compile conformity dossier", "description": "Assemble the technical documentation required by an applicable market regime from identity, composition, provenance, verification, licensing and lifecycle findings, and place it under the regime's retention duty.", "inputs": [ "Product key", "Regime reference and target market", "Covered release references", "Evidence artifact references" ], "outputs": [ "Technical documentation file", "Coverage report listing missing or stale evidence" ], "preconditions": [ "A conformity assessment route has been determined for the regime", "Each referenced evidence artifact is bound to a covered release by digest" ], "effects": [ "Retention floor for the dossier is applied and overrides routine housekeeping deletion", "Disclosure of the dossier is logged with recipient and legal basis" ], "source_refs": [ "SRC-007", "SRC-006" ] }, { "id": "revise-identification-tag", "name": "Revise identification tag", "description": "Increment tag-version to correct metadata without changing software-version.", "inputs": [ "Existing identification tag", "Corrected metadata" ], "outputs": [ "Identification tag with incremented tag-version" ], "preconditions": [ "The software-version is unchanged" ], "effects": [ "Tag metadata is corrected without creating a new software version" ], "source_refs": [ "SRC-016" ] }, { "id": "apply-patch-tag", "name": "Apply patch tag", "description": "Install a patch tag linked with rel=patches that must not change software-version, or perform an upgrade that replaces primary tags.", "inputs": [ "Patched release reference", "Patch or upgrade package" ], "outputs": [ "Patch tag linked with rel=patches, or replaced primary tags after an upgrade" ], "preconditions": [ "A patch tag must not change software-version" ], "effects": [ "Installed state reflects the patch or upgrade", "Primary tags are replaced when the version changes" ], "source_refs": [ "SRC-016", "SRC-021" ] }, { "id": "withdraw-release", "name": "Withdraw or yank release", "description": "Mark a published version withdrawn or yanked while retaining historical identity for exposure analysis.", "inputs": [ "Release identifier", "Withdrawal or yank event time" ], "outputs": [ "Updated publication status", "Publication event log entry" ], "preconditions": [ "The release was previously published on the channel" ], "effects": [ "The version is marked withdrawn or yanked and its historical identity is retained for exposure matching" ], "source_refs": [ "SRC-016", "SRC-004" ] }, { "id": "issue-advisory", "name": "Issue advisory", "description": "Publish a CSAF document with tracking identity, publisher authority, TLP and product tree.", "inputs": [ "Publisher namespace and issuing authority", "Product tree", "TLP label" ], "outputs": [ "CSAF advisory document" ], "preconditions": [ "A document tracking identifier, version and status are assigned" ], "effects": [ "A machine-readable advisory exists with revision history and distribution constraints" ], "source_refs": [ "SRC-008" ] }, { "id": "disclose-sbom-or-inventory", "name": "Disclose SBOM or inventory", "description": "Share a catalogue, SBOM or operator inventory under TLP, contractual and access-scope rules, auditing disclosure separately from public product pages.", "inputs": [ "Catalogue, SBOM or inventory artifact", "Recipient scope", "TLP label" ], "outputs": [ "Disclosure export carrying its TLP label and recipient scope" ], "preconditions": [ "An explicit scope grant from the owning steward exists for non-public content" ], "effects": [ "The disclosure is recorded in the audit log separately from public product pages" ], "source_refs": [ "SRC-018", "SRC-008" ] }, { "id": "retire-deployment", "name": "Retire deployment", "description": "Decommission a deployed system and remove corresponding primary, patch and supplemental tags per the SWID/CoSWID lifecycle.", "inputs": [ "Deployed system identifier", "Decommission event time" ], "outputs": [ "Updated operations inventory record" ], "preconditions": [], "effects": [ "Primary, patch and supplemental tags are removed per the SWID/CoSWID lifecycle", "The deployed system is marked decommissioned" ], "source_refs": [ "SRC-016", "SRC-004" ] } ], "composition": [ { "target": "WM-SFT-007 Software Component and Package", "relation": "COMPOSE", "purpose": "Product releases are composed of components and packages whose own identity, ecosystem metadata and internal files are modelled there. This model holds the composition relation, the declared constraint and the recorded resolution; it does not restate component internals.", "required": true, "source_refs": [ "SRC-001", "SRC-002", "SRC-006" ] }, { "target": "Organization model (producer, supplier, distributor, operator)", "relation": "REFERENCE", "purpose": "Producer, supplier, SBOM author, advisory publisher and deployment operator are all party references. Candidate sibling, not confirmed in the registry relations; recorded as a reference obligation rather than an assumed link.", "required": true, "source_refs": [ "SRC-001", "SRC-006", "SRC-008" ] }, { "target": "Intellectual property and rights model", "relation": "REFERENCE", "purpose": "Copyright holders, relicensing authority and the underlying rights instruments behind a licence expression live outside this model; only the expression, its determination basis and a holder reference are held here.", "required": false, "source_refs": [ "SRC-001", "SRC-015" ] }, { "target": "Identifier and naming scheme model", "relation": "REFERENCE", "purpose": "Governance of purl types, the CPE dictionary and tag-issuer rules belongs to the identifier model; this model records which coordinates denote the product and how scheme conflicts are resolved per use.", "required": false, "source_refs": [ "SRC-003", "SRC-013" ] }, { "target": "Dataset model", "relation": "REFERENCE", "purpose": "Datasets consumed or produced by the software, including training data for AI-enabled products, are referenced rather than described. SPDX carries a separate Dataset profile for exactly this separation.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "Vulnerability record model (CVE Program record format)", "relation": "REFERENCE", "purpose": "Vulnerability records, weakness classifications and scoring vectors are governed externally; this model references the identifier and holds only the product's exposure and exploitability judgement.", "required": false, "source_refs": [ "SRC-014", "SRC-008" ] }, { "target": "AI system and model model", "relation": "EXTEND", "purpose": "Where the product is AI-enabled, model cards, training provenance and model-specific evaluation extend this model rather than duplicating into it; both SPDX and CycloneDX treat this as a separate profile or object.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "SPDX Specification 3.0.1", "relation": "ALIGN", "purpose": "Alignment for element identity, artifact and package structure, relationships, creation information, integrity methods, external identifiers and the Software, Security, Licensing and Build profiles. Alignment only; no conformance is claimed without a cited conformance artifact.", "required": false, "source_refs": [ "SRC-001", "SRC-015" ] }, { "target": "CycloneDX v1.6 (ECMA-424)", "relation": "ALIGN", "purpose": "Alignment for BOM metadata, component typing, services, dependency graph, compositions, lifecycle phases, formulation and declarations. Component-versus-package granularity differs from SPDX and is recorded as a conflict rather than harmonised silently.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "ECMA-427 Package-URL (PURL)", "relation": "ALIGN", "purpose": "Alignment for the governed global coordinate used to identify the distributed form of a release across ecosystems; purl is a coordinate, never the master key.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "OASIS CSAF v2.0 including the VEX profile", "relation": "ALIGN", "purpose": "Alignment for advisory tracking, product trees with identification helpers, product status vocabularies, remediations, scores and threats used by the advisory and exploitability findings.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "ISO/IEC/IEEE 12207:2026 and ISO/IEC 25010:2023", "relation": "ALIGN", "purpose": "Alignment for life cycle stage vocabulary (acquisition, supply, development, operation, maintenance, disposal) and for the product quality characteristics used to specify and measure quality. Full texts are paywalled, so alignment is at catalogue-scope level and flagged as an evidence gap.", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must nominate a producer-side owner package for identity, classification, release, licensing, composition and provenance records, and a separate operator-side owner package for deployment, environment, effective-configuration and interface records; a single package owning both is a governance failure because it lets producer intent silently overwrite operational observation.", "Each owner package must name its authoritative master system per artifact class and state, for every record it writes, which identity tier was used: master-system identifier, governed global identifier, or Dimension-assigned ULID.", "Each owner package must publish a resolvable namespace, an advisory intake route and a disclosure contact, since advisory reporting duties and SBOM distribution requests arrive from outside the Dimension.", "The Dimension must declare, per external standard it aligns to, the exact specification version pinned for each record, and must not present alignment as conformance without a cited conformance artifact." ], "namespace_guidance": "Use a registry-scoped or reverse-DNS namespace owned by the Dimension, with product records under a stable software-product path segment and release records nested beneath their product. Never promote an ecosystem coordinate (purl, CPE name, SWID tag id, container image tag) to primary key: coordinates are assertions about a product by a scheme, they are reassignable, and several may be true at once. Never derive a key from a version string, release date, hostname or environment name.", "registry_links": [ "SPDX License List, for licence identifiers used inside licence expressions", "NVD CPE Dictionary, for CPE names asserted against this product", "CVE Program record store, for vulnerability identifiers referenced by exposure mappings", "purl type definitions maintained under the ECMA-427 framework, for validating coordinate syntax per ecosystem", "CSAF publisher metadata, for resolving advisory publishers and their tracking namespaces" ] }, "canon_and_patch": { "canonicalization_rules": [ "All time values are normalised to RFC 3339 date-time with mandatory seconds and an explicit offset or Z before comparison or storage; -00:00 is preserved where the local offset is genuinely unknown.", "Version strings are stored verbatim and never normalised; a separate derived ordering key is computed from the declared version scheme and recomputed if the scheme declaration changes.", "Package URLs are stored in their canonical form per the governed syntax, with qualifiers ordered deterministically; the raw as-received string is retained alongside when it differed.", "Hash digests are stored lowercase hexadecimal with an explicit algorithm label; a bare digest with no algorithm is rejected.", "Licence expressions are stored in the declared expression syntax with identifiers from the referenced licence list; free-text licence names are retained separately as evidence, not substituted into the expression." ], "patch_rules": [ "Published release facts, bill-of-materials documents, provenance attestations and shipped notice sets are immutable; corrections are recorded as new statements linked by a supersession reference with a reason code.", "Mutable state fields — release state, support status, exploitability status, effective configuration, running release — are patched only through an event that carries actor, authorisation reference, RFC 3339 event time and prior value.", "Exploitability statements and advisories are versioned by tracking version; a withdrawn not-affected claim is retained because it is material evidence of what consumers were told.", "Observations are append-only: a new deployment or configuration observation never edits an earlier one, even when it contradicts it." ], "compatibility_rules": [ "Adding an optional data element, an additional question or a new artifact form is backward compatible; removing or retyping a required element, or narrowing a cardinality, is breaking and requires a major model version.", "Controlled vocabularies extend by adding codes; existing codes are deprecated with an end date but never re-pointed to a different meaning.", "Each record pins the external specification version it was written against, so an upgrade of SPDX, CycloneDX or CSAF does not retroactively change the meaning of stored records.", "Projections (JSON, YAML, Markdown, Git, MongoDB, MCP resources) may reshape structure freely but must round-trip identity, timestamps with offsets, provenance and access scope without loss." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record that owns the artifact class — the producer's product or release key for producer-side artifacts, and the operator's inventory identifier for deployment-side artifacts — always stored together with the issuing system so its authority can be checked.", "Governed global identifier or IRI where a recognised scheme exists: an SPDX element IRI, a Package URL per ECMA-427, a CPE name from the NVD dictionary, a SWID tag identifier, a CVE or advisory tracking identifier, or a content digest for a binary artifact.", "UUID or ULID minted by the adopting Dimension when neither of the above exists, recorded explicitly as Dimension-assigned and never later presented as authoritative.", "A version string, release date, build date, hostname, environment name or file path is never an identifier; version strings and dates are attributes that may participate in a composite key only alongside a tier-one or tier-two identifier." ], "timestamp_rule": "All time values are recorded as RFC 3339 date-time strings with mandatory seconds and an explicit UTC offset or Z; where the instant is known in UTC but the local offset is not, -00:00 is used rather than Z. Event time and observation or ingestion time are stored as separate elements and are never conflated: release publication, advisory initial and current release, go-live, decommission, configuration change and update application are event times, while SBOM generation, deployment scanning, coordinate assertion and verification outcomes carry an observation time. Where only one of the two is known, the record must state which one it holds.", "serial_naming_rule": "Serial artifacts are named as the artifact identifier followed by a zero-padded monotonic sequence number scoped to the owning record — for example a release manifest per product, a bill-of-materials document per release, an exploitability statement per product-and-vulnerability pair. The sequence is an ordering key only, carries no date or calendar semantics, and is never reused after a withdrawal; withdrawn serials retain their number with a withdrawn state.", "integrity_rule": "Every binary or downloadable artifact carries at least one named hash (algorithm plus lowercase hexadecimal digest) and, where available, a signature and a build provenance attestation bound to that digest. Verification outcome, verifier identity and verification time are stored with the artifact; a failed or absent verification blocks promotion of the artifact and raises an exception record rather than being silently accepted. Evidence artifacts — verification results, provenance, quality reports — bind to the artifact digest, not to the version string, so evidence cannot migrate between different builds of the same version." }, "policies": [ "External standards are recorded as alignments only. Conformance to SPDX, CycloneDX, CSAF, an ISO standard or a regulatory regime is asserted only with a cited conformance artifact naming the exact version; otherwise the record reads aligned, not conformant.", "Producer-asserted and third-party-observed statements are stored with distinct provenance and are never merged. Where a declared licence and a concluded licence, or an intended and an observed running release, disagree, both are retained with their asserting party.", "Completeness is expressed positively: components that could not be determined are declared as known unknowns with a reason, and an absent entry is never read as an assertion of absence.", "Operational records are treated as observation, not intent. A recorded running version, effective configuration or exposure rating must carry an observation timestamp and collection method or it is not admissible as evidence.", "Personal data and secrets are out of scope for this model. Where an interface register or configuration snapshot would capture them, only the category and the custody location are recorded, never the values.", "Split stewardship: the producing organization owns product, release, SBOM-as-published and producer advisories; the operator owns deployed systems, environments, supplemental tags and inventory evidence.", "Known unknowns SHALL be explicit. Omitting a CISA 2026 field is not equivalent to recording that the field is unknown.", "Public product catalogue projections SHALL omit operator inventory, environment location and entitlement secrets. SBOM and advisory sharing follow TLP and contractual disclosure, with audit.", "Withdrawn, yanked and end-of-support releases SHALL be retained for exposure matching until the retention period expires; publication status must not erase identity.", "License legal text and organization master data SHALL be referenced, not copied, from sibling models.", "Patch records MUST NOT silently change software-version; upgrades that change version replace primary tags." ], "crud": { "read": [ "Producer-published findings — identity, classification, release lineage, version scheme, licensing, lifecycle statements and publicly disclosed bills of materials — are readable by any authenticated agent within the Dimension.", "Operator-held findings — deployment inventory, environment profiles, effective configuration, interface registers and exposure sets — are deny-by-default and readable only under an explicit grant from the operator owner package, with each read logged at instance scope.", "Bulk read of composition or deployment data is rate-limited and logged separately from single-record reads, because aggregate exposure data is more sensitive than any single record." ], "create": [ "A product record is created only with an authoritative master-system identifier, or with an explicitly flagged Dimension-assigned identifier and a recorded reason why no master system exists.", "A release record is created only with a verbatim version string, a publication event time in RFC 3339 with offset, and at least one integrity value for each distributable artifact.", "A bill-of-materials document is created only with a named format, a pinned specification version, an author reference distinct from the producer reference where they differ, a creation timestamp and a declared depth.", "A deployment record is created only with an operator reference, an environment reference, an observed release reference and an observation timestamp with collection method." ], "update": [ "Published release facts, bill-of-materials documents, notice sets, provenance attestations and issued declarations are immutable; a correction creates a new record linked by supersession with a reason code and an effective-from time.", "State fields transition only through recorded events carrying actor, authorisation, event time and prior value; a state change with no event is rejected.", "Exploitability statements and advisories are revised by incrementing the tracking version and retaining the prior revision in full.", "Recomputation of derived values, such as version ordering keys, is permitted and is logged with the declaration version that produced it." ], "delete": [ "Records are withdrawn, not erased: withdrawal sets a state, records the withdrawing party and time, and retains the prior statement for audit and for reconstructing what consumers were told.", "Hard deletion is permitted only for personal data or secrets that should never have entered the record, and requires a recorded legal basis, an approver and a tombstone showing that a deletion occurred without restating the deleted content.", "Statutory retention floors — notably technical documentation duties attached to placing a product on a market — override routine housekeeping deletion, and any scheduled purge must test against them before executing.", "Withdrawing a release from distribution does not delete its record; distribution availability and record existence are separate states, because exposure questions outlive availability." ] }, "roles": [ { "name": "Product Steward (producer side)", "responsibilities": [ "Owns the product identity record, namespace, canonical naming and classification assignments", "Approves supersession of identity and classification statements and maintains the stewardship assignment" ] }, { "name": "Release Engineer", "responsibilities": [ "Creates release records with publication event times, integrity values and distribution registrations", "Maintains the version scheme declaration and the dependency resolution records for each build", "Attaches bills of materials and build provenance attestations to the releases they describe" ] }, { "name": "Deployment Operator", "responsibilities": [ "Owns deployment inventory entries, environment profiles, configuration snapshots and interface registers", "Records observations with method and time and grants or refuses read access to operator-scoped findings", "Applies updates and records application evidence per instance" ] }, { "name": "Security Response Owner", "responsibilities": [ "Maps advisories to affected releases and instances and publishes exploitability statements with justifications", "Holds time-boxed cross-operator read access during an active advisory and submits authority reports where required", "Triggers re-assessment when new evidence arrives and retains superseded statements" ] }, { "name": "Licensing and Compliance Officer", "responsibilities": [ "Maintains licence declarations, determination basis, attribution notice sets and the restriction register", "Compiles technical documentation dossiers and enforces statutory retention floors against deletion schedules", "Approves disclosures of bills of materials and dossiers outside the Dimension and records the legal or contractual basis" ] }, { "name": "Model Custodian", "responsibilities": [ "Maintains the AGENTS.md bootstrap contract, projection mappings and pinned external specification versions", "Runs canonicalization, patch and compatibility rules and blocks breaking changes without a major model version" ] } ], "access": { "default_rule": "Producer-published layers are readable Dimension-wide by authenticated agents; operator-held layers covering deployment, environment, effective configuration, interfaces and exposure are deny-by-default and require an explicit grant from the operator owner package. Write access follows the stewardship assignment strictly: producer-side packages cannot write deployment records and operator-side packages cannot write release records.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "The Security Response Owner may read deployment and exposure records across operators for a named active advisory; the access is time-boxed to the advisory's response window, scoped to the affected release set, and logged per instance read.", "Bill-of-materials disclosure to a customer may be contractually restricted; the restriction is recorded as an access condition on the document, never by removing components from it or by publishing a shallower BOM without declaring the reduced depth.", "Regulator or market-surveillance access to technical documentation is granted only on a documented legal request, recorded with the requesting authority and the legal basis, and is never silent.", "Break-glass read of effective configuration during live incident response is permitted without prior grant, and requires post-hoc review by the operator owner package within a stated window; an unreviewed break-glass access escalates automatically.", "Embargoed advisory content is readable only by the pre-notification list until the advisory's initial release time, and every pre-notification read is recorded against the embargo.", "Emergency vulnerability-response break-glass may grant time-bounded read of operator inventory and non-public advisories, with mandatory audit and expiry", "Public open-source product catalogue pages may be world-readable while still withholding deployment and entitlement fields" ], "audit_requirements": [ "Every read of an operator-scoped finding or artifact records requester identity, stated purpose, scope and time as an RFC 3339 timestamp with seconds and an explicit offset.", "Every disclosure of a bill of materials, exploitability statement or technical documentation file outside the Dimension is logged with recipient, legal or contractual basis, and the exact document version disclosed.", "Break-glass access, cross-operator advisory access and embargo pre-notification reads are reviewed, and the review outcome is stored with the original access record rather than in a separate system.", "Every hard deletion records the approver, legal basis and a tombstone; audit logs are retained at least as long as the longest applicable statutory documentation retention period.", "Log create, update, delete, disclosure and exception grants at finding and artifact grain with actor, action, event time and observation time", "Retain access logs at least as long as the disclosed SBOM, advisory or inventory artifact", "Record TLP label and recipient scope on every advisory or SBOM export" ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Alignment and conformance status" ], "read_order": [ "Read AGENTS.md at the storage root first and resolve Name, Type, Model ID, Specification URL, Storage type URL, Interface URL and Processes URL before performing any read or write, including in MongoDB and MCP deployments where the file is stored as a document or exposed as a resource rather than as a file on disk.", "Follow the Specification URL to load the model scope, boundaries, and the bundle, layer, finding and question structure, and to learn which findings are producer-owned versus operator-owned.", "Follow the Storage type URL to learn the concrete projection in use and its canonical field mapping, including how timestamps, identity tiers and provenance are represented in that projection.", "Follow the Interface URL to learn the available operations, authentication, and the bundle, layer, finding and artifact access scopes before requesting any operator-scoped data.", "Follow the Processes URL to learn the CRUD, patch, disclosure, audit and retention procedures, and confirm the pinned external specification versions before mutating any record.", "Check Alignment and conformance status last, and treat any external standard listed there as an alignment unless a conformance artifact with an exact version is cited." ] } }, "coverage": { "claim": "Claude's seven-bundle structure is the base: identity and coordinates, release lineage, distribution and integrity, declared composition and build provenance, licensing and inherited obligations, deployment and effective configuration, support lifecycle and vulnerability response, and quality and regulatory conformity. It is extended with four grok findings (family/edition/channel/SKU line identity, SWID/CoSWID tag types and patch-versus-upgrade, composition completeness aggregates and coverage, advisory remediation with restart and entitlement gating) and six operational functions covering tag revision, patch application, withdrawal, advisory issuance, disclosure and deployment retirement. Component internals (WM-SFT-007), organization masters, licence instruments, identifier-scheme registries and CVE records stay outside by delegation. Accessibility conformance, cryptographic BOM, AI and SaaS extra elements, and product-line variability beyond edition/channel remain declared gaps. No universal or metaphysical completeness is claimed.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Master-system identifier first, governed global coordinates (purl per ECMA-427, CPE, SPDX IRI, content digest) second, Dimension-assigned ULID third; version strings and dates explicitly excluded as identifiers. Producer-side and operator-side identity are keyed by their own systems of record." }, { "dimension": "lifecycle", "status": "covered", "notes": "Release states and withdrawal events, support status and end-of-life milestones, update delivery, and post-support continuation are separated from the software life cycle processes standard, which is aligned rather than restated." }, { "dimension": "relationships", "status": "covered", "notes": "Product publishes release, release composed of components, dependency declares and resolves to a release, instance runs a release and is hosted in an environment, advisory affects release ranges. Component-side relationship detail is delegated to WM-SFT-007 by COMPOSE." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with mandatory seconds and explicit offset throughout, with -00:00 for unknown local offset; publication, go-live, decommission, configuration change and advisory release are event times, while SBOM generation, deployment scanning and verification carry observation times." }, { "dimension": "provenance", "status": "covered", "notes": "Build provenance attestations, SBOM author distinct from software producer, coordinate assertion parties, licence determination basis, and asserting party recorded on scores and exploitability statements." }, { "dimension": "ownership", "status": "covered", "notes": "Producer-side versus operator-side stewardship split enforced in the access default rule and in owner package requirements, with an explicit succession rule for acquisition, dissolution or abandonment." }, { "dimension": "validation", "status": "covered", "notes": "Artifact integrity verification with recorded outcome and verifier, BOM conformance validation against a pinned specification version, configuration drift against a baseline, and evidence bound to artifact digest rather than version string." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default for operator-held findings, four access scopes, and five named exceptions covering advisory response, contractual SBOM restriction, regulator requests, break-glass and embargo pre-notification." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Withdraw-not-erase default, narrow hard-deletion path for personal data and secrets with tombstones, statutory documentation retention floors overriding housekeeping purges, and distribution-point retention held separately from record retention." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignments to SPDX 3.0.1, CycloneDX 1.6/ECMA-424, ECMA-427, CSAF 2.0 and the CVE record format, each pinned per record, with format and specification version carried on every BOM document and no conformance claimed without a cited artifact." }, { "dimension": "classification", "status": "covered", "notes": "Component type, primary and additional purpose, delivery model and regulatory class, each with the governing vocabulary and version and the assigning party recorded." }, { "dimension": "composition", "status": "covered", "notes": "BOM document as a governed artifact with declared depth and known unknowns, plus dependency declaration and resolution kept distinct so drift is computable." }, { "dimension": "security and vulnerability", "status": "covered", "notes": "Advisory identity and tracking versions, affected ranges, severity scoring with asserting party, exploitability status with recognised justification and applicability conditions, and authority reporting triggers." }, { "dimension": "licensing and rights", "status": "covered", "notes": "Licence expression with declared-versus-concluded basis, attribution and reciprocal obligations, corresponding-source availability duration, and use, field-of-use and export restrictions with waivers." }, { "dimension": "quality and measurement", "status": "covered", "notes": "Quality characteristics selected from a governed quality model with measure, method, target and measured value, plus verification activities and knowingly accepted defects." }, { "dimension": "regulatory conformity", "status": "covered", "notes": "Applicable regimes per market, conformity route, declaration and marking bound to specific releases, and technical documentation retention. Grounded in EU legislation, so non-EU regimes are asserted only as placeholders." }, { "dimension": "spatial and jurisdiction", "status": "covered", "notes": "Hosting location and jurisdiction on the environment profile, jurisdiction-scoped restriction register and export classification. Geometry-level location is deliberately not modelled." }, { "dimension": "privacy", "status": "covered", "notes": "Data categories crossing interfaces are recorded with a regulated flag and applicable regime reference; a standing policy forbids capturing personal data values or secrets in this model, delegating them to a privacy or data-protection sibling." }, { "dimension": "accessibility conformance", "status": "gap", "notes": "No authoritative accessibility source was consulted, so accessibility conformance statements are not structured here. Treating accessibility as merely a quality subcharacteristic is probably insufficient for products subject to accessibility legislation; this is a known structural gap rather than a claim of non-applicability." }, { "dimension": "commercial terms and entitlement fulfilment", "status": "not-applicable", "notes": "Pricing, contracts and entitlement issuance belong to a contract and commercial model. Only the entitlement requirement needed to judge lawful use is retained here, as an access precondition." } ], "known_omissions": [ "Source-control history, branch and commit semantics: only a source revision reference appears, inside build provenance.", "Cryptographic bill of materials and detailed cryptographic asset inventory, which CycloneDX 1.6 supports and which will matter for post-quantum migration planning; it is referenced by component type only.", "Hardware bill of materials and firmware-to-device binding beyond the hosting platform descriptor.", "AI-specific documentation such as model cards, training data provenance and evaluation results, delegated by EXTEND rather than modelled, despite AI-enabled software being explicitly in the current SBOM guidance's frontier.", "Detailed incident and outage records for deployed systems; only configuration change events and update application evidence are held.", "Localisation, packaging variants and edition matrices, which are treated as separate products or releases without a dedicated variant structure.", "Cost, resource consumption and sustainability measures of deployed instances.", "Export-control classification schemes are referenced generically rather than modelled per jurisdiction, because no single authoritative cross-jurisdiction scheme was located.", "ISO/IEC 19770-2 XML schema annexes were not retrieved in full; CoSWID/RFC 9393 and NISTIR 8060 paraphrases carry the tag information model used here.", "CISA 2026 PDF body was retrieved as a file but not fully field-extracted; new-element names come from the official landing page and partner summaries and should be re-checked against the PDF tables before implementation.", "ISO/IEC 19770-3 entitlement schema, ISO/IEC 19770-1 SAM processes and ISO/IEC 19770-6 HWID are not modelled.", "EU Cyber Resilience Act and BSI TR-03183-2 SBOM requirements are regional obligations not ingested as primary text in this run.", "CISA Software Bill of Materials for AI — Minimum Elements (May 2026) and SaaS-specific extra elements are flagged as required extras, not expanded.", "SLSA, in-toto and SPDX Build profile details are only represented as formulation/provenance stubs.", "SPDX 3.1 RC (January 2026) hardware, safety and operations expansions are emerging and excluded from the canonical structure.", "Commercial SKU/price-list, export-control classification and dual-use coding have no primary support here.", "Product-line variability (feature flags, SPL) beyond edition/channel is a gap.", "Full CPE 2.3 naming specification (NISTIR 7695) was cited via CSAF informative references, not fetched as a standalone primary." ], "conflicts": [ "SPDX and CycloneDX draw the component boundary differently: SPDX distinguishes Package, File and Snippet within a Bom collection, while CycloneDX uses a single component object with a type enum plus separate services. A record faithful to one is not mechanically faithful to the other, so the model stores the source format and specification version per document rather than harmonising into one shape.", "purl and CPE identify overlapping but non-identical things: purl names a package in a distribution ecosystem, CPE names a product for vulnerability applicability. One CPE can span many purls and vice versa. The model records both with asserting parties and requires a per-use precedence decision instead of asserting equivalence.", "Semantic Versioning is widely adopted but not universal; calendar versioning, ecosystem-specific schemes and vendor schemes coexist. The model therefore requires a declared version scheme and refuses to assume semantic precedence rules when computing affected ranges.", "The 2021 NTIA minimum elements and the 2026 CISA-led minimum elements differ in required fields, with the newer guidance adding fields such as component hash and licence. Records must state which baseline they were produced against; treating an older SBOM as deficient against the newer baseline would be a category error.", "SLSA v1.1 is retired in favour of v1.2, and ISO/IEC/IEEE 12207:2017 was cancelled and replaced by the 2026 edition on 2026-04-29. Both alignments are therefore version-pinned; the v1.1 levels page was used as the accessible primary text and this is recorded rather than glossed.", "CycloneDX lifecycle phases (design, pre-build, build, post-build, operations, discovery, decommission) and the process stages of the software life cycle standard are different abstractions over similar ground; the model uses record states and events rather than adopting either phase vocabulary as canonical.", "Regulatory obligations and SBOM guidance disagree on whether an SBOM must be published or merely produced and made available on request. The model treats disclosure as an access condition, which satisfies both readings without asserting either as universal.", "SPDX and CycloneDX are competing SBOM formats both recognized by CISA 2026; neither is the meta-model.", "CPE vendor:product identity and PURL ecosystem identity often cannot be derived from each other; both may be absent.", "NTIA 2021 Supplier Name versus CISA 2026 Component Producer versus SPDX originatedBy/suppliedBy versus CycloneDX manufacturer/supplier are overlapping but not identical roles.", "RFC 9393 states SWID and CoSWID may diverge because they are maintained by different bodies.", "CoSWID forbids a patch from changing software-version; many package ecosystems treat patches as new versions.", "CSAF product includes hardware and specifications; this software model must not silently absorb those branches.", "SPDX 2.2.1 remains the ISO/IEC 5962:2021 text while operational SBOM practice has moved to SPDX 3.x and CycloneDX 1.7.", "A withdrawn package version in an ecosystem registry is not always the same event as CSAF document status withdrawn or CoSWID software removal." ], "regional_assumptions": [ "The regulatory conformity bundle is grounded in EU legislation (Regulation (EU) 2024/2847), with reporting obligations from 2026-09-11 and main application from 2027-12-11. Products not placed on the EU market will have different or no equivalents, and other regimes are not modelled.", "The SBOM minimum elements source is US-led guidance developed with international partners; it is authoritative for US federal contexts and influential elsewhere, but it is not binding law in most jurisdictions.", "The CPE dictionary and the CVE Program are US-operated registries. Regional vulnerability databases exist with different identifiers and different affected-range conventions, and a product may carry identifiers in several of them simultaneously.", "Export-control and sanctions classifications are jurisdiction-specific and change without notice; the restriction register is scoped per jurisdiction with effective windows for this reason.", "ISO and IEC standards are paywalled, so alignment claims to ISO/IEC/IEEE 12207:2026 and ISO/IEC 25010:2023 rest on catalogue-level scope statements rather than clause-level reading. This is an evidence limitation, not a conformance claim.", "CISA 2026 minimum elements and NIST SWID guidance are US-origin instruments adopted with international partners; they are not global law.", "CPE and NVD matching are US NIST operational practice; other jurisdictions may prefer PURL/OSV matching.", "CSAF has strong European implementation (BSI co-editorship) and TLP-based distribution that may differ from US federal sharing rules.", "EU CRA and BSI TR-03183 may impose stricter SBOM field and format constraints on products placed on the EU market than CISA 2026.", "UNSPSC classification on CoSWID is optional and not universally used outside procurement contexts." ], "adversarial_checks": [ "Checked whether any bundle, layer or finding rests only on the non-authoritative N4 predecessor material. The predecessor's product, architecture and operation split survives only where a primary source independently supports it; its contracts and projections sections were not carried over as structure because no primary source justified them as findings.", "Checked for duplication with WM-SFT-007. The composition layer deliberately holds only the BOM document, the declared constraint and the recorded resolution. Component identity, ecosystem metadata and internal files were rejected here even though they are attractive to include, because that would make the COMPOSE relation meaningless.", "Tested whether the model breaks when purl and CPE disagree about product boundaries. It does not: coordinates are stored as assertions with asserting parties and a per-use precedence decision, rather than as keys, so contradictory schemes coexist without corrupting identity.", "Tested the assumption that an SBOM is complete. Rejected: declared depth and known unknowns are required elements, and a standing policy forbids reading an absent entry as an assertion of absence.", "Tested identity survival through producer acquisition, rename or abandonment. The master key plus issuing system and the succession rule handle it; keying on producer name or namespace alone would have failed this test, which is why namespace is a separate element from the key.", "Tested the case of software with no distributable artifact at all, delivered only as a hosted service. Release and integrity findings degrade rather than break: the delivery model code records the degradation and the BOM type shifts, which is why delivery model is a required element rather than an optional annotation.", "Tested whether producer intent could silently overwrite operational reality. Prevented by keying deployment records to the operator's inventory system, requiring observation timestamps and collection methods, and forbidding producer-side packages from writing deployment records.", "Tested whether a withdrawn not-affected exploitability claim could disappear. Prevented by versioning statements and retaining superseded revisions, since what consumers were previously told is itself material evidence.", "Checked for a plausible but unsupported temptation to model a single global support-period minimum. Rejected: the support period is a producer declaration tested against a jurisdiction-specific regulatory minimum, because no universal minimum was found in any consulted source.", "Component/package file-level and ecosystem-registry internals were pushed to WM-SFT-007 rather than duplicated as local findings.", "License legal instruments and organization masters are references, not local objects, despite CISA Component License and CoSWID licensor roles.", "CVE/CWE catalogues are not mastered; only product affectation and VEX status are local.", "No conformance to SPDX, CycloneDX, CSAF, ISO 19770-2 or 12207 is claimed.", "Dates and version strings were rejected as identifiers; tag-id, spdxId, PURL and master-system ids are required.", "Producer catalogue versus operator inventory ownership was kept split so public projections cannot leak deployment location.", "SaaS and AI extras were marked as CISA-noted gaps rather than invented fields.", "Patch-versus-upgrade and corpus-versus-primary tag types were included as rare lifecycle cases with RFC 9393 primary support." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Claude's aggregate framing is accepted over grok's entity framing. Release records, bill-of-materials documents, advisories, deployed-instance records and configuration snapshots each have their own lifecycle, their own authoring party and their own retention duty, yet none is meaningful except anchored to one product identity. Grok's own structure carries the same independently-lifecycled children (publication event logs, CSAF documents, operator inventory records, endpoint evidence) while labelling the root an entity, which understates the ownership split it itself enforces between producer catalogue and operator inventory. Aggregate is therefore the honest boundary, and the producer-side / operator-side seam is the aggregate's internal ownership line rather than a second model." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude as base", "rationale": "Claude carries seven boundary notes each with a named neighbour, a stated distinction and source refs, plus explicit in-scope and out-of-scope lists that survive adversarial testing (purl/CPE disagreement, producer acquisition, hosted-service-only delivery). Grok's boundaries are competent but push licensing, quality and regulatory conformity wholly out of scope, leaving a narrower object than the stated purpose requires. Size was not decisive; boundary completeness was." }, { "concept": "Entry kind", "disposition": "aggregate, accepted", "rationale": "Releases, BOM documents, advisories and deployed-instance records have independent lifecycles and separate authoring parties, but are only interpretable anchored to one product identity. Grok's entity label contradicts the producer/operator ownership split grok itself enforces." }, { "concept": "Regulatory conformity (EU CRA and technical documentation)", "disposition": "Retained in scope from base", "rationale": "Grok explicitly excludes CRA conformity dossiers and notified-body certificates; Claude models the regime, conformity route, declaration binding to a specific release, and documentation retention with legislative backing. Excluding it would remove the only structure connecting a release to the duty that keeps it lawfully on a market. Retained with the base's own caveat that non-EU regimes are placeholders." }, { "concept": "Rights and licensing bundle", "disposition": "Retained in scope from base as obligations-and-references, not licence mastering", "rationale": "Grok delegates licensing entirely to an IP sibling. The base's narrower reading is correct and is kept: licence expression, declared-versus-concluded basis, attribution and reciprocal reach, corresponding-source duration, and use and export restrictions are product-level obligations, while licence instruments, texts and disputes stay in the sibling model." }, { "concept": "Quality characteristics and verification evidence", "disposition": "Retained in scope from base", "rationale": "Grok has no analogue. The base binds quality measures to a governed quality model and binds verification results to artifact digests rather than version strings, which is the only place in either provider where evidence is tied to the exact bytes tested. Kept, with the paywalled-standard evidence limitation carried as a hold." }, { "concept": "Family, edition, channel and SKU", "disposition": "Accepted into product-identity", "rationale": "Closes a gap the base explicitly declares as a known omission, with CoSWID software-meta and CSAF product-tree backing. Without it, editions of one code base must be modelled as unrelated products or collapsed into versions, and both are wrong." }, { "concept": "SWID/CoSWID tag types and patch-versus-upgrade", "disposition": "Accepted into release-lineage", "rationale": "Neither RFC 9393 nor NISTIR 8060 was consulted by the base, and no base finding distinguishes corpus, primary, patch and supplemental identification records or the patch-must-not-change-version rule. This is grok's strongest unique evidence axis and it lands cleanly on an existing base layer." }, { "concept": "Composition completeness aggregates and coverage", "disposition": "Accepted into declared-composition", "rationale": "The base has declared depth and known unknowns but no governed completeness vocabulary; CycloneDX compositions supply one that makes composition-evidence quality measurable rather than narrated. Accepted on the CycloneDX grounding alone; the CISA element-rename claim is held for field-level verification." }, { "concept": "Advisory remediation, restart and fix entitlement", "disposition": "Accepted into vulnerability-and-advisory", "rationale": "The base can say a product is affected but cannot say what fix exists, whether applying it requires a restart, or who is entitled to obtain it. CSAF remediations carry exactly these fields, and the fix-access gate is distinct from the product-acquisition entitlement already modelled under restrictions." }, { "concept": "SBOM authorship, type and generation context", "disposition": "Rejected as a finding; sbomType taxonomy deferred to element enrichment", "rationale": "Two of its three questions duplicate the base's bill-of-materials-document (author identity versus producer, document creation time versus release time). Only the sbomType axis (design, source, build, analyzed, deployed, runtime) is genuinely new, which is one element's worth of value and does not justify a parallel finding beside an existing one." }, { "concept": "Producer, creator, supplier and maintainer roles", "disposition": "Rejected as duplicative", "rationale": "The base's producer-and-stewardship already asks which role owns each slice, who may publish binding statements, whether record author differs from producer, and what happens on succession. Grok's CoSWID role vocabulary and reg-id naming authority are element-level refinements of that finding, not a separate decision surface." }, { "concept": "Contained components and declared dependencies", "disposition": "Rejected as duplicative and seam-threatening", "rationale": "The base's dependency-graph-and-resolution already holds declared constraint, scope, optionality, build-time resolution and pinning. Importing grok's component-grain containment finding would thicken the COMPOSE seam to WM-SFT-007 that both providers agree must stay thin." }, { "concept": "Product status and VEX assertions", "disposition": "Rejected as duplicative", "rationale": "Fully covered by the base's exploitability-assessment, which additionally models applicability conditions and retention of superseded assessments. Only grok's CSAF mandatory-test rule on contradicting product status is new, and that is a validation rule rather than structure." }, { "concept": "Publication, withdrawal and yank as a finding", "disposition": "Rejected as a finding; accepted as the withdraw-release function", "rationale": "The base's release-record already carries pre-release, generally available, superseded, withdrawn and yanked states plus the withdrawal event and its replacement. The gap was operational, not structural, so it is closed by adding the function rather than a duplicate finding." }, { "concept": "Hosting environment and discovery evidence", "disposition": "Rejected as duplicative; endpoint-digest matching deferred", "rationale": "Grok bundles genuinely new discovery-evidence content (payload versus on-device evidence, observed hash compared against the published digest set) with hosting-environment content that closely matches the base finding at high similarity. Importing the whole would duplicate; the new part is recorded as deferred element enrichment of deployed-instance-record." }, { "concept": "Service and hosted-offering treatment", "disposition": "Merged into base deployment and interface layers", "rationale": "Both providers treat services as within the product's runtime trust boundary rather than a separate model: the base records external services and data flows under runtime-configuration-and-interfaces and degrades release and integrity findings explicitly for SaaS-only delivery. No separate service layer is created; grok's service-boundary question is absorbed there." }, { "concept": "SBOM format harmonisation", "disposition": "Refused; per-document format and specification version retained", "rationale": "SPDX and CycloneDX draw the component boundary differently and both providers recognise this. The base's rule of storing source format and spec version per document is kept rather than harmonising into one shape, which also lets the CycloneDX 1.6 versus 1.7 pin be resolved later without restructuring." } ], "publicationHolds": [ "Source and live-version verification for every accepted source before publication: the providers disagree on SPDX 3.0.1 publisher attribution (Linux Foundation alone versus Linux Foundation with OMG), on the CycloneDX pin (1.6 with ECMA-424 June 2024 versus 1.7 with ECMA-424 December 2025), and on the ECMA-427 PURL edition; SLSA v1.1 is recorded as retired in favour of v1.2. Each URL must be re-fetched and each pin restated before any alignment claim is published.", "Field-level verification of the 2026 CISA minimum elements against the source PDF tables. The providers give divergent readings of the same document: the base speaks of declared depth and adds component hash and licence, while the source provider claims Depth is replaced by Coverage and Supplier Name by Component Producer, and itself admits the PDF body was not fully field-extracted. No element name from this document may be bound in the published draft until the tables are read directly.", "Multi-domain profile validation across at least five delivery profiles before the coverage claim stands: commercial on-premises application, open-source library in a package ecosystem, container image, firmware-as-software, and SaaS-only offering with no distributable artifact. The base states that release and integrity findings degrade for the SaaS case; that degradation must be exercised rather than asserted.", "Clause-level confirmation of ISO/IEC 19770-2:2015 and NISTIR 8060 for the accepted tag-type finding, since the source provider states the 19770-2 XML schema annexes were not retrieved in full and the tag information model was carried via RFC 9393 and paraphrase.", "Paywalled-standard limitation must be restated at publication: alignment to ISO/IEC/IEEE 12207:2026 and ISO/IEC 25010:2023 rests on catalogue-level scope statements, not clause-level reading, and no conformance to SPDX, CycloneDX, CSAF, ISO 19770-2 or 12207 is claimed." ], "deferredResearch": [ "SBOM type taxonomy (design, source, build, analyzed, deployed, runtime) plus tool name and version and generation context, to be absorbed as elements of the existing bill-of-materials-document finding rather than a parallel finding, once the CISA element names are verified against the PDF tables.", "Advisory TLP labelling, sharing constraints, CSAF document status lifecycle (draft, interim, final, withdrawn) and profile selection, as element enrichment of advisory-and-exposure-mapping and of the model's access policy rather than as a separate advisory-identity finding.", "Endpoint discovery evidence: CoSWID payload versus on-device evidence mutual exclusivity, and comparison of observed endpoint file or image hashes against the published release digest set, as element enrichment of deployed-instance-record.", "Accessibility conformance, which the base names as a live structural gap with no authoritative source consulted; treating it as a quality subcharacteristic is probably insufficient for products subject to accessibility legislation.", "Cryptographic bill of materials and cryptographic asset inventory for post-quantum migration planning, currently reachable only through a component-type reference.", "AI-specific and SaaS-specific extra transparency elements, including the separately published CISA AI SBOM minimum elements, which both providers flag as required extras but neither expands.", "CoSWID entity role vocabulary (aggregator, distributor, licensor, maintainer) with reg-id naming authority, as elements on producer-and-stewardship so role assertions can be correlated across documents.", "SPDX 3.1 release-candidate expansion into hardware, safety and operations, tracked as emerging and deliberately excluded from the canonical structure until it is formally published.", "Product-line variability beyond edition and channel (feature flags, software product lines) and per-jurisdiction export-control classification schemes, neither of which has primary support in either provider run." ] }, "statistics": { "sources": 22, "bundles": 7, "layers": 14, "findings": 30, "questions": 107, "artifacts": 30, "functions": 15 } }