Prior and Adjacent Work

Purpose

Document prior and adjacent work relevant to the exploratory feasibility study of finite conformance auditing for security-relevant identity semantics in software vulnerability matching.

Track what existing standards, guidance, research, and tools already provide and identifies which parts of the proposed workflow remain distinct, redundant, unsupported, or still uncertain.

For each source, we ask:

What problem does the work address?
What semantic or identity model does it use?
What does it make explicit?
What does it automate?
How close is it to the proposed work?
What does it already provide that must not be claimed as novel?
What, if anything, appears not to be provided?
What does the source imply for the feasibility or novelty boundary?

The current novelty boundary is provisional and must be revised as additional prior work is identified.

Key Terms

translation: the proposed mapping from external semantics into the audit model

translation admissibility: whether that mapping is sufficiently grounded and semantics-preserving to permit conformance evaluation

admissibility verdict: ADMISSIBLE UNDERDETERMINED UNSUPPORTED INVALID

Foundational Operational-Identity Work

Operational Identity

Case, D. M. Operational Identity: A Finite Audit of Declared and Implemented Rules of Sameness. 2026.

Operational Identity models a declared rule of sameness and the identity-relevant behavior induced by an implementation as partitions of the same finite record domain.

It compares those partitions using refinement and provides finite divergence witnesses when an implementation introduces distinctions that the declaration does not make.

This study evaluates whether that finite audit can be translated faithfully into the software vulnerability-matching domain.

The mathematical machinery itself is therefore prior work for this study, not an empirical contribution of the present project.

Remains to be established:

The present study must determine whether externally defined software-security identity and applicability rules can be translated faithfully into the Operational Identity framework and whether the resulting analysis contributes information beyond a conventional source-grounded conformance audit.

Entity Resolution and Record Linkage

Fellegi-Sunter and subsequent entity-resolution work

Sources:

Fellegi and Sunter, A Theory for Record Linkage, 1969.
Elmagarmid, Ipeirotis, and Verykios, Duplicate Record Detection: A Survey, 2007.
Getoor and Machanavajjhala, Entity Resolution: Theory, Practice, and Open Challenges, 2012.
Christen, Data Matching, 2012.
Papadakis et al., Blocking and Filtering Techniques for Entity Resolution: A Survey, 2020.

Entity resolution determines whether multiple records correspond to the same real-world entity.

The field includes similarity measures, probabilistic matching, classification, candidate blocking, filtering, and scalable matching procedures.

Blocking and matching mechanisms can themselves divide a record domain according to which records are considered plausible matches.

This is close to the present work because both concern operational decisions about sameness and difference between representations.

A matching or blocking rule can induce distinctions between records that are structurally similar to the distinctions represented by an operational identity partition.

Important distinction:

Entity resolution evaluates a matching procedure against ground-truth co-reference and reports aggregate pair-level accuracy (precision/recall). The proposed audit compares two stipulated relations: a normatively declared rule the implementation is expected to follow, and the relation induced by implementation behavior. Neither side is ground truth, and it reports a refinement relationship and a finite divergence witness rather than an accuracy score.

The immediate question is not "which records really represent the same entity?" but "does the implementation apply the identity or applicability rule that governs this operation?"

Provenance and Data Lineage

W3C PROV-DM

Moreau and Missier, eds. PROV-DM: The PROV Data Model. W3C Recommendation, 2013.

PROV-DM provides a general vocabulary for entities, activities, agents, derivations, generations, uses, associations, and attribution.

Software supply-chain systems commonly preserve derivation, generation, dependency, and transformation information.

That information can establish how one artifact arose from another.

Important distinction:

Derivation does not by itself establish identity preservation.

Knowing that artifact B was derived from artifact A does not determine whether A and B must be treated as the same package, component, product, artifact, or vulnerability-applicability target.

Implication:

Provenance representation is prior work.

The present study is concerned with the semantic rule governing identity across or within those recorded transformations.

Software Identification

CISA Software Identification Ecosystem

CISA, Software Identification Ecosystem Option Analysis.

CISA identifies software identification as a prerequisite for correlating software inventories, vulnerabilities, mitigations, policies, and other cybersecurity information.

A central problem is that multiple identification schemes can refer to the same software differently.

Key evidence:

CISA emphasizes that correlation requires different cybersecurity participants to know that they are referring to the same software.

This is directly aligned with the empirical motivation for the present study.

Vulnerability matching depends on correctly determining when different representations refer to the same relevant software object.

Scope:

The guidance addresses identifier ecosystems, correlation, availability, harmonization, and adoption.

It does not appear to define a general executable procedure that:

extracts a normative identity or applicability commitment;
records its semantic direction and identity dimension;
validates a proposed translation of that commitment;
rejects semantically invalid translations; and
only then audits implementation conformance.

Implication:

The need for harmonized software identity is established prior work.

The project must not claim to discover the software-identification problem.

The possible contribution is a method for making particular identity commitments explicit and testing implementations against them.

SBOM Representation and Interoperability

CISA Framing Software Component Transparency

CISA, Framing Software Component Transparency, Third Edition, 2024.

CISA defines baseline SBOM attributes and maps those attributes to major SBOM representations, including SPDX and CycloneDX.

The mappings provide an authoritative starting point for identifying conceptually corresponding information across SBOM formats.

They are particularly relevant to prospective SPDX/CycloneDX transformation and round-trip cases.

Establishes:

Cross-format field mapping is prior work.

This project must not claim novelty merely for relating SPDX and CycloneDX fields.

Open Question (for this study):

A field mapping does not automatically establish whether two resulting component descriptions preserve the same operational identity for a specific security decision.

The study must determine whether that additional semantic question can be expressed and audited independently.

SPDX and CycloneDX Conversion

CycloneDX SPDX Interoperability Library

CycloneDX .NET library, CycloneDX.Spdx.Interop.

The library converts between CycloneDX and SPDX representations.

Its documentation explicitly identifies information that may be lost during conversion, including differences involving relationships, component identity, PURLs, CPEs, dependency graphs, composition, and external references.

Key evidence:

The project explicitly warns that conversion between SPDX and CycloneDX may lose information.

This is important prior art for the proposed cross-format and round-trip feasibility cases.

Information loss during conversion is already known and must not be presented as the contribution of this study.

Open Question (for this study):

The relevant question is narrower:

When information changes or is lost, does the transformation alter an identity relation that a security operation is required to preserve?

That requires an externally grounded identity commitment rather than a generic expectation of losslessness.

SPDX cdx2spdx

SPDX cdx2spdx.

cdx2spdx is a utility for converting CycloneDX SBOM documents into SPDX representations.

It is concrete evidence that cross-format conversion is an existing engineering task rather than a novel contribution.

It may also provide candidate fixtures for later transformation experiments.

Implication:

Format conversion itself is not the contribution.

The possible contribution concerns semantic conformance of identity-sensitive behavior across such transformations.

Semantic Normalization and Diff

sbom-tools

sbom-tool/sbom-tools.

The tool normalizes CycloneDX and SPDX documents into a canonical internal representation and performs semantic diffing, component matching, dependency comparison, vulnerability analysis, validation, and other checks.

Its matching machinery includes PURL matching, aliases, ecosystem-specific normalization, and fuzzy similarity.

Close prior work:

This is one of the strongest adjacent systems identified so far.

It already demonstrates that:

SPDX and CycloneDX can be normalized into a common representation;
components can be matched semantically rather than textually;
cross-format differences can be automated;
matching decisions can be explained;
conformance and policy checks can be incorporated into CI.

The project must not claim novelty for:

canonical SBOM normalization;
semantic SBOM diffing;
component matching;
PURL-based matching;
alias matching;
cross-format comparison;
CI automation of SBOM comparison.

Candidate distinction:

The proposed work begins from an externally grounded semantic commitment and asks whether the mapping from that commitment into the executable conformance relation is itself valid.

The distinction to test is therefore:

semantic diff

versus:

source-grounded semantic commitment -> admissibility-checked translation -> conformance relation -> implementation result

Whether that distinction produces useful analytical value remains an empirical question.

Package URL Identity

Package URL Specification

Package URL specification.

PURL provides a structured package identifier containing fields such as type, namespace, name, version, qualifiers, and subpath.

Qualifiers may identify additional package characteristics such as architecture or repository information.

PURL structure is directly relevant to the Grype repository_url case and to future identifier-strength and qualifier-transformation cases.

Important distinction:

PURL syntax identifies available representational dimensions.

PURL syntax alone does not determine every downstream application's semantic rule for deciding whether two PURLs should match.

Those rules must be grounded in the consuming specification or implementation contract being audited.

VEX Product Identification and Applicability

OpenVEX Specification

OpenVEX Specification.

OpenVEX expresses vulnerability status with respect to software products and components.

Products may be addressed through software identifiers, including Package URLs.

The specification recommends supplying sufficient software identifiers to help VEX processors match products.

VEX makes software-product identity operationally consequential.

A VEX statement is useful only when a consumer can determine which observed software products the statement applies to.

Important distinction:

The semantic problem is not merely whether two strings are equal.

The consumer must determine whether a VEX product description applies to a software representation produced by an SBOM or scanner.

OpenVEX PURL qualifier matching discussion

OpenVEX issue #27, PURL matching with qualifiers.

The discussion explicitly identifies ambiguity caused when one PURL contains qualifiers and another does not.

It considers alternative matching strategies, including:

ignoring qualifiers;
requiring all qualifiers to match; and
comparing common qualifiers while tolerating additional ones.

This is particularly important evidence because it shows that qualifier matching is a recognized semantic problem in the VEX ecosystem itself.

Two independently correct producers can emit PURLs at different levels of specificity, creating an applicability decision for the consumer.

Implication:

The qualifier-matching problem itself is not novel.

The study's possible contribution is the explicit representation, validation, and conformance auditing of the chosen governing rule.

VEX and Vulnerability-Matching Semantics

OpenVEX / go-vex matching behavior

OpenVEX specification and go-vex implementation.

The implementation provides concrete rules for determining whether software identifiers match for VEX processing.

These rules are part of the source semantics that must be established before constructing an Operational Identity audit.

The Grype feasibility case revealed that matching semantics may be directional rather than symmetric.

That distinction determines whether a proposed partition-based translation is admissible.

Methodological implication:

Observed scanner behavior must not be used to infer the normative matching relation against which that behavior will subsequently be tested.

The relation must be independently grounded in the relevant specification, library contract, or documented ecosystem convention.

SBOM Empirical Research

Nocera et al.: SBOM Adoption

Nocera et al., Software Bill of Materials Adoption: A Mining Study from GitHub. ICSME 2023.

Nocera et al., On the Adoption of Software Bill of Materials in Open-Source Software Projects. Journal of Systems and Software, 230, 2025, 112540.

These studies examine SBOM adoption in open-source projects, including adoption extent, generation practices, standards use, completeness, and compliance characteristics.

Relevance:

They establish SBOM artifacts, tooling practices, standards compliance, and repository mining as established empirical-software-engineering subjects.

Important distinction:

The present study is not primarily an SBOM-adoption or schema-conformance study.

Its empirical object is identity-sensitive behavior induced by software-security tooling under controlled transformations.

Wang et al.: Adherence Gap Between SBOM Standards and Tools

Wang et al., A Large Scale Empirical Analysis on the Adherence Gap between Standards and Tools in SBOM, 2026.

This study evaluates the gap between SBOM standards and the behavior of SBOM generation tools using an automated framework.

The evaluation covers tens of thousands of SBOMs (55,444 SBOMs from six tools across 3,287 repositories) generated by multiple tools from thousands of real-world repositories and examines compliance, cross-tool consistency, longitudinal consistency, and information accuracy.

Close prior work:

This work is particularly close to the present study because it treats disagreement between standards and tool behavior as an empirical conformance problem rather than merely comparing tools with one another.

The project must not claim that measuring gaps between SBOM standards and implementations is novel.

Candidate distinction:

The adherence-gap study evaluates standards compliance and tool consistency at scale.

The proposed study asks whether a particular externally grounded identity or applicability commitment can first be represented admissibly and then audited as a finite operational relation, with a specific witness and structural classification when appropriate.

Whether that narrower identity-specific analysis contributes useful evidence beyond standards-adherence testing remains an open question.

Wild SBOMs Dataset

Soeiro, Robert, and Zacchiroli, Wild SBOMs: a Large-scale Dataset of Software Bills of Materials from Public Code, 2025.

The dataset contains more than 78,000 unique SBOM files discovered across more than 94 million public repositories, together with metadata about format, provenance, revisions, and quality.

Relevance:

This work demonstrates that a substantial public corpus of naturally occurring SBOMs is available and may inform corpus design or external validity.

It is also relevant to the study's corpus-adequacy risk.

The dataset does not by itself provide the controlled transformations or independently grounded identity commitments required by the proposed audit.

SPDX and CycloneDX Tool Ecosystems

Bangash et al., The State of the SBOM Tool Ecosystems: A Comparative Analysis of SPDX and CycloneDX, 2025.

The study analyzes 170 publicly advertised SBOM tools, tens of thousands of issue reports, and project-level ecosystem measures for SPDX and CycloneDX.

Relevance:

It provides empirical context for the maturity, diversity, and practical differences of the two principal SBOM tool ecosystems.

It also establishes that cross-format tooling and interoperability limitations are already recognized ecosystem concerns.

Implication:

Differences between SPDX and CycloneDX tooling, ecosystem maturity, or interoperability are background conditions rather than contributions of the present study.

Schema and Profile Validation

Existing SBOM tooling validates documents against schemas, minimum-element requirements, compliance profiles, and other structural rules.

These checks answer questions such as:

Is the required field present?
Is the value structurally valid?
Does the document satisfy the selected SBOM profile?
Does the document satisfy a compliance rule?

Those checks are important prior art.

The proposed translation-validation stage asks a different question:

Does the executable relation faithfully represent the semantic commitment that the auditor claims to be testing?

For example:

source rule = directional

combined with:

audit relation = symmetric

would produce:

TRANSLATION: INVALID

even if both input artifacts are individually schema-valid.

Whether this distinction is already formalized elsewhere remains an active prior-art question.

Metamorphic Testing

Metamorphic testing addresses the test-oracle problem by specifying relations that should hold across related inputs and outputs rather than requiring an independently known expected output for every execution.

For example, a transformation may be applied to an input and the tester may require a corresponding relation to hold between the original and transformed outputs.

This is directly relevant to proposed study families such as:

SPDX -> CycloneDX representation changes;
SPDX -> CycloneDX -> SPDX round trips;
multiple SBOM generators applied to the same artifact;
PURL qualifier transformations; and
intentionally lossy representation changes.

A round-trip expectation such as:

representation A -> representation B -> representation A'

with a requirement that some property of A and A' be preserved is naturally expressible as a metamorphic relation.

Important distinction:

Metamorphic testing establishes that a relation is expected to hold across executions.

The present study adds a separate source-grounding question:

What external standard, specification, contract, or documented convention justifies that metamorphic relation for the identity dimension being tested?

A plausible transformation relation must not be treated as a governing identity commitment merely because it is useful for testing.

Implication:

Metamorphic testing and round-trip testing are established prior work.

The project must not claim novelty for generating transformed inputs, testing round trips, or checking preservation relations across related executions.

The candidate contribution is the source-grounded admissibility and identity-conformance analysis applied to such transformations.

Differential Testing

Differential testing compares multiple implementations or executions and identifies cases in which their outputs disagree.

That approach is highly relevant to vulnerability scanners because two scanners, two versions, or two equivalent representations may produce different findings.

Relation to this study:

A differential test can establish: These executions disagree.

It does not by itself establish: Which behavior violates the governing semantic commitment?

The proposed conformance audit therefore requires a rule grounded independently of the observed disagreement.

Implication:

Scanner disagreement and differential testing are not contributions of this study.

The contribution under evaluation is identity conformance.

A future revision of this page should add the strongest software-security differential-testing literature identified during the formal literature search.

Declarative Semantic Translation and Conformance

This is currently the least settled prior-work category and therefore requires targeted searching.

The candidate workflow is:

external normative source
        |
        v
declared semantic commitment
        |
        v
declarative translation
        |
        v
translation admissibility check
        |
        +--> ADMISSIBLE
        +--> UNDERDETERMINED
        +--> UNSUPPORTED
        +--> INVALID
        |
        v
ADMISSIBLE only
        |
        v
executable conformance relation
        |
        v
implementation observation
        |
        v
PASS / FAIL + witness

The prior-art search must determine whether an existing framework already provides this combination.

Particular attention should be given to:

model transformation validation;
schema-mapping verification;
ontology alignment;
executable standards conformance;
refinement checking;
declarative policy languages;
metamorphic testing;
model-based testing;
semantic interoperability testing;
compiler translation validation.

The existence of analogous methods in another domain would not necessarily eliminate the contribution, but it may change how the method should be positioned.

Normative-Systems and Commitment Conformance

Sources:

Conformance Verification of Normative Specifications using C-O Diagrams.
Verifying conformance of multi-agent commitment-based protocols (Bentahar et al.).

These lines of work give formal semantics to normative specifications (obligations, permissions, prohibitions; commitments and their actions) and separate two checks: whether the specification or contract is itself realizable/consistent, and whether an implementation satisfies it.

Close prior work:

This is the closest conceptual antecedent to the two-stage structure proposed here. The realizability/consistency check plays the structural role of translation admissibility; the implementation-satisfaction check plays the role of conformance. The commitment-protocol literature also explicitly warns that informal translation-based approaches reduce commitments to abstract structures and fail to preserve their real semantics - the concern that motivates the translation-admissibility gate.

The project must not claim that separating specification/translation admissibility from implementation conformance is itself novel.

Candidate distinction:

The antecedent work targets deontic and temporal behavior of agents and protocols. The proposed work targets identity and applicability relations over a finite record domain, using partition refinement and finite witnesses, grounded in software-security artifacts (PURL, OpenVEX/go-vex, SBOM formats). Whether that identity-specific, partition-based instantiation adds value beyond a generic admissibility-then-conformance framing remains the open question.

Compiler Translation Validation

Necula: Translation Validation for an Optimizing Compiler

George C. Necula, Translation Validation for an Optimizing Compiler, PLDI 2000, pp. 83-94.

Translation validation checks a particular transformation performed by a compiler to determine whether the transformed program preserves the semantics of the original program.

Close prior work:

This is relevant because both approaches make the correctness of a translation itself an explicit verification concern rather than assuming that a transformation preserves meaning.

Important distinction:

Compiler translation validation compares program representations before and after a compiler transformation and checks preservation of program semantics.

The present study instead asks whether a researcher's mapping from an external software-security commitment into an executable identity or applicability relation is justified by the source semantics.

Terminology implication:

Because "translation validation" is an established compiler-verification term, this project uses translation admissibility for its own model-construction gate.

The project must not claim that checking whether a translation preserves semantics is itself novel.

Emerging Novelty Boundary

The current candidate distinction is the combination of:

an externally grounded identity or applicability commitment;
explicit recording of the identity dimension under examination;
explicit direction and semantic roles when the commitment is directional;
a declarative translation into an executable audit relation;
validation of the translation independently of implementation behavior;
distinct translation outcomes:
ADMISSIBLE
UNDERDETERMINED
UNSUPPORTED
INVALID
conformance evaluation only for ADMISSIBLE translations;
a finite implementation-conformance result:
PASS
FAIL + witness
structural classification of the failure when the translated relation supports meaningful partition analysis.

None of these elements should be claimed individually as novel without further prior-art review.

The research question is whether their combination yields a useful, reproducible conformance method for software-security identity semantics that is not already supplied by existing mapping, normalization, semantic-diff, schema-validation, VEX-processing, or software-identification systems.

Current Closest Prior and Adjacent Work

Current closest work falls into five groups.

Software identity and applicability

CISA software-identification guidance: establishes the cybersecurity need for reliable correlation of software identities across datasets.
Package URL: provides structured package identifiers and qualifier semantics.
OpenVEX and go-vex: provide product identification, vulnerability-applicability semantics, and concrete matching behavior.

SBOM representation and transformation

CISA SBOM attribute mappings: establish mappings between SBOM concepts and SPDX/CycloneDX representations.
CycloneDX SPDX interoperability tooling: performs concrete conversion and documents representational loss.
SPDX conversion tooling: performs CycloneDX/SPDX transformation.
Metamorphic testing: supplies the established testing paradigm for transformation and round-trip relations.

Semantic comparison and implementation conformance

sbom-tools: provides canonical normalization, semantic matching, cross-format diffing, validation, and CI-oriented analysis.
Wang et al.: empirically measure standards/tool adherence gaps, inter-tool consistency, longitudinal consistency, and information accuracy.
Entity-resolution literature: provides mature theory for comparing induced and reference co-reference classifications.

Formal conformance antecedents

Normative-specification conformance: separates specification realizability/consistency from implementation satisfaction.
Commitment-protocol verification: formalizes protocol semantics and warns about semantic loss in informal translations.
Compiler translation validation: establishes semantics-preservation checking for individual transformations.

Empirical ecosystem and corpus work

Nocera et al.: establish SBOM adoption and compliance as empirical-software- engineering subjects.
Wild SBOMs: provides a large public corpus of naturally occurring SBOM artifacts.
SPDX/CycloneDX ecosystem studies: characterize the tool landscape and interoperability environment.
W3C PROV: provides standardized derivation and provenance without itself determining identity preservation.

The remaining prior-art question is therefore narrower than whether mapping, transformation, conformance, semantic comparison, or translation checking already exist. They do.

The open question is whether an identity-specific combination of:

source-grounded commitment -> translation admissibility -> executable operational relation -> finite conformance audit -> structural classification + witness

provides useful evidence not already supplied by those established approaches.

Working Claim

Current:

We are evaluating whether an explicit, source-grounded translation-admissibility gate, followed by finite identity-conformance analysis, provides useful evidence beyond existing software-identification, normalization, interoperability, standards-adherence, semantic-diff, metamorphic-testing, and formal-conformance techniques.

Process

If we find a groundable multi-block case and SE adds real structural information: strongest outcome; proceed toward conformance and structural-surplus RR.

If we find groundable cases but SE adds little beyond conventional semantic diff: still useful; methods paper centered on admissibility/conformance, with a bounded role for partitions.

If many promising cases repeatedly become UNDERDETERMINED or UNSUPPORTED: potential jurisdiction/boundary contribution, but only if the pattern is broad enough to support a general conclusion.

If we cannot find enough groundable cases for a meaningful corpus: then little empirical contribution and unlikely MSR fit.

Next checkpoint:

Can we identify one externally specified, genuinely multi-class identity commitment in the SBOM/VEX/vulnerability-matching ecosystem?

If yes, the project is promising.

We need:

An authoritative external source defines the identity or applicability rule
That rule induces more than two equivalence classes on some finite set of records.
The relation is genuinely about sameness/co-reference for a security-relevant purpose, not just field correspondence.
At least one real implementation can be observed to preserve, split, merge, or cross those classes.

We must target standards that define canonical identifiers or explicit uniqueness. PURL is not merely a field mapping. Its specification says it provides a standardized syntax that uniquely identifies software packages, and it is used in CycloneDX, SPDX, vulnerability databases, package repositories, and CVE records.