Security

How to report an issue, what we ask, what we commit to

In Scope

This policy covers two surfaces:

  • speytech.com — the static Astro site, its build pipeline, its nginx configuration, and the deploy infrastructure visible from the public internet.
  • axilog.io — the Axioma framework's public specification site, on the same hosting infrastructure, under the same operational discipline.

Both sites share a single disclosure contact and a single security policy because they share a trust boundary: same VM, same operator, same build-and-deploy pipeline. A report against either domain reaches the same inbox.

Out of Scope

The following are deliberately not covered by this policy:

  • app.speybooks.com — the SpeyBooks SaaS platform runs a separate security posture appropriate to a multi-tenant accounting application. It has its own disclosure process. If a report touches SpeyBooks specifically, we will route it; if you can address it to the right surface from the outset, please do.
  • Third-party infrastructure — the upstream hosts, CDNs, registrars, certificate authorities, and analytics provider (self-hosted Umami, but the underlying Postgres and the host operating system are not in scope).
  • Issues that depend on browser bugs, user device compromise, or attacker-controlled clocks. We accept that not every theoretical attack vector is one we can defend against, and we don't want to spend your time on reports we cannot act on.

Reporting a Vulnerability

Send reports to security@speytech.com.

For sensitive material, encrypt with the PGP key published at /.well-known/pgp-key.txt. Verify the fingerprint before encrypting:

E575 34E6 17EB D9C1 7096  5333 AEB2 FE92 2344 130A

This is an ed25519 key issued for security@speytech.com on 2026-05-16. If the fingerprint shown by your client does not match, do not encrypt to that key — contact us in plaintext describing only that you have a sensitive report, and we will arrange a verified out-of-band exchange.

A good report includes:

  • A clear description of the issue.
  • The steps required to reproduce it, including the affected URL or endpoint.
  • What you observed, and what an attacker could plausibly do with it.
  • Whether the issue is currently being exploited, to your knowledge.
  • Any remediation suggestions, if you have them.

You don't need to find a maximum-impact framing for the report to be worth sending. A clearly described low-impact issue is more useful than a speculative high-impact one.

What We Commit To

When a report arrives:

  • Acknowledgement within 72 hours. This is a person-to-person acknowledgement, not an autoresponder. If you do not hear back in that window, please assume the message was lost and re-send.
  • An initial assessment within 7 days of acknowledgement, telling you whether we have reproduced the issue and our intended response.
  • Status updates at meaningful points, not on a calendar. If we are working on a fix, you will hear when we are about to ship it; if we have decided not to act, you will hear why.
  • Credit on request in the remediation note, the relevant changelog, or any public write-up we publish about the fix. Anonymity is the default if you prefer it.

What We Ask of You

  • Give us a reasonable window to investigate and fix the issue before publishing. The right window depends on the severity; we will discuss it openly rather than impose an arbitrary number.
  • Don't exploit the issue beyond what's needed to demonstrate it. Read access to one record is a proof of concept; downloading the database is not.
  • Don't disrupt service for other users — no denial-of-service tests, no high-volume automated probing, no destructive testing against production data.
  • Keep findings private until we agree they can be published. If we have not responded in a reasonable time after a serious issue, you are free to escalate or disclose; we trust your judgement.

We don't operate a bug bounty programme. We can offer thanks, public credit, and (occasionally, for substantive reports) a small token of appreciation arranged with you privately. We don't pay cash for reports and we don't compete with researchers' time at commercial rates.

What Counts as a Vulnerability

The reports we can act on, in rough order of usefulness:

  • Authentication or authorization defects in any surface that handles them (the contact form, the CSP receiver endpoint, the rare authenticated administrative paths).
  • Information disclosure beyond what the public sites are intended to publish — configuration, credentials, internal paths, build-artifact leakage.
  • Injection issues — server-side template injection, header injection, redirect open-relays, XSS where it bypasses CSP.
  • Supply chain issues — compromised dependencies, build pipeline tampering, signing or attestation gaps.
  • Privacy issues — analytics inadvertently capturing identifying information, third-party scripts leaking referrer data, cookies set outside the documented scope.

The reports that are unlikely to be acted on (please feel free to send them anyway — we'd rather decline than miss something):

  • Missing security headers on responses where their absence is not exploitable.
  • CSP Report-Only violations that do not affect site behaviour.
  • Theoretical CSRF against endpoints with no authenticated state.
  • Reports generated by automated scanners without human triage.
  • Best-practice suggestions decoupled from a concrete attack.

How We Operate

A brief description of the security discipline behind these sites, so researchers know what they are looking at.

The public sites are static — Astro builds, nginx serves. There is no database, no user session state, no privileged authenticated surface. The two PHP endpoints (/api/contact.php and /api/csp-report.php) are allowlisted and tightly scoped; everything else under .php is dropped at the nginx layer.

The nginx configuration enforces several defensive patterns: HSTS, a Content Security Policy currently in Report-Only mode (with violations posted to an authenticated receiver), connection-close on common probe patterns (PHP, WordPress, hidden files, config and backup extensions), and a separate SEO log format that makes crawler behaviour analysable independently of attack noise.

The build pipeline runs an SEO and structural validator after every deploy. Anomalies are surfaced before they reach search engines or crawlers. Logs are analysed regularly for unusual probe patterns and new attack categories.

This is not a comprehensive security architecture. It is the discipline appropriate to two static sites with a small authenticated surface. We have deliberately chosen this scope rather than build a heavier posture that would not be honestly maintained.

Coming Later

Machine-readable transparency artifacts — including the ability to fetch the current state of our automated security audit at a stable URL — are planned but not yet shipped. When they arrive, this page will be updated to point at them. Until then, this disclosure policy is the authoritative source for how to report issues and what to expect in return.

Policy Lifecycle

This policy is reviewed annually, alongside the renewal of the security.txt file at the same expiry date. The date below records when the policy was last edited, not when it was last read; if something is unclear, that is on us, please write and tell us.

Last updated: May 2026