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.
local demo · registry allowlist only
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.
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 →
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.
Read as a list: 5 authorization · 4 semantics — the focus of the LMV draft · 3 provenance · 2 integrity · 1 identity.
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.
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.
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.
106 published CVEs · 10 GHSAs without a counted CVE · 29 security PRs. Published snapshot: 2026-09-26.
317 counted records across 149 projects. Records include different evidence types, not a count of independent vulnerabilities.
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.