Software Product

Product Identity Record

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.

1. Which identifier is the authoritative master-system identifier for this product, and which system issued it? identity
2. Within which namespace is the canonical product name unique, and which marketing or legacy names alias it? definition
3. Which organization is accountable as producer or supplier of record for this product? ownership
4. Where does this product stop, and which adjacent offerings are separate products rather than editions of this one? composition

Identifier Coordinates and Crosswalk

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.

1. What Package URL type, namespace, name and qualifiers identify the distributed form of this product? identity
2. Which CPE names are asserted to denote this product, and who asserted them? interoperability
3. Where two identifier schemes disagree about the product boundary, which scheme is authoritative for which use? decision
4. How is a claimed coordinate verified against the published artifact before it is trusted? validation

Family, edition, channel and SKU

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.

1. Which product family, edition and colloquial version line does this offering belong to, and which sibling editions share the same code base? composition
2. Which distribution or licensing channel (OEM, academic, retail, volume or other) applies to this offering? classification
3. Which CSAF product group, if any, collects this product with related products for common advisory or remediation status? relationship

Software Classification and Purpose

Controlled typing of the software (component type, primary and additional purpose, delivery model, regulatory class) that determines which downstream profiles and obligations apply.

1. Which component type from the governing BOM vocabulary applies to this product? classification
2. What primary purpose and additional purposes does the released artifact serve? definition
3. Is the product delivered as an installable artifact, an appliance image, or a hosted service, and does that change which BOM type applies? interoperability
4. Is the product classified as important or critical under an applicable product-security regime? requirement

Producer Accountability and Record Stewardship

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.

1. Which role owns each slice of this record: producer, supplier, distributor or operator? ownership
2. Who is authorised to publish a binding statement about this product, and under what delegation? authority
3. Is the author of a given record the same party as the software producer, and how is the difference recorded? provenance
4. What becomes of stewardship if the producing organization is acquired, dissolved or abandons the product? exception

Release Record

One published version of the product: its version string, publication event time and observation time, distribution channel, state and supersession links.

1. What exact version string identifies this release, and is that string immutable once published? identity
2. When was the release published, and is that time distinct from when this record observed it? temporal
3. What is the release's current state: pre-release, generally available, superseded, withdrawn or yanked? state
4. Which event withdrew or re-published this release, and what release replaced it? event

Version Scheme and Ordering

The declared versioning scheme and precedence rules that make version comparison, dependency ranges and affected-range statements decidable rather than guessed.

1. Which versioning scheme governs this product line, and is it declared by the producer or inferred by a consumer? classification
2. How is precedence determined between two versions, including pre-release identifiers and build metadata? constraint
3. What change classes force a major increment, and what compatibility promise attaches to minor and patch increments? requirement

Patch versus upgrade and tag types

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.

1. 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)? state
2. If this is a patch, which release does it patch, and does the patch illegally change the software-version? relationship
3. If this is a pre-install corpus record, which installation media or package installer does it describe? process

Distribution Channel and Availability

Authoritative download locations and registries for a release, the access conditions attached to them, and how long prior releases stay retrievable.

1. From which authoritative download locations or registries is this release distributed? provenance
2. What access conditions apply to obtaining this release: public, entitled, embargoed or jurisdictionally restricted? access
3. How long are prior releases retained at the distribution point, and what is the removal policy? retention

Artifact Integrity and Signature

Hashes, signatures and signing identities that let a consumer verify a fetched artifact, together with the verification outcome and any reproducibility claim.

1. Which hash algorithms and digest values are published for each distributable artifact of this release? evidence
2. Which signing identity signed the release, and how is that identity's authority established? security
3. What verification procedure must a consumer run before accepting the artifact, and what does a failure trigger? validation
4. Is the build reproducible, such that an independent rebuild yields a bit-identical digest? quality

Bill of Materials Document

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.

1. Who authored this bill of materials, and is that party the same as the software producer? provenance
2. What depth does this bill of materials claim: top level only, direct dependencies, or complete transitive closure? measurement
3. Which parts of the composition are declared known unknowns rather than silently omitted? quality
4. Which bill-of-materials format and specification version does the document conform to, and was that conformance verified? interoperability

Dependency Graph and Resolution

Declared dependency constraints with scope and optionality, the concrete releases that satisfied them at build time, and the pinning that makes the resolution reproducible.

1. What constraint range and scope does the release declare for each dependency? composition
2. Which concrete component release satisfied each constraint at build time, and which resolver produced that resolution? relationship
3. How is a later re-resolution distinguished from the resolution recorded at build time? temporal
4. Is the resolved dependency set pinned by a lockfile or digest so that the build can be reproduced? validation

Coverage, completeness and known unknowns

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.

1. What completeness aggregate applies to this composition, and is first-party or third-party content incomplete? measurement
2. Which component, dependency, license or identifier fields are explicitly unknown rather than omitted? evidence
3. What horizontal and vertical coverage does the producer claim relative to CISA 2026 Coverage, and what is out of that claim? constraint

Build Provenance Attestation

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.

1. Which build platform and builder identity produced this release? provenance
2. What top-level inputs, parameters and source revision entered the build? process
3. What build-integrity level does the provenance support, and who verified that claim? evidence
4. How is the provenance protected from forgery by the tenant whose build it describes? security

Secure Development Practice Assurance

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.

1. Which secure development framework practices does the producer claim, and over what organizational and product scope? requirement
2. What evidence substantiates each claimed practice, and who attested to it? evidence
3. Is each claim self-attested, customer-audited or assessed by an independent third party? authority

Licence Declaration and Expression

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.

1. What licence expression applies to this release as a whole, and in which expression syntax is it written? definition
2. Where do the declared and the concluded licences differ, and on what evidence was the conclusion drawn? evidence
3. Who holds copyright in the product and who is empowered to relicense it? ownership
4. Has the licence changed between releases, and does the change apply retroactively to prior releases? lifecycle

Third-Party Attribution Obligations

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.

1. Which attribution notices must ship with the product, and in what form must they be delivered? requirement
2. Which contained components impose reciprocal obligations, and how far do those obligations reach into the product? constraint
3. Where is corresponding source made available for components that require it, and for how long must it stay available? retention

Use and Export Restrictions

Restrictions on who may obtain, run or re-export the product, including entitlement requirements, field-of-use exclusions, jurisdictional controls and documented waivers.

1. What entitlement is required to obtain and run this release lawfully? access
2. Which fields of use or deployment contexts are excluded by licence, contract or regulation? constraint
3. Which export-control or sanctions classifications apply to this release, and who determined them? authority
4. Under what documented exception may a restriction be waived, and who approves the waiver? exception

Deployed Instance Record

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.

1. Which identifier denotes this deployed instance in the operator's authoritative inventory? identity
2. Which release is actually running on this instance, as observed rather than as intended? state
3. Over which time window did this instance run this release, with event time and observation time recorded separately? temporal
4. What business criticality and exposure does this instance carry? measurement

Hosting Environment and Platform

The environment class, platform stack, jurisdictional location and network exposure of the host on which instances run.

1. Which environment class does this host: development, test, staging, production or disaster recovery? classification
2. What platform, operating system and runtime constitute the hosting stack for this instance? composition
3. In which jurisdiction and region does hosting occur, and does that location constrain what may be processed there? spatial
4. Is this instance reachable from the public internet, and through which controlled boundary? security

Effective Configuration State

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.

1. Which security-relevant configuration values are actually in effect on this instance, and when were they last observed? state
2. How does the effective configuration differ from the release default or the hardened baseline? validation
3. Which change event last altered this configuration, and who authorised it? event

External Interfaces and Data Flows

Services, endpoints and data flows a deployed instance exposes or consumes, including third-party services that are dependencies but never shipped as components.

1. Which external services does this instance call, and are they recorded as services rather than as shipped components? composition
2. What categories of data cross each interface, and is any of it personal or otherwise regulated? privacy
3. How is each interface authenticated and authorised, and where are its credentials held? access

Support Status and End of Life

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.

1. What support status applies to this release line today, and who set it? state
2. What are the announced end-of-support and end-of-life dates, and when were they announced? temporal
3. Does the declared support period satisfy the applicable regulatory minimum for the expected product lifetime? requirement
4. What happens to deployed instances that remain in service after end of support, and who accepts the residual risk? exception

Update and Patch Delivery

How fixes reach deployed instances: channels, mechanism, default automation, separability of security fixes from feature change, and evidence that an update was actually applied.

1. By what mechanism are security updates delivered, and are they applied automatically by default? process
2. Are security fixes separable from feature changes so that an operator can apply one without the other? requirement
3. What record proves that a given instance received and applied a given update? evidence

Advisory and Exposure Mapping

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.

1. Which advisory and vulnerability identifiers apply, who published them, and at which tracking version? provenance
2. Which version ranges of this product are declared affected, fixed, or under investigation? relationship
3. What severity or exploitability scores are asserted, by which scoring system and which scoring party? measurement
4. When must an actively exploited vulnerability in this product be reported, and to which authority? requirement

Exploitability Assessment

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.

1. What is this product's status for the vulnerability: affected, not affected, fixed, or under investigation? state
2. If the product is not affected, which recognised justification applies and what evidence supports it? evidence
3. Does the assessment hold for all deployments, or only under stated configuration or environment conditions? constraint
4. What triggers re-assessment, and how is a superseded assessment retained? lifecycle

Remediation, entitlements and restart

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.

1. What remediation category and URL are offered for the affected products, and on which date was that remediation published? process
2. Does applying the remediation require a restart, and of what kind? constraint
3. Which entitlements gate access to the fix, and what activation status applies to the installed product? access

Quality Characteristics and Measures

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.

1. Which quality model and which of its characteristics are used to specify this product's quality requirements? classification
2. What measure, measurement method and target value are defined for each selected characteristic? measurement
3. What values were actually measured, on which release, and under which stated conditions? quality

Verification and Test Evidence

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.

1. Which verification activities were performed against this release, and by whom? process
2. How is each verification result bound to the exact artifact digest it was run against? validation
3. Which known defects were accepted as open at release, and who accepted the residual risk? decision

Conformity Assessment and Technical Documentation

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.

1. Which product-regulation regimes apply to this product in each target market, and from which date? requirement
2. Which conformity assessment route was used, and who performed the assessment? authority
3. What technical documentation must exist, and for how long must it be retained after the product is placed on the market? retention
4. What declaration of conformity or marking is issued, and against exactly which release does it hold? evidence