Security

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

axilog.io is a small static documentation site with a deliberately narrow attack surface. This page tells security researchers how to reach us, what we accept as in-scope, and what to expect in return. The same policy covers the partner site at speytech.com — both sites share a trust boundary and a disclosure inbox.

Last reviewed:

This policy covers two surfaces:

  • axilog.io — the Axioma framework's public specification site. Pure static Astro build, served by nginx, with cookieless self-hosted Umami analytics as the only embedded telemetry.
  • speytech.com — the maintainer's portfolio site, hosted on the same infrastructure under the same operational discipline. Static Astro build with a contact form and a CSP receiver endpoint as the only server-side surface.

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.

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 the underlying operating system and Postgres used by the self-hosted Umami instance 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.

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.

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.
  • 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 configuration value is a proof of concept; mass-exfiltrating the build-artefact tree is not.
  • Don't disrupt service for other users — no denial-of-service tests, no high-volume automated probing, no destructive testing against production.
  • 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.

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

  • Information disclosure beyond what the public sites are intended to publish — configuration, credentials, internal paths, build-artefact leakage, source-repository content served unintentionally.
  • Injection issues — server-side template injection, header injection, redirect open-relays, XSS that 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 (see /privacy/ and /cookies/).
  • Authentication or authorization defects in any partner-site surface that handles them (the speytech.com contact form, the speytech.com CSP receiver endpoint). Axilog.io itself has no authenticated surface.

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.

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

The site is pure static — Astro builds, nginx serves. There is no database, no user-session state, no authenticated surface, no contact form, no CSP receiver endpoint, and no PHP infrastructure. Anything matching common probe patterns (PHP, WordPress, hidden files, config and backup extensions) is dropped at the nginx layer; the deny rules are documented inline in the nginx configuration.

The nginx configuration enforces several defensive patterns: HSTS, a Content Security Policy (currently in Report-Only mode while it is being tuned), connection- close on common probe patterns, and a separate SEO log format that makes crawler behaviour analysable independently of attack noise. Two access logs are maintained: a standard combined-format log for operational analysis, and an SEO log for crawler traffic. Both are rotated daily and retained for 90 days. See /privacy/ for the data-handling description.

The build pipeline runs a structural and SEO validator after every deploy. Anomalies are surfaced before they reach search engines or crawlers; the validator runs against the live site post-swap, so any regression introduced by a build is caught against production rather than against a local preview that might lie.

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

One thing worth saying separately: axilog.io is operated to the same discipline the framework it hosts recommends. The Axioma framework's substantive position is that audit trails should be cryptographic objects rather than log files, that determinism is better than reproducibility, and that the integrity of published material should be verifiable rather than trusted. The publishing infrastructure follows the same commitments at the scale appropriate to a static site.

For the framework itself, the published specifications carry their own integrity guarantees: bit-identical reproduction across x86, ARM, and RISC-V platforms; cryptographic attestation per CBF v1 deployment bundle; Merkle audit chains spanning data, training, and inference layers; per-spec PDFs generated from the canonical HTML source with the same hash. These properties are described at /framework/ and demonstrated through the harness at github.com/SpeyTech/certifiable-harness.

A reader who wants to verify the framework's claims rather than trust them has a defined route: clone the public spec repository, reproduce the reference implementations, run the harness, compare hashes. The framework eats its own discipline; this site exists to publish what that discipline produces.

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.

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.

Disclosure contact
security@speytech.com
PGP key
/.well-known/pgp-key.txt
security.txt
/.well-known/security.txt
Partner policy
speytech.com/security/
Next review due