A false clean is worse than a gap
A gap you know about gets a compensating control. A gap reported as coverage gets nothing, because nobody knows to look. The expensive failures in security are almost never the ones somebody was watching.
Trust
What we do when we do not know.
Most security claims have two states: checked and clean, or checked and failed. The interesting third state is the one a product is tempted to hide, which is that a check did not actually happen. Here is where Bolt carries that state instead, and what it does with it.
Four places the product says unknown
Each of these was built for its own reasons by different people. That they converged on the same discipline is the point.
The supply-chain gate
Secrets, Rust advisories, npm advisories and licence obligations are scanned on every commit and again at release against a frozen build point. Each check reports pass, fail, or unknown. A scanner that could not run, timed out, or is missing reports unknown and is never recorded as a scanner that found nothing. Detail at /trust/supply-chain.
Content we could not read
When the data-loss engine meets part of a file it cannot parse, an unreadable archive member or a format it does not understand, that part is carried through to the caller as unread. It is not counted as inspected and found clean. A policy decision made on partial reading says so.
A detection engine that cannot run
The named-entity model that finds free-text names ships only on some platforms and is off until an administrator enables it. Enable it where it cannot run and the admin API reports the engine as degraded and names the engine actually in effect. It does not accept the setting and silently do nothing. Detail at /trust/questionnaire.
Independent scan links
Every release publishes a report link for each installer, keyed to that file's own SHA-256. Where no independent scan of those exact bytes exists yet, the file says so rather than leaving you to click and find an empty page.
Why we think this matters more than it sounds
It cannot be adopted retroactively
A third state has to exist in the code. Either a check can return unknown and a caller has to handle it, or the type has two values and the question was never asked. Ours has three, in four separate places, written by different people at different times.
It is the question you are actually asking
A security review is rarely trying to establish that a vendor is perfect. It is trying to establish whether the vendor will say so when they are not. Everything else on this Trust Center is downstream of that.
The same rule, applied to this website
A principle that stops at the product boundary is a marketing position. So the Trust Center carries its own unknowns in the same place as its claims rather than in a footnote: the supply chain page lists what our build provenance does not yet cover, the reviewer packet lists the assurance we do not have beside the assurance we do, and the CASA page spends as much space on what the assessment does not prove as on what it does.
Where we are wrong about any of this, we would rather hear it than not. Our disclosure policy commits to a one-business-day acknowledgement and a good-faith safe harbor, and a claim on this site that does not survive contact with the product is as much a finding as a bug is.
Reviewing Bolt?
The reviewer packet states what we have and what we do not, on one page, written to be forwarded without edits.