SE Operational Identity Semantics in Software Vulnerability Matching

An exploratory feasibility study of finite conformance auditing for security-relevant identity semantics in software vulnerability matching.

Background

• Paper: SE-210 Operational Identity
• Repo: Executable verification of finite mathematical core of SE-210
• Prior and Adjacent Work
• Documentation

Plain Language Version

Imagine two computer security tools are looking at the same piece of software and trying to decide whether the software is vulnerable.

Sometimes the same software can be described in two slightly different ways. Different choices for identifiers, qualifiers, representations, aliases, and serialization formats can cause software to be represented differently. For example, one description might use an SPDX SBOM and another might use a CycloneDX SBOM. The formats differ, but they still describe the same underlying software components. This project studies whether the security tools treat differing descriptions consistently.

We are not just looking for places where the security tools disagree. We ask: What rule of sameness should apply? We compare that rule of sameness with what the software actually does.

If a security tool treats two descriptions as different when the governing rule says they are the same, this project can produce a checkable example showing exactly where the mismatch occurs.

The larger goal is to make security decisions more explainable and auditable. Instead of saying: The security scanner behaved strangely. We want to be able to say: Here is the exact identity rule, here is how the implementation behaved, and here is the precise location where the rule and the observed behavior stopped lining up.

Status

This repository contains an exploratory feasibility study evaluating whether the Structural Explainability Operational Identity framework (described in the paper abbreviated SE-210) supports a defensible MSR 2027 Registered Report on security-relevant identity semantics in software vulnerability matching.

This repository is under active development. It contains the study plan, protocol, identity commitments, validation and prospective case specifications, validation fixtures, scanner-adapter foundations, and the initial Python research-software implementation. The vulnerability-matching harness and prospective study design remain under active development.

No prospective study results have been collected. Publicly known cases used to validate the engineering machinery will remain separate from prospective research evidence.

Research Objective

Software composition analysis and VEX tools must decide when two package, component, artifact, or product representations identify the same entity. This project will first determine whether externally grounded identity/applicability commitments can be faithfully translated into the SE-210 Operational Identity framework and whether the resulting structural analysis adds something beyond conventional source-grounded conformance auditing. If it passes the feasibility decision, we will examine whether those operational decisions conform to an applicable identity commitment and will identify decisions for which the governing standards, documentation, or conventions are underdetermined.

The contribution is identity conformance, not scanner disagreement. Each adjudicated witness is intended to connect:

• two controlled inputs;
• the applicable identity commitment and its provenance;
• the identity relationship induced by an implementation;
• the Structural Explainability identity axis under evaluation;
• the resulting security consequence; and
• when nonconformance is established, a finite, reproducible witness.

The initial implementations under study are Grype and Trivy, including their VEX-processing and vulnerability-database behavior.

Research Questions

The study asks:

1. Which identity commitments govern vulnerability matching, and which are underspecified?
2. Which operational identity relations do SCA and VEX implementations induce under controlled transformations?
3. Where do operational relations diverge from applicable commitments, and on which Structural Explainability identity axes?
4. Which security consequences follow, including missed findings, inappropriate suppression, duplicated findings, incorrect scope propagation, and indeterminate behavior?
5. If supported by the evidence, does structural positioning explain identity-sensitive failures more precisely than conventional differential testing?

Registered-Report Boundary

Before Stage 1 authorization, this project may develop and test the harness, schemas, protocol, analysis code, and already-public engineering-validation fixtures. It must not execute or inspect the prospective discovery corpus.

Known public validation cases are excluded from every analysis used to answer the research questions. Raw observations will be preserved separately from normalized observations and adjudicated witnesses.

See the project plan notes regarding scope, milestones, risks, and freeze policy.

The implementation will reuse the finite operational-identity audit from se-verification-operational-identity at an exact version.

Repository Structure and Study Flow

The repository separates normative commitments, case specifications, execution protocol, validation material, and prospective research evidence.

flowchart TD

    C["contracts/<br/>identity commitments<br/>and source provenance"]
    CV["cases/validation/<br/>known public validation cases"]
    CP["cases/prospective/<br/>prospective study cases"]
    P["protocol/<br/>selection, adjudication,<br/>analysis, reliability,<br/>freeze and disclosure rules"]
    FV["data/validation/fixtures/<br/>registered validation fixtures"]
    D["data/validation/demo/<br/>bounded feasibility demonstrations"]
    O["data/validation/outputs/<br/>validation execution evidence"]
    S["src/<br/>adapters, audit machinery,<br/>normalization and witness construction"]
    R["results/<br/>prospective study results"]

    C --> CV
    C --> CP

    P --> CV
    P --> CP

    CV <--> FV

    D -. "related to validation cases;<br/>excluded from RQ analysis" .-> CV

    FV --> S
    S --> O

    CP --> S
    S --> R

    P --> R

Loading

The major boundaries are intentional:

• contracts/ records the identity commitments and provenance against which implementation behavior is evaluated.
• cases/validation/ contains already-public cases used to validate the engineering and analytical machinery.
• data/validation/fixtures/ contains the registered fixtures associated with those validation cases.
• data/validation/demo/ contains bounded feasibility and demonstration artifacts. These may be related to validation cases but are not research-question evidence.
• protocol/ defines how cases are selected, executed, adjudicated, and analyzed.
• cases/prospective/ defines the prospective study corpus but must not be executed before Stage 1 authorization.
• src/ implements the adapters, audit logic, normalization, and witness construction used by both validation and prospective execution.
• results/ is reserved for prospective study results and contains no prospective observations before authorized execution.

Validation and demonstration artifacts may establish that the machinery is technically sound and that a proposed formalization is feasible. They do not contribute observations to the analyses used to answer the registered research questions.

Development

This repository uses uv.

uv self update
uv python pin 3.14

uv python install
uv lock --upgrade
uv sync

uvx pre-commit install
uv run pre-commit autoupdate

git add -A
uvx pre-commit run --all-files
# repeat if changes were made by pre-commit tasks
uvx pre-commit run --all-files

uv run ty check
uv run python -m pytest
uv run python -m zensical build

# save progress
git add -A
git commit -m "your message here"
git push -u origin main

Validate the research-data registries and registered-report boundary from the repository root with:

uv run se-verification-vulnerability-matching validate

This command cross-checks commitments, cases, public evidence, and reduced fixtures. It parses prospective case metadata to verify the boundary, but it does not execute prospective cases or dispatch them to scanner adapters. Validation evidence remains categorically excluded from research-question analysis.

Publication Plan

Working title:

SE Operational Identity Semantics in Software Vulnerability Matching: An Exploratory Study.

If it passes the feasibility decision, the Stage 1 protocol is planned for the MSR 2027 Registered Reports track. The work is grounded in public scanner repositories, releases, security metadata, issue reports, fixes, and reproducible artifacts. Structural Explainability is the analytical method; software vulnerability matching is the empirical domain.

Prospective RR title, conditional on GO: "A Finite Conformance Audit for Security-Relevant Identity Semantics in Software Vulnerability Matching"

Annotations

.annotations/annotations.md

Citation

Citation metadata is available in CITATION.cff.

A Zenodo DOI will be added after this repository is archived.

License

MIT

Metadata

Machine-readable research-software metadata is available in codemeta.json.

Repository Manifest

The repository's role, scope, and dependencies are declared in SE_MANIFEST.toml.