Build provenance

Signing proves an artifact is authentic - the exact bytes that were published, unmodified. It does not prove the artifact is safe: a poisoned dependency or a compromised build produces a perfectly-signed artifact. Provenance closes that gap. It records who built the artifact, from what source, with what builder, and - when a signed attestation is supplied - verifies it.

Provenance is metadata. Your application and build are never inspected or uploaded; you stay zero-integration.

Two levels

• Declared - your pipeline reports the builder and source over an authenticated channel. Trustworthy as far as your pipeline and token are.
• Verified - your pipeline also ships a signed SLSA attestation. Meshanics checks the signature against the signing keys you registered and binds it to the artifact's digest. This is the strong form.

Both surface in the Trust Center, and the rollout provenance gate can require verified before an artifact ships.

1. Create an ingest token

In the console, open Integrations → Inbound · Build provenance and create a token. It is shown once. The token can only submit provenance for your fleet - store it as a CI secret.

2. Report from your pipeline

GitHub Actions

- uses: meshanics/report-provenance@v1
  with:
    endpoint: https://panel.meshanics.com/api/v1/provenance/ingest
    token: ${{ secrets.MESHANICS_PROVENANCE_TOKEN }}
    name: detector
    version: 2.1.0

The builder and source are taken from the workflow context.

Any CI (one curl)

curl -fsS https://panel.meshanics.com/api/v1/provenance/ingest \
  -H "Authorization: Bearer $MESHANICS_PROVENANCE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "detector",
    "version": "2.1.0",
    "builder_id": "gitlab-ci@your-org",
    "source_repo": "git+https://gitlab.com/your-org/detector",
    "source_ref": "v2.1.0",
    "build_type": "https://slsa.dev/gitlab"
  }'

Identify the artifact by name + version, or by digest (sha256:…).

3. Make it verified

Register the public half of your signing key under Integrations → Trusted signing keys (ed25519 or ECDSA, PEM). Then have your pipeline sign a SLSA in-toto statement into a DSSE bundle (for example with cosign attest-blob) and include it:

{
  "name": "detector",
  "version": "2.1.0",
  "attestation": "<base64 of the signed DSSE bundle>"
}

If the signature verifies and the statement's subject matches the artifact's digest, the artifact is marked verified and the builder and source are taken from the attestation. If a supplied attestation does not verify, the request is rejected - it is never silently downgraded.

4. Trusted-builder allowlist (optional)

A valid signature proves who vouched for an artifact - but a trusted key can legitimately sign builds from many repos and branches. The allowlist adds the second question: was it built by the builder, from the source and ref you expect? A verified artifact built from a fork, a feature branch, or an unexpected pipeline is then refused even though its signature checks out.

It is opt-in and never mandatory: with no rules, your provenance gate is unchanged. Add rules under Integrations → Inbound · Trusted-builder allowlist. Each rule is a set of patterns - builder_id, source_repo, source_ref, build_type - where * is a wildcard and a blank field matches anything. An artifact passes if it matches any rule. The allowlist is evaluated by the same provenance gate: in require a non-matching verified artifact is blocked (with a reasoned, audited override); in warn it is recorded.

A rule for releases built by the GitHub Action (which reports a builder of https://github.com/<org>/<repo>/.github/workflows@<ref> and a source of git+https://github.com/<org>/<repo>):

This admits only tagged releases from my-org repositories, from any other builder/source/branch is refused. Leave a field blank to not constrain it.