Scout — proof collection

Beyond scanning, Scout gathers proof attestations: local, on-host evidence about certificate trust and custody, published to the Hub alongside every scan report. Every attestation carries a status from a small vocabulary — proven, partial, conflict, missing — and Scout filters out any attestation whose kind isn't in the wire vocabulary before publishing (a soft guard against collector drift, proof_collectors.go:20).

There are exactly two proof kinds. Each is fed by one or more collectors.

The Hub does not yet consume this evidence

Scout collects and publishes proof attestations on every report, but the Hub-side feature that once displayed them was retired. Today the Hub only logs a warning when Scout reports dropped attestations (dropped_proof_attestation_count); it does not persist, display, or act on the attestations themselves (hub/src/api/agent.rs). Treat this page as documenting a Scout-side capability that is live on the wire but currently unconsumed, not an operator-visible feature.

Read the maturity notes

Several collectors are narrower than their name suggests. This page is deliberately honest about what is and isn't proven, because the distinctions matter when you rely on the evidence. Everything below describes Scout on Linux x86-64 — the supported platform (see Install → Supported platforms).

Two proof kinds were removed

local_trust_store_membership and local_renewal_controller were pruned from the wire vocabulary (entity-split prune): no collector for either exists anymore, and the Hub drops any attestation carrying one of those kinds at ingest. If you remember four kinds from an earlier version of this page, that's why there are only two now.

installed_vs_served

"Does the cert configured/installed here match what's actually served on the wire?" Two collectors emit this kind:

• Generic scan-vs-local — cross-references live scan fingerprints against filesystem-discovered certs. proven when fingerprints agree, conflict when they differ, partial when only one side is present.
• Server-binding (nginx / Apache / HAProxy / Caddy / Traefik / Envoy) — reads the configured leaf cert file off disk, fingerprints it, and compares to the live scan for the name-matched vhost. Never reads private-key material (private_key_material_collected: false). Config paths are the conventional /etc locations for each server.

Coverage gaps

Server-binding proofs don't cover Tomcat/Kafka/Elasticsearch/Logstash's own served certs — those apps have no installed_vs_served collector, and there is no Kubernetes / cert-manager collector anywhere in Scout — if the product surfaces K8s cert-manager evidence, that lives outside Scout.

key_custody_metadata

"Is there a plausible private-key file beside this cert, and what's its file hygiene?"

This never reads keys and never checks pairing

Despite the name, this collector is filename-convention guessing + stat() — it records the candidate key path, octal permission mode, a coarse permission summary, symlink flag, size, and owner/group UID/GID. It explicitly sets private_key_material_collected: false, key_match_validated: false — it does not open the key or verify it pairs with the cert. Describe it as "candidate key-file discovery + file hygiene," not "key custody verification."

Maturity at a glance

Collector	Kind	Maturity
Generic installed-vs-served	installed_vs_served	Live
Server binding	installed_vs_served	Live
Key custody metadata	key_custody_metadata	Live