v5.60.0 10 June 2026 Feature

Live Trust Badge: Security Verification Served in Real Time

Why This Matters

The previous release built a public trust API and a single source of truth for the security grade, but the badges in the page footers were still baked at build time. That left one gap: a grade was only as current as the last site deploy, kept fresh by the discipline of deploying after every audit. Discipline is an operational control, not a guarantee, and the documentation badge sitting frozen for three months earlier this year was that gap made visible.

This release closes it. The security cell in the footer of every page on both the marketing site and the documentation site is now served live by the trust API and assembled into the page at request time. The grade you see is the grade as measured, not the grade as it stood when the page was last built. A daily audit refreshes it, and a freshness gate refuses to render any grade older than the threshold. The badge no longer depends on anyone remembering to deploy.

Live Trust Badge

  • Served at request time, not build time The footer security cell is now assembled into each page as it is served, pulling the current verification fragment from the trust API. The page frame is static; the badge inside it is live. Updating the grade no longer requires rebuilding a single page.

  • A stale grade cannot render If the verification data is stale, malformed, or unavailable, the badge renders an honest “Security verification pending” fallback rather than a stale grade. This is enforced at the serving layer on both sites and was verified by negative testing on the production host: stale, invalid, and missing cases were each induced under controlled conditions and the badge was seen to withhold the grade and fail to a safe state, then recover when fresh data returned. Proof anchor: trust gate render tests T1 through T6, both domains.

  • Daily freshness, decoupled from publication The security audit now runs every day and writes the verification data the live badge reads. The badge can be at most a day behind reality. The full audit report is still published weekly to Insights as a dated point-in-time record. Measurement and publication are now separate cadences: the badge tells the daily truth, the article keeps the weekly record.

  • One writer, one source A single process is the sole author of the verification data, and as of this release it writes exactly one file. The two build-time data files the footers previously read have been retired along with the build-time badges they fed. There is now one producer and one consumer path, with no second copy to drift.

A Worked Example of the Gate Doing Its Job

Transparency is the point of publishing a security grade, so it is worth recording that the system earned its keep on the day it shipped. During this work the daily audit flagged a warning the automated patch tooling had been silent about: two pending OpenSSL security updates that the unattended-upgrade configuration was no longer matching, because the host had rolled to an older stable Debian release and the update path was tracking the wrong package suite.

A badge hard-coded to show a clean grade would have shown green over a real pending security update on the host that fronts the API. The live badge showed the warning honestly, the cause was traced to the configuration, the OpenSSL packages were applied, and the update path was pinned so the same drift cannot recur unseen. The grade returned to its top band by fixing the finding, not by reweighting it. A trust signal that can surface an uncomfortable truth on its first day is worth more than one that only ever shows good news.

Operational Impact

  • Both footer badges moved from build-time baked to request-time live; the grade is current without a site deploy
  • A stale, invalid, or missing grade fails to a safe “verification pending” state at the serving layer, verified by negative testing on both domains
  • Verification data writers and copies reduced to a single producer writing a single file
  • Audit cadence is daily for the badge, weekly for the published report, as separate schedules
  • A real pending OpenSSL security update, missed by automated patching due to a release-tracking misconfiguration, was surfaced by the audit, applied, and the patch path corrected
  • The daily audit no longer rebuilds the sites to refresh the badge, since the badge is live; site builds now happen only when there is new published content to carry

Versioning

Internal components were versioned during this work with no change to any public API surface. The trust API endpoints introduced in the previous release are unchanged. The live badge is assembled by the web servers using standard server-side includes; no client-side JavaScript is involved, and the fallback is plain server-rendered markup.

Files Changed

Backend:

  • Trust API: the verification fragment now carries the full footer security cell, so both sites render one shared, identical badge from a single source

Frontend / both sites:

  • Footer components: the build-time security badge replaced with a live server-side include and a byte-identical safe fallback, on both the marketing site and the documentation site
  • Deploy pipelines: a build gate on each site asserts the served page carries the live include and its fallback, so a future build cannot silently ship a frozen badge

Infrastructure:

  • Web server configuration on both sites assembles the live badge with a short server-side cache, well inside the freshness threshold
  • The audit pipeline writes a single verification file and no longer deploys the sites on its daily run; the host patch path was corrected as described above

The badge has moved from “this was true when we built the page” to “this is true now”, and it proved the difference on the day it shipped.