Provenance

Cryptographic verification and build provenance for LinnemanLabs application and content

This site publishes full provenance for both the application server and the content bundle it’s currently serving. Everything on this page is derived from real build attestations and signatures - this is what I’m actually running and how it got here.

Application

The application server is a custom Go binary built with security and observability as primary concerns. This section displays provenance for the currently running binary, including source information, build attestations, vulnerability scans, SBOMs, licensing, and container metadata.

Webserver Source: linnemanlabs-web on GitHub

Build/Release System Source: build-system on GitHub

Content Bundle

The content bundle is a signed artifact containing all static HTML, CSS, JavaScript, and assets generated by Hugo. The server verifies bundle integrity at load time and exposes provenance information via API.

Website Source: linnemanlabs-site on GitHub

What’s next

This page currently covers application and content provenance. The cryptographic and transparency layer beneath the application is already self-hosted in the lab - Fulcio for keyless certificates, Rekor as the transparency log, TesseraCT as the certificate transparency log, and a Timestamp Authority for trusted timestamps, all rooted in an offline YubiKey-held CA with KMS-backed signing keys. Trust material is published at trust.linnemanlabs.com.

What’s still ahead is the layer below that - OS-enforced signed execution (IMA/EVM), dm-verity verified filesystems on golden images, kernel lockdown, UEFI Secure Boot, and TPM-based hardware attestation. The end goal is a verifiable chain from silicon to running application, where every layer’s integrity is cryptographically anchored to the one below it.

verification chain · silicon -> content

silicon firmware os runtime app content

verified today roadmap

Application bundle the running server binary

tl;dr · what verifies today

app — · —

verify --bundle app --summary

kms signature aws-kms

keyless signature fulcio · pending

transparency log rekor #pending, #—

timestamp rfc3161 · pending

artifact digest —

verifying… at —

trust attestation

Every release is dual-signed: an AWS KMS key signs the artifacts and inventory, and a keyless Fulcio certificate - minted from the workflow's GitHub OIDC identity - is logged to Rekor and anchored with an RFC 3161 timestamp. Both chains root in the self-hosted stack at trust.linnemanlabs.com.

aws kms signature

signed artifacts index inventory release sigstore bundle

identity

version —

track —

built —

go —

release id —

build id —

binary sha-256 —

artifact digest —

source → build → artifact

source

application source

—@—

build

github actions

— · run #—

artifact

container image

—

posture

policy gate — · worst — · enforcement —

vulnerabilities

—

critical

—

high

—

medium

—

low

—

negligible

—

unknown

total findings —

scanned —

licenses

status —

without license —

denied found none

software bill of materials

source packages —

artifact packages —

evidence ledger

application evidence - findings, SBOM packages, licenses, policy, attestations, artifacts for auditors

build tooling

tool	role	version	sha-256
Go	binary toolchain	—	—
cosign	signing	—	—
syft	sbom generator	—	—
grype	vuln scanner	—	—
trivy	vuln scanner	—	—
govulncheck	vuln scanner (Go)	—	—

vulnerability scan

scope—

deduplication—

gate threshold—

scanners

per-scanner results

show findings hide findings

software bill of materials

generated at

—

generators

formats produced

show all packages hide packages

licenses

licenses found

show packages by license hide packages by license

release policy

enforcement—

allow if VEX—

unknown licenses—

block on severity

allowed licenses

denied licenses

attestations

total—

source—

artifact—

SBOM scan license

show attestation files hide attestation files

evidence files

file count

—

Content bundle the static site being served

tl;dr · what verifies today

content —

verify --bundle content --summary

content hash sha384 · verified at load

kms signature pending

keyless signature fulcio · pending

transparency log rekor #pending, #—

timestamp rfc3161 · pending

integrity verified at —

trust attestation

The server recomputes the bundle's sha384 at load and refuses to serve on mismatch. Each bundle is also dual-signed at build time - an AWS KMS key plus a keyless Fulcio certificate - and each signature is independently logged to Rekor and RFC 3161 timestamped, all rooted in the self-hosted stack at trust.linnemanlabs.com.

verified by sha384 recomputation at load

content digest —

identity

version —

type —

built —

files · size — · —

content id —

schema —

commit —

build

actor —

system —

build run #—

builder identity —

host —

user —

build time —

commit date —

source → build → artifact

source

site source

—@—

→↓

build

github actions

— · run #—

→↓

artifact

content bundle

—

evidence ledger

content evidence - tooling checksums, file inventory, runtime, raw manifest for auditors

build tooling

tool	role	version	sha-256
Hugo	static site generator	—	—
HTML Tidy	html validation	—	—
Git	version control	—	—
Bash	build shell	—	—

file inventory

show all files

transparency · keyless

rekor origin—

rekor log id—

rekor log index—

rekor tree size—

rekor root hash—

entry kind—

entry version—

ct log id—

ct log timestamp—

ct log hash algo—

tsa imprint algo—

tsa imprint hash—

tsa serial—

tsa policy oid—

show rekor inclusion proof

show signed checkpoint + raw TSR

rekor signed checkpoint

RFC 3161 TimeStampResp · DER · base64

transparency · kms

rekor origin—

rekor log id—

rekor log index—

rekor tree size—

rekor root hash—

entry kind—

entry version—

tsa imprint algo—

tsa imprint hash—

tsa serial—

tsa policy oid—

show rekor inclusion proof

show signed checkpoint + raw TSR

rekor signed checkpoint

RFC 3161 TimeStampResp · DER · base64

runtime

source—

loaded at—

server time—

runtime hash—

raw manifest

show provenance.json