Published

Software Component / Package

vr.wm-sft-007 · wm-sft-007-software-component-package

Provide the format-neutral context an agent needs to identify, classify, verify, compose, govern and operate a versioned, distributable software component or package release used as a dependency.

World Models Information and virtual systems INF.SFT.PKG

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

6 bundles · 13 layers · 29 findings · 117 questions

Identity, Naming and Version Designation How a component is uniquely named, how its release is designated and how its bytes are addressed and verified.

Package Coordinates and Identifier Alignment

Ecosystem coordinates, cross-scheme identifiers and content-address integrity for the component and its artifacts.

Ecosystem coordinate identity

The purl type, optional namespace and name that address the component in its ecosystem of record, plus the normalization rules that must run before any comparison.

Which purl type, namespace and name uniquely address this component in its ecosystem of record? identity
What distinguishes the project-level identity of this component from the identity of one specific release? definition
Which normalization rules must be applied to the coordinate before two identities are treated as equal? constraint
Which registry or namespace authority allocates this name, and may the name be reassigned after removal? authority

Cross-scheme identifier alignment

Additional identifier schemes asserted for the component (CPE, SWID, content identifiers such as SWHID or OmniBOR) and the confidence and directionality of each mapping.

Which additional identifier schemes are asserted for this component, and by which asserting party? interoperability
What evidence supports each cross-scheme mapping, and is it one-to-one, many-to-one or unverified? validation
How is a conflicting or over-broad identifier match handled when it produces false vulnerability hits? exception
Which identifier scheme is authoritative for which downstream use case? classification

Content address and integrity verification

Cryptographic digests over the exact released byte streams, the algorithms accepted, and the mandatory verification step before consumption.

Which cryptographic digests, computed over which exact byte streams, address the released artifacts? identity
What verification procedure is required before these bytes are consumed from an untrusted source? validation
Which digest algorithms are accepted for this ecosystem and which are deprecated or forbidden? security
How does an immutable artifact digest relate to the mutable registry tag or channel that pointed to it? relationship

Version Designation and Release Composition

The version scheme that orders releases and the set of distribution artifacts that constitute one release.

Version scheme, precedence and immutability

Which versioning scheme governs the version string, how two versions are ordered, and whether published content for a version is immutable.

Which versioning scheme governs this component's version strings, and was that scheme declared or inferred? classification
How are two versions of this component ordered, and how are pre-release and build metadata treated in that ordering? constraint
Is the published content for a given version immutable, and what mechanism enforces that? requirement
How is this version string represented when exchanged with a tool that assumes a different version scheme? interoperability

Release variant and distribution set

The distinct distribution artifacts that constitute one release (source distribution, binaries, platform and architecture variants) and how a consumer selects among them.

Which distinct distribution artifacts make up this release, and are any of them optional? composition
What is the primary purpose and packaging form of each artifact in the release? classification
Which artifact must be selected for a given target platform, and which metadata drives that selection? decision
Does each variant carry its own identifier and digest, or do all variants share the release identity? identity

Component type and software purpose

CycloneDX requires a component type such as application, library, framework, container, operating-system, firmware, file or machine-learning-model. SPDX records primaryPurpose and additionalPurpose, noting that purpose is intrinsic to how the element is used rather than solely to its content. The two vocabularies overlap but are not identical.

What CycloneDX component type classifies this package? classification
What SPDX primaryPurpose and additionalPurpose values describe how this package is used? classification
Is the recorded purpose based on use context rather than bit content, and could the same bits be a library in one product and an application in another? definition

Composition, Dependencies and Derivation What the component declares it needs, what a resolver actually selected, what the artifact contains, and what it was derived from.

Declared and Resolved Dependencies

Dependency constraints declared by the component and the concrete closure a resolver produced from them.

Declared dependency constraints

The dependency edges the component itself declares, with version constraint expressions, scope and linkage kind.

Which dependencies does this component declare, and under which version constraint expression for each? relationship
What is the scope of each declared dependency, and does it reach the distributed artifact at all? classification
Which declared dependencies are conditional on platform, feature flag or optional extra? constraint
Is the dependency linked statically, dynamically or used only as a tool, and does that change obligations? composition

Resolved dependency closure

The concrete transitive set a resolver selected at a stated instant, together with the completeness of that closure.

Which resolver, resolver version and registry state produced this closure? process
At which instant was the closure resolved, and can it be reproduced from the recorded inputs? temporal
What is the complete transitive component set, and which members are direct rather than transitive? composition
How complete is the recorded closure, and which parts are explicitly declared unknown? quality

Contained Content and Derivation

What the released artifact actually contains, including undeclared bundled code, and what upstream work it was derived from.

Contained files, snippets and bundled subcomponents

Files and subpaths inside the released artifact, and third-party code bundled or vendored without a manifest declaration.

Which files or subpaths does the released artifact contain, and which of them are third-party code? composition
What evidence identifies bundled code that is not declared in the dependency manifest? evidence
Which contained subpath is referenced when only part of the component is used? constraint
How do contained subcomponents inherit or override the parent component's licence and provenance? relationship

Pedigree, patches and derivation

Ancestry of the component: what it was derived from, what modifications were applied, and how confident that chain is.

From which ancestor component, upstream release or revision was this component derived? provenance
Which patches, commits or variant changes were applied to the ancestor to produce this component? composition
Is this component a fork, a rebuild, a repackaging or an unmodified redistribution? classification
What confidence attaches to the pedigree chain, and what evidence supports it? validation

Origin, Build Provenance and Trust Who produced and supplied the component, from which source, through which build, and what makes that claim verifiable.

Origin, Roles and Source Linkage

Which agents played which supply role, and which source revision corresponds to the release.

Supplier, author and distributor roles

The distinct agents who originated, supplied and distributed the release, and which of those is accountable for security response.

Which agent originated, which supplied and which distributed this component release? ownership
Which role holder is authoritative for security contact and vulnerability response for this component? authority
How was each role assertion obtained, and is it self-declared or independently verified? provenance
How does a repackager, mirror or internal rebuild change the supply chain seen by a downstream consumer? relationship

Source revision and repository linkage

The repository and exact revision corresponding to the release, and what if anything verifies that link beyond a self-declared URL.

Which source repository and exact revision correspond to this released artifact? provenance
What links the distributed artifact to that revision beyond a self-declared repository URL? validation
What is recorded when no source is available or the source link cannot be verified? exception
Which qualifier or external reference carries the source location in each exchange representation? interoperability

Build Provenance and Trust Verification

The attestation describing how the artifact was built and the signature material that makes it checkable.

Build provenance attestation

The provenance predicate binding the artifact digest to a build platform, build type, parameters and time window, and the assurance level claimed from it.

Which build platform, build type and external parameters produced this artifact? process
When did the build start and finish, and how do those instants relate to publication? temporal
Which resolved dependencies and byproducts were recorded for the build, and how complete are they? evidence
Which provenance assurance level is claimed, and what concrete evidence supports the claim? measurement
Is the attestation subject digest identical to the digest of the artifact actually distributed? validation

Signature, envelope and admission decision

Signature and attestation envelopes covering the artifact, the verification policy that gates admission, and how exceptions are authorised.

Which signatures or attestation envelopes cover this artifact, and which identity signed each? security
Which verification policy must pass before the component is admitted, and what happens on failure? validation
When was each signature made, when does the trust material expire, and how is verification-at-time recorded? temporal
On what basis may an unsigned or unverifiable component be accepted, and who authorises that? exception

Licensing, Rights and Regulatory Obligations The licence position of the component, the obligations that follow from redistributing it, and the regulatory duties that attach to shipping it.

Licence Determination and Obligations

Declared versus concluded licensing and the concrete obligations that follow.

Declared and concluded licensing

The licence expression the supplier declares, the expression a reviewer concludes, and how ambiguity and choice under disjunction are recorded.

What licence expression is declared by the supplier for this component release? definition
What licence has been concluded after review, and which agent made that determination? decision
Which operator semantics apply, and which option has been selected under a disjunctive expression? constraint
How are unlicensed, ambiguous or unasserted licence cases represented and escalated? exception

Attribution, notice and redistribution obligations

The concrete obligations triggered by redistributing the component and the evidence that they were met.

Which attribution, notice and source-offer obligations attach to redistributing this component? requirement
Which copyright statements and notice texts must be reproduced, and where were they taken from? composition
How do obligations differ between static linking, dynamic linking and unmodified redistribution? constraint
What record proves the obligations were satisfied for a specific distribution? evidence

Regulatory and Disclosure Duties

Support-period, due-diligence, disclosure and incident-reporting duties triggered by shipping the component in a regulated market.

Support period and third-party due diligence

The support period determined for products containing the component and the due-diligence step required before integrating a third-party or open-source component.

What support period has the responsible manufacturer determined for products containing this component? requirement
Which regulator, market and legal instrument imposes obligations on this component's use? authority
How and when is the end of the support period communicated to the purchaser? temporal
Which due-diligence step was performed before integrating this third-party or open-source component? process

Component disclosure and incident reporting duties

What component data must be disclosed to customers or authorities, to whom, in what form, and on what deadlines once a vulnerability is actively exploited.

Which component data fields must be disclosed, to whom, and in which machine-readable form? requirement
Which reporting deadlines apply once a vulnerability in this component is actively exploited? temporal
Who is entitled to receive the component disclosure, and under what confidentiality terms? access
What is disclosed when component contents are commercially sensitive or genuinely unknown? exception

Lifecycle State, Exposure and Health The published state of a release over time, its vulnerability exposure, and the signals used to decide whether to adopt or retire it.

Release State and Support Window

Published state transitions of a release and the maintenance window and replacement path around it.

Release state and transitions

The current published state of the release, the transitions permitted, and how a resolver must behave in each state.

What is the current published state of this release in its registry of record? state
Which state transitions are permitted, who may perform them, and which are irreversible? lifecycle
Which event caused the most recent state change, and what reason string was recorded? event
How must a resolver behave when a required version is yanked or deprecated? constraint

Maintenance window, end of life and replacement

Built, released and valid-until instants, maintenance signals, accountable maintainer and the recommended successor release.

What are the built, released and valid-until instants recorded for this release? temporal
Which release is the recommended replacement, and what migration cost has been recorded? decision
Which signals indicate this component is no longer actively maintained? measurement
Who is accountable for maintenance now, and has stewardship been transferred? ownership

Vulnerability Exposure and Remediation

Whether a specific version is affected by published advisories and what was decided about it.

Vulnerability affectedness of a version

The computed verdict on whether this exact version falls inside an advisory's affected ranges, and the evidence behind it.

Which advisories declare this exact version affected, through which range type and events? relationship
How is affectedness computed for a version not explicitly enumerated in the advisory? validation
When was each advisory published, last modified or withdrawn, and when was this assessment made? temporal
What severity is asserted for each advisory, by which scoring system and which source? measurement

Exploitability, remediation and exception

Whether an advisory is exploitable in the component's actual usage, what remediation was chosen, and under what time-bounded exception an affected version may remain.

What is the exploitability status of this advisory in the component's actual usage context? state
Which remediation was chosen, and who approved it? decision
What is the fixed version and the concrete upgrade path from the currently adopted version? process
Under what documented exception may an affected version remain in use, and until when? exception

Health Signals and Identification Evidence

Measured project health used for adoption decisions and the evidence supporting the claim that this component is present at all.

Maintenance and security-practice health signals

Measured checks over the component's project used as adoption signals, with the tool, revision and measurement time that make them comparable.

Which health and security-practice checks were run against this component's project, and what results were produced? measurement
Which signals materially change the adoption decision, and what threshold applies? quality
When were the signals measured, and how quickly do they become stale? temporal
Which tool and tool version produced each signal, and against which repository revision? provenance

Evidence and confidence of component identification

What evidence supports the claim that this component is present in a given artifact, with what confidence, produced by which technique and context.

What evidence supports the claim that this component is present in the analysed artifact? evidence
What confidence is attached to the identification, and how was that confidence computed? quality
How are two conflicting identifications of the same artifact reconciled? validation
Which tool, technique and generation context produced the identification? provenance

Distribution, Availability and Record Governance Where the component is obtained, how long it stays obtainable, and how assertions about it are governed and exchanged.

Distribution Channel and Availability

Registry of record, retrieval endpoints, and the deletion and retention behaviour that governs continued availability.

Registry of record and retrieval location

Where the component is retrievable, which registry's metadata prevails, and what prevents namespace substitution between internal and public sources.

From which registry, repository URL and mirrors is this component retrievable, and which is the registry of record? spatial
Which registry's metadata prevails when a public and an internal registry disagree about the same coordinate? authority
What controls prevent substitution between an internal namespace and a public one with the same name? security
Which credentials or entitlements are required to retrieve this component? access

Availability, removal and retention

How long the artifact remains retrievable upstream, under what conditions the publisher may remove it, and what internal copy guarantees continuity.

How long will this artifact remain retrievable from the registry of record, and under which published policy? retention
Under which conditions may the publisher remove this release, and may the name and version then be reused? constraint
Which internal copy or archive guarantees continued availability once upstream removal occurs? process
What happens to builds already pinned to a version that has been removed upstream? exception

Assertion Provenance and Format Projection

How facts about the component are attributed and timed, and how the record projects into exchange formats without silent loss.

Assertion provenance and record currency

Who asserted each fact about the component, from which source, at which event time and which observation time, and how conflicts are resolved.

Who asserted each recorded fact about this component, and from which source document? provenance
How are event time, observation time and ingestion time recorded and distinguished for the same fact? temporal
How stale is each recorded fact, and what refresh obligation applies? quality
How is a conflicting assertion from two sources resolved and recorded? validation

Format projection and interoperability

Which exchange formats the component record must project into, which fields are lossy in each direction, and which representation is authoritative on disagreement.

Which exchange formats must this component record project into, and at which versions? interoperability
Which fields are mandatory in a target format but optional here, and how are the gaps filled? constraint
How is a round-trip projection validated, and what is the acceptance criterion? validation
Which representation is authoritative when two exported forms of this component disagree? classification

Containment and SBOM reference

A package typically contains files and may contain sub-packages. SPDX contains, expandsTo, hasDistributionArtifact and packagedBy describe those edges. CycloneDX metadata.component and compositions describe the root and relationship completeness. The SBOM document is WM-SFT-012; this package references it rather than embedding document identity as its own identity.

Which files, sub-packages or expanded artifacts does this package contain or distribute? composition
Which SBOM documents (WM-SFT-012) describe this package as a component or root? relationship
What relationship completeness is asserted for this package's composition: complete, incomplete, unknown or a CycloneDX composition aggregate? quality
Is this package the SPDX rootElement or CycloneDX metadata.component of an inventory, or only a nested component? interoperability
What pedigree of ancestors, descendants, variants or commits is recorded for this component? provenance

Classifiers Filled

Family: World Models
Category: Information and virtual systems
Entry kind: entity
Navigation path: NAV.INF.SFT.PKG
Domain: INF.SFT.PKG
Industry: Cross-industry
Tags: softwarecomponentpackageinf.sft.pkg

What it is Filled

This model covers the identifiable software component or package as a distributable unit: its project-level and release-level identity, version designation, contained and depended-upon composition, origin and build provenance, licensing and regulatory obligations, lifecycle state, vulnerability exposure, distribution channel and the provenance of every assertion made about it. It deliberately stops at the boundary of the consuming product, the SBOM document, the advisory record and the running deployment, each of which is a sibling or parent model. Storage and interface (JSON, YAML, Markdown, Git, MCP, MongoDB) are projections of this model, never its semantics.

In scope

Project-level identity (ecosystem type, namespace, name) and release-level identity (version, distribution variants, content digests).
Cross-scheme identifier alignment: purl, CPE, SWID, content identifiers, OCI descriptors and registry-native keys.
Declared dependency constraints, resolved dependency closures, contained files, bundled subcomponents and pedigree or derivation.
Origin and supply-chain provenance: supplier, author, manufacturer and distributor roles, source revision linkage, build attestation and signature verification.
Declared and concluded licensing, attribution and notice obligations attaching to redistribution.
Release lifecycle state (pre-release, published, deprecated, yanked, withdrawn, removed), support window and replacement path.
Vulnerability affectedness of a specific version, exploitability status, remediation decisions and time-bounded exceptions.
Distribution channel, registry of record, retrieval location, availability, unpublish and retention behaviour.
Assertion-level provenance: who asserted a fact, from which source, with what evidence and confidence, at which event and observation time.

Out of scope

The composed software product or service that consumes the component, and its architecture (WM-SFT-001).
The SBOM document itself, its structure, exchange, signing and distribution (WM-SFT-012); only the reference edge and coverage claims remain here.
Vulnerability and advisory records as first-class entities (CVE, GHSA, OSV entries); only the affectedness edge for a version is in scope.
Source repository, branch and commit management, code review and contribution process.
Build platform, pipeline and runner configuration as entities; only the emitted provenance predicate and its subject digest are referenced.
Deployed or running instances, hosts, containers at runtime and operational telemetry.
Legal-entity master data for suppliers, maintainers and stewards; only the role edge is in scope.
Licence texts, licence drafting and legal interpretation; only the expression and derived obligations are in scope.
Cryptographic key material, trust roots, key issuance and rotation procedures.
Hardware bills of material and non-software components.

Why it exists Filled

Provide the format-neutral context an agent needs to identify, classify, verify, compose, govern and operate a versioned, distributable software component or package release used as a dependency.

Distinguishing features Filled

Identifies a distributable unit by ecosystem coordinates and version, not a product or a running service.
Differs from an SBOM, which is a declaration about a component made by someone at a time.
Differs from an installed software asset, which records presence on a specific machine.
Keeps the provenance of each assertion about the component, such as licence or vulnerability claims.

What robots and AI may and may not do Filled

Must not

Install, publish or upgrade a package in production without approval.
Treat a package name match as identity across ecosystems.
Declare a licence position as legal advice or conclude compliance without review.
Ignore failed integrity or provenance checks.
Report a component as free of vulnerabilities because no advisory was found.

Only with a human decision

Accepting a component with an unresolved licence conflict.
Approving use of a component with a known exploitable vulnerability.
Adopting an unmaintained or abandoned component in a critical system.

May

Normalize and compare package coordinates such as Package URLs.
Verify artifact digests and build provenance against published attestations.
Resolve the dependency closure and report unknowns.
Evaluate exposure to published vulnerability advisories.

Moral aspects Filled

Components built by volunteer maintainers are reused widely; attribution and licence terms are owed to them.
A compromised package can harm many downstream users at once.
Vulnerability exposure data, if published carelessly, can help attackers.

Who is affected

Maintainers and authors of the component
Organizations that build on the component
End users of software that contains it

Owners Filled

Steward

The adopting Dimension MUST name exactly one owner package that holds the component register and is accountable for coordinate normalization, duplicate detection and merge decisions.

Roles

Component Register Owner: Own coordinate normalization, duplicate detection, alias and merge decisions for the register.; Designate the registry of record per purl type and maintain namespace reservations.; Approve no-digest and no-source exceptions and record their rationale and expiry.
Supply-Chain Verification Engineer: Maintain and version the admission policy for digest, signature and provenance verification.; Operate verification runs and record outcomes, policy version and verification instant.; Investigate digest mismatches, quarantine affected artifacts and raise incidents.
Open Source Licence Reviewer: Record concluded licence expressions with rationale, evidence and approver, and select disjuncts where a choice exists.; Derive redistribution obligations per linkage kind and maintain the notices assembly.; Escalate unlicensed, ambiguous or unasserted cases and hold redistribution until resolved.
Vulnerability Response Coordinator: Maintain the advisory source set with snapshot times and run affectedness evaluations.; Record exploitability analysis, remediation decisions and time-bounded exceptions with approvers and expiry.; Track regulatory reporting deadlines from the triggering event and evidence that notifications were made.
Registry and Distribution Operator: Operate retrieval endpoints, mirrors and internal archives and guarantee continuity after upstream removal.; Enforce namespace precedence in resolver configuration and alert on colliding public coordinates.; Apply retention and purge schedules for artifact bytes distinctly from metadata retention.
Compliance and Regulatory Officer: Maintain the market-specific obligation register and the support-period declarations that reference components.; Approve disclosure packages, redactions and their legal bases, and record recipient entitlements and expiry.; Review conformance and alignment claims and reject any not backed by a stored validation result.

Links to other meta-models Filled

composes

WM-SFT-001 Software Product / Service - A software product or service is composed of component or package releases; the product model owns architecture, market framing and operation, this model owns the reusable versioned unit. SPDX models both as Package instances, so the distinction is carried by this edge rather than by class.
Assertion provenance mixin (asserting agent, source, event and observation time) - Supplies the uniform attribution and time-separation fields applied to every claim in this model so that provenance is not re-implemented per finding.

references

WM-SFT-012 Software Bill of Materials - A package release references the SBOM documents that assert its contents. SPDX defines Sbom as a distinct class, so document structure, completeness and exchange stay in the sibling model while this model keeps the reference and the coverage claim.
Vulnerability / advisory record (OSV, CVE, GHSA) - Affectedness verdicts reference advisory records that carry their own identifiers, aliases, ranges, severities and modification times. This model stores only the resolved verdict for a concrete version plus its evidence.
Organisation / Agent (supplier, author, distributor, steward) - Supplier, originator, distributor and steward roles reference agent identities owned elsewhere; the model records the role edge and its assertion basis, never duplicate legal-entity master data.
Source code repository revision - Links a release to the exact revision claimed to have produced it, keeping repository, branch and review process in the source model.
Build or pipeline run - References the build run whose provenance predicate binds a builder identity and build definition to the artifact's subject digest; the run itself is a separate event entity.
Regulatory obligation register (EU Regulation 2024/2847 and equivalents) - References the register of market-specific duties, so support-period, due-diligence and reporting obligations attach to the component without embedding jurisdiction-specific rules in this model.

aligned

Package URL (purl) identifier scheme, ECMA-427 - Canonical component identity aligns to the purl syntax and normalization rules as a governed global identifier scheme; alignment is asserted as a mapping, not as conformance.
SPDX License List and licence expression grammar - Licence expressions are canonicalized to the SPDX expression grammar with its identifiers, operators and precedence so that determinations are comparable across suppliers.
CPE 2.3 product-class naming - Aligns package identity to product-class names used for platform enumeration and vulnerability matching, recording the mapping as lossy and directional rather than equivalent.
SWID tag / software asset inventory (ISO/IEC 19770-2) - Aligns package identity to installed-software identification for asset management, keeping endpoint installation state outside this model.
Secure development process framework (NIST SP 800-218) - Aligns the model's verification, archiving and reuse functions to a recognised secure development practice set, recorded as an alignment rather than a conformance claim.

extends

Container image / OCI artifact - Extends package identity with content-descriptor addressing for container and OCI-distributed artifacts, where the digest rather than the mutable tag is the identity.

neighbor

WM-SFT-001 Software Product / Service - A product or service is the marketed and operated whole; a package is a versioned distributable unit reusable across many products. SPDX models both as Package instances distinguished only by purpose vocabularies, so the distinction must be carried by the composition edge, not by the class.
WM-SFT-012 Software Bill of Materials - An SBOM is a document asserting a component set at a point in time; SPDX models it as a distinct Sbom class. The component exists independently of any SBOM, so SBOM structure, completeness and exchange belong to the sibling model.
Vulnerability / advisory record (OSV, CVE, GHSA) - The OSV entry is the authority-published record with its own identifier, aliases, ranges and modification time. This model stores only the resolved verdict for a concrete version plus the evidence of that resolution.
Build or pipeline run - SLSA provenance describes the build run, its builder identity and parameters. The package holds the subject digest and the attestation reference; the run itself is a separate event entity.
Source code revision (VCS commit) - purl types such as github and golang can address version-control locations, but a revision is not a distributable release with its own distribution artifacts and lifecycle state; the two must not be conflated.
Product-class identifier (CPE) - CPE names classes of IT products for platform enumeration and vulnerability matching; it does not address a specific downloadable artifact. purl does. Mapping between them is lossy and must be recorded as an alignment.
Installed software asset (SWID tag) - SWID tags describe software installed on an endpoint, including patch and supplemental tags for asset management. Endpoint installation state is asset data, not package identity.
Container image / OCI artifact - An OCI image is addressed by a content descriptor digest and may also carry a purl of type oci. It extends package identity with layered content addressing rather than replacing it.

parent

WM-SFT-001

What else AI and robots need to interact with it Filled

Sources Filled

SPDX Specification 3.0.1 — Software Profile, Package class - SPDX Project / The Linux Foundation
SPDX Specification 3.0.1 — Annex E, Package URL specification - SPDX Project / The Linux Foundation
Package-URL (purl) — Introduction and ECMA-427 standardization - Ecma International / package-url project
Semantic Versioning 2.0.0 - Semantic Versioning (semver.org)
CycloneDX v1.6 JSON Reference — component object - OWASP Foundation / Ecma TC54
SLSA v1.2 — Build Provenance specification - Open Source Security Foundation (OpenSSF) / SLSA
in-toto Attestation Framework — Statement layer v1 - in-toto project / Cloud Native Computing Foundation
Open Source Vulnerability (OSV) Schema - Open Source Security Foundation (OpenSSF)
SPDX Specification 3.0.1 — Annex D, SPDX license expressions - SPDX Project / The Linux Foundation
Cyber Resilience Act — summary of legal provisions - European Commission, Directorate-General for Communications Networks, Content and Technology
NIST IR 7695 — Common Platform Enumeration: Naming Specification Version 2.3 - National Institute of Standards and Technology (NIST)
NIST IR 8060 — Guidelines for the Creation of Interoperable Software Identification (SWID) Tags - National Institute of Standards and Technology (NIST)
OCI Image Format Specification — Content Descriptors - Open Container Initiative
PEP 592 — Adding "Yank" Support to the Simple API - Python Software Foundation / Python Packaging Authority
npm Unpublish Policy - npm, Inc. / GitHub
OpenSSF Scorecard — Checks documentation - Open Source Security Foundation (OpenSSF)
NIST SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1 - National Institute of Standards and Technology (NIST)
SPDX Specification 3.0.1 — Software Profile overview - SPDX Project / The Linux Foundation
Cyber Resilience Act — policy page - European Commission, Directorate-General for Communications Networks, Content and Technology
ExternalIdentifierType - SPDX Specification 3.0.1 - Linux Foundation SPDX Project
RelationshipType - SPDX Specification 3.0.1 - Linux Foundation SPDX Project
Hash - SPDX Specification 3.0.1 - Linux Foundation SPDX Project
SoftwarePurpose - SPDX Specification 3.0.1 - Linux Foundation SPDX Project
Standard ECMA-427 Package-URL (PURL) specification, 1st Edition - Ecma International Technical Committee 54
Common Platform Enumeration: Naming Specification Version 2.3 (NISTIR 7695) - National Institute of Standards and Technology
Guidelines for the Creation of Interoperable Software Identification (SWID) Tags (NISTIR 8060) and ISO/IEC 19770-2 - National Institute of Standards and Technology
SWHID: International Standard for Software Artifact Identification (ISO/IEC 18670:2025) - ISO/IEC JTC 1 / SWHID Working Group
Semantic Versioning 2.0.0 - Semantic Versioning (semver.org)
POM Reference – Maven - Apache Software Foundation
2026 Minimum Elements for a Software Bill of Materials (SBOM) - Cybersecurity and Infrastructure Security Agency
Framing Software Component Transparency (2024) - Cybersecurity and Infrastructure Security Agency
SoftwareArtifact - SPDX Specification 3.0.1 - Linux Foundation SPDX Project

Open questions

Reconcile the SPDX dependency vocabulary evidence: the base recorded 404s for SoftwareDependencyRelationship and SoftwareDependencyLinkType while grok retrieved SPDX Core RelationshipType (dependsOn, hasOptionalDependency, hasProvidedDependency, hasPrerequisite, hasStaticLink, hasDynamicLink). Confirm the live paths and attach the SPDX vocabulary to the declared-dependency finding, which currently cites CycloneDX only.
Build per-ecosystem resolution and version-grammar profiles: PEP 440, Debian epochs, Maven SNAPSHOT and classifiers, Go minimal version selection, Cargo features, NuGet, RubyGems, conda and OCI index behaviour, each of which changes ordering and closure semantics.
Obtain first-party registry lifecycle policies beyond npm and PEP 592 — crates.io yank, PyPI yank, Maven Central immutability and Go module proxy retention — to ground the release-state and retention findings per registry of record.
Track the VERS version-range syntax standardisation effort and decide whether range expressions become a modelled construct or remain delegated to advisory range types.
Research export control, sanctions screening and country-of-origin restrictions on component distribution; neither provider obtained a primary source and both list it as an omission.
Specify the same-content relation for one archive published under multiple purls (mirrors, forks, republished coordinates) so dual publication yields two coordinates linked by digest rather than a merged identity.
Determine how personal data in maintainer and author fields is to be handled by registries and SBOM exchange formats, closing the privacy gap recorded in the base checklist.
Ecosystem-specific dependency semantics are not enumerated: Cargo features, Maven dependency management and BOM imports, Go minimal version selection, Debian and RPM epochs and Python extras all change resolution behaviour and would need per-type profiles.
Cryptographic key management, trust roots, transparency log operation and key rotation are referenced but not modelled; they belong to a sibling trust-infrastructure model.
Machine-learning model and dataset packaging (model cards, data governance, training provenance) is only referenced through the component type vocabulary and is not developed.
Export control, sanctions screening and country-of-origin restrictions are not modelled; no primary source was obtained during this research and inventing structure would be unsupported.
The SBOM document lifecycle, its own signing, versioning and distribution are deliberately deferred to WM-SFT-012 and are not duplicated here.
Cost, contractual and procurement attributes of commercial components are out of scope and would need a separate commercial-terms model.
Binary similarity and provenance recovery techniques for artifacts with no manifest are acknowledged in the evidence finding but not specified as a method.
The CISA 2026 Minimum Elements PDF body was not retrieved; field-level 2026 deltas versus NTIA 2021 are therefore not cited as primary text.
VERS version-range syntax is planned as an Ecma standard in 2026 and is not treated as normative here.
Ecosystem-specific version grammars beyond SemVer and Maven (PEP 440, Debian Policy epochs, RubyGems, NuGet, Go modules, OCI index, conda, Hex, Yocto) are not fully expanded.
Registry unpublish windows (npm, crates.io yank, PyPI yank) lack first-party policy citations in this pass.
EU Cyber Resilience Act component identification duties, NIST SSDF, and sector SBOM profiles are not incorporated.
Sigstore/Rekor, in-toto and SLSA provenance attestations are omitted as a sibling process model.
OSGi bundle symbolic-name+version, Java module names, and language-level package names distinct from distribution packages are omitted.
Private coordinate collisions across disconnected registries (same GAV, different bits) need operational federation rules not specified by the cited standards.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-007-software-component-package/spec.yaml, ver-cy/world-models/card-supplements/wm-sft-007-software-component-package.json