Supply-chain provenance for citizen-facing tools
A citizen-facing supply-chain status indicator that translates raw bill-of-materials data into a single meaningful signal ('all dependencies current, no known vulnerabilities' vs '3 critical vulnerabilities upstream'), backed by a machine-readable document for agents.
A citizen reaching a service through an agent, or an agency standing behind a tool, is trusting not just the tool but everything it is built from: its libraries, the models it calls, the data it draws on. Approval on the day it is certified says nothing about whether one of those parts has since become vulnerable or changed underneath it.
The challenge is to know what a tool depends on, and to keep that knowledge current, so trust reflects the tool's state now rather than on approval day.
Government needs trust in a tool to track the tool's actual state, not a one-time approval: a current, queryable record of what it depends on, so a new vulnerability upstream shows up in the trust signal rather than going unseen. An agent deciding whether to rely on the tool needs that record in a form it can read.
The builders most at risk of being shut out are the small ones, the volunteer or single-developer civic tools that cannot run a manual supply-chain audit for every release. Keep the path open by making the dependency record something a tool can generate and keep updated automatically, so producing it is a build step, not a compliance project. A tool that cannot yet produce one should be marked unverified, not excluded.
A live status badge is driven by continuous SBOM evaluation rather than a static certificate, so the trust signal reflects current supply-chain risk instead of approval-day state.
No surface has been built yet; the approach above is the brief for one.
- Emerging Headline
A software bill of materials (SBOM) is discretionary and agency risk-based in US federal procurement, increasingly mandated in EU regulation, with tooling to consume and visualize it maturing fast.
- Frontier
Folding an SBOM into civic technology certification has no working precedent.
US Executive Order 14028 and CISA SBOM requirements (US, 2021–present). EO 14028 (May 2021), which remains in force, directed work toward software supply-chain security including SBOMs. CISA published minimum-elements guidance (updated draft June 2025) and maintains an SBOM Resources Library. The federal SBOM mandate has since been rolled back: EO 14306 (June 2025) rescinded EO 14144's SBOM and attestation enhancements, and OMB Memorandum M-26-05 (23 January 2026) makes vendor SBOMs and security attestations discretionary — a matter for agency risk-based assessment — rather than mandatory.
EU Cyber Resilience Act and SBOM alignment (EU, 2024–2025). The CRA mandates SBOMs for products with digital elements sold in the European market; OpenSSF and others are aligning SBOM standards globally (SPDX, CycloneDX) between US and EU requirements.
FDA SBOM requirements for AI medical devices (US, 2025). The FDA's 2025 premarket guidance for AI-enabled device software functions requires an SBOM to enable vulnerability tracking, extending SBOM requirements from general IT procurement into domain-specific safety regulation.
SBOM visualization tools (2024–2025). A growing ecosystem makes SBOMs consumable beyond security teams: SBOM Play (browser-based, privacy-first) for dependency graphs, license breakdowns, and vulnerability mapping; CycloneDX Sunshine for interactive radial dependency visualization; OWASP Dependency-Track for API ingestion and evaluation against live vulnerability intelligence.
High for supply-chain transparency; moderate for citizen-facing UX. SBOMs are essential infrastructure for any trust registry or certification regime: they enable ongoing monitoring, not just point-in-time approval. The citizen-facing design challenge is translating SBOM data into a meaningful signal. For AI agents, SBOMs provide structured, queryable metadata that can ground decisions about whether to rely on a tool.
An SBOM addresses component-level supply-chain integrity, not algorithmic correctness. It would not catch a flawed calculation method, which is a methodology failure rather than a compromised dependency.