1sealsemantic last-mile verification

0x00What 1seal checks

draft model · private development · scoped checks

The signature is perfect. The payload is wrong.

1seal researches failures in signing, release and verification systems. We are developing a toolkit to check that a payload matches declared intent before it is signed, deployed or accepted. The toolkit remains private/pre-release. Last-mile verification (LMV) is the draft model behind this work.

Advisories · Research evidence · Current availability · Services

Scoped security reviews of signing and release pipelines, by request. Product access is separate.

local demo · registry allowlist only

...Check not run
identitysigner shown as sample datanot checked integritydigest shown as sample datanot checked provenanceno attestation evaluatednot checked semanticsregistry not checkednot checked

The local check has not started. No signing or deployment takes place.

payload about to be signed · edit the registry

{
  "action":   "deploy",
  "registry": "",
  "base":     "cgr.dev/chainguard/static",
  "digest":   "sha256:9f2c…a1",
  "signer":   "ci@approved.example"
}

Check unavailable until the local script starts. If this message remains, enable JavaScript or reload the page.

declared intent · local invariants

registry ∈ ["approved-registry.io"]
# only this equality check runs in this demo

Enter approved-registry.io for PASS, or any other value for FAIL. Only the registry is checked, locally with no network request. This is not signature verification or the semantic LMV engine.

The expected registry is predefined for this example. In a real deployment, the source of approved intent and why it is trusted must be defined separately; the payload being checked cannot be its own sole proof of approval.

0x01Start here

Why are you here?

Working with us: scope and how to write · labs@1seal.org · Machines: /llms.txt

0x03Records336 counted public records · definition: counting rules; records are not independent vulnerabilities · data as of 2026-10-13

Recent records

Newest 5 counted records by disclosure date.

All 342 research records

0x05About this work

§1

The gap is semantic

Some attacks do not break a signature. They make you sign the wrong thing. Digest substitution between build and sign, a counterparty swapped between approval and submission, firmware downgraded to a vulnerable version — a signature may still validate while the artifact is wrong.

The same discipline applies wherever signing exists: containers, releases, SBOMs, transactions, firmware, agent actions. Domain mappings →

§2

How it works

LMV compares a payload with declared intent: supplied expected values and constraints. This map shows complementary security questions, not a required processing order or five separate products. One tool or rule can support several checks.

5authorization — is this action permitted? OPA, Cedar 4semantics — does this match intent? LMV draft · private implementation 3provenance — where did this come from? SLSA, in-toto 2integrity — were the bytes tampered? digests, Rekor 1identity — who is this? PKI, Fulcio, SPIFFE

Read as a list: 5 authorization · 4 semantics — the focus of the LMV draft · 3 provenance · 2 integrity · 1 identity.

Worked example: checking an image before signing →

§3

What a PASS means — and what it does not

A PASS is scoped. It means the evaluated payload matched the declared intent under the configured invariants and the available evidence. It does not mean the action is lawful, safe, compliant, approved, or generally trustworthy.

No layer's PASS should be silently consumed as another layer's PASS.

§4

Brakes are part of the control

A verification layer needs a safe path under uncertainty. Four draft protocols describe degraded-mode decisions when verification cannot complete; appeals with recorded evidence; an invariant lifecycle from experimental to retired; and error-cost calibration per domain. These are design rules, not measured product guarantees.

Read the protocols →

§5

Research foundation

Public vulnerability research across signing, update security, certificate validation and policy enforcement informs this work. The discipline of reproducible evidence and bounded claims carries into LMV; the research record is not a product validation.

112 published CVEs · 12 GHSAs without a counted CVE · 29 security PRs. Portfolio updated: 2026-10-13.

336 counted records across 157 projects. Records include different evidence types, not a count of independent vulnerabilities.

Browse research →

§6

Status, stated plainly

1seal is an N=1 research and engineering effort. LMV is a draft model. The public 1seal/verifier repository currently documents an offline DSSE/JCS evidence verifier; executable implementation code is not published there. The semantic implementation remains in private development / pre-release. External review, conformance testing and independent implementation remain prerequisites for broader claims.

Questions or a scoped research engagement: labs@1seal.org. Services are separate from product access.