security.txt
This site does NOT currently publish /.well-known/security.txt. The reason is honest: RFC 9116 requires a mandatory Contact field, and since no verified direct channel is published yet, we refuse to fabricate a record that merely looks standards-compliant. The day a channel is published, the file is added and this section updates.
The file's Expires field is deliberately set well ahead and renewed before it lapses; an expired security.txt signals worse than none at all. The Canonical line pins the file's single official address — trust that address, not copies.
Responsible disclosure
Good-faith researcher reports are welcome: describe the finding, impact and reproduction steps, and allow a reasonable fix window before public disclosure. No bounty programme is promised; contributions are met with honest thanks.
A good report contains three things: the affected address or file, the observed behaviour, and reproduction steps where possible. Any report made without publishing exploit code, exfiltrating data or degrading the service counts as good-faith and is treated as such. Should you prefer encrypted contact, note it in your first message once a channel is live and a suitable method will be arranged together.
A good report contains three things: the affected address, the observed behaviour and, where possible, reproduction steps. Our commitment in return: acknowledgement, assessment within a reasonable window, and after the fix, credit under your name or anonymously as you prefer. Granting a fix window before public disclosure is the ecosystem's shared etiquette.
This site’s security posture
The site is static: no server-side code, database, sessions or forms — which structurally shrinks the attack surface. The deploy notes require HTTPS redirect, HSTS and security headers at the hosting layer; live header grades come from independent tools such as SecurityHeaders.
A static posture does not mean maintenance-free: the header recipe at the hosting layer, certificate renewal and domain records are periodically verified live. The site practices its own Deploy-Verify discipline — the producer drinks its own medicine. With no third-party scripts, the supply-chain surface is structurally closed; a dependency never added is a dependency never left unpatched.
Pentest and active-scan boundary
WebTrustEngine is not a penetration-testing tool, and no pentest is claimed for this site either. Active security testing against this domain requires written authorisation; unauthorised scans and load tests count as abuse.
Integrity verification
Every downloadable document’s SHA-256 is published in the Evidence Hub; the site’s own file inventory ships with manifest and checksum records. You can independently verify your file was not altered.
The verification steps are written out for three platforms in the Evidence Hub and take a minute even if the command line is unfamiliar. Should a file disagree with the published digests — usually a corrupted download — fetch it again; if the mismatch persists, report it.
The verification habit is not only for documents: the whole site ships in its deployment package with a file-by-file checksum list. Anyone running a mirror or archive copy can answer 'is this copy bit-for-bit the official release?' with a single command from the root.
What is not guaranteed
This page is not a security guarantee: no system can be declared “fully secure”. The commitment here is transparency — what is done, what is not, and which channel findings travel through.
Out-of-scope examples
The list illustrates rather than limits; for the researcher in doubt the rule is simple: when unsure, write anyway — if out of scope you are told politely, if in scope the process starts. A misclassified report never counts against you; the only truly out-of-scope behaviour is trying without asking.
The following do not count as security findings and need no report: session/CSRF scenarios that cannot exist on a static site, social-engineering attempts, the third-party e-mail provider s own configuration, and volume-only denial of service. For every real weakness outside those, the channel is open.
Incident communication
In a confirmed incident, the affected surface, actions taken and fix status are updated on this page — in restrained, evidence-tied language.
The rhythm of communication is defined too: while verification runs, the page says "under review" and shares no guesses; once confirmed, impact and action are written; at closure, root cause and the permanent measure are added. All three stages use the same language — evidence-bound, restrained, date-stamped. When there is no incident, the page stays silent; artificial updates buy no trust.
The measure of 'restrained language' is concrete: the affected surface is named, no assurances are given for the unaffected, and no guesses are written before the root cause is found. In security communication the costliest mistake is not panic but early certainty that later needs correcting.
Scope: what this page covers and what it does not
This page covers the webtrustengine.com domain and the static files shipped in this package. The hosting provider's infrastructure, the network layer and the domain registry are their operators' responsibility; findings there belong to the respective provider's security channel — though if you write to us, we will route you.
One more out-of-scope note: this page does not describe the WebTrustEngine product's security commitments inside customer environments; that frame lives in service agreements and the Technical Trust Note.
Dependencies and the supply chain
The site has no runtime external dependencies: no external scripts, fonts or API calls. This structurally excludes supply-chain attack surfaces such as a compromised third-party script. Build tools are used only at build time, and the output is pinned by a checksum list before deployment.