Skip to main content

Security

Vulnerability Disclosure Policy

If you have found a security vulnerability in The Living Chronicle, please report it to us privately so we can fix it before it gets exploited. We take every report seriously and respond promptly.

Contact: security@aegisbrightsmark.com

Scope

The following assets are in scope for vulnerability research:

  • Production API — api.thelivingchronicle.com and all versioned endpoints.
  • Web — thelivingchronicle.com and all subdomains.
  • iOS app — The Living Chronicle on the Apple App Store.
  • Android app — The Living Chronicle on Google Play.
  • Companion API — public developer endpoints served from the production API.

Out of scope

  • Denial of service / volumetric attacks. Do not send traffic that could degrade the service for real users.
  • Physical attacks. Physical access, social engineering of staff, and phishing attacks against employees are out of scope.
  • Social engineering. Tricking users or staff into revealing credentials.
  • Third-party services. Vulnerabilities in infrastructure we do not control (Apple, Google, Vercel, RevenueCat, Expo, Supabase) should be reported to those vendors directly.
  • Rate-limit bypass. We have rate limits in place and we know they are not infinite. Reporting that a determined attacker can hit us with enough requests to trigger 429s is not a finding.
  • Reports that require an unlikely precondition. Self-XSS, issues that require the attacker to have a valid session, or issues that require the victim's device to already be compromised.

Rules of engagement

  • Do not exfiltrate user data. If you can prove the issue with a single test record you created yourself, that is enough.
  • Do not modify production data. Read access is sufficient to demonstrate most bugs. If write access is necessary, use a test account and document what you changed.
  • Do not perform automated scans against production. If you need to scan, contact us first and we will set up a staging instance.
  • 90-day disclosure. Give us 90 days to fix the issue before disclosing publicly. If the fix takes longer, we will negotiate a timeline.
  • Coordinate with us. If you want to publish a blog post or conference talk about a finding, let us know in advance so we can verify the fix is deployed and offer technical review.

How to report

Email security@aegisbrightsmark.com with:

  • A description of the vulnerability.
  • Steps to reproduce, if possible.
  • The affected URL, endpoint, or app screen.
  • Your name and contact info so we can credit you in the Hall of Fame (optional — anonymous reports are accepted).

We will acknowledge your report within 48 hours and aim for a fix within:

  • Critical severity — 7 days.
  • High severity — 30 days.
  • Medium severity — 60 days.
  • Low severity — 90 days.

Bug bounty

We are a small team and do not currently offer monetary bug bounties. We do credit researchers in our Hall of Fame and respond promptly. If our situation changes — for example, if we grow to the point where a formal bounty program makes sense — we will update this page.

Hall of Fame

We gratefully acknowledge the following researchers who have responsibly disclosed vulnerabilities:

No reports yet. Be the first — and thank you in advance.

security.txt

This policy is also referenced from our /.well-known/security.txt file, which follows RFC 9116. The file includes our contact email, the canonical URL of this policy, the expiry date (one year from publication), and the preferred language (English).

General security questions

For general security questions unrelated to vulnerability research — encryption practices, data retention, GDPR compliance, DPA requests — please contact info@aegisbrightsmark.com.

Security — Vulnerability Disclosure Policy — The Living Chronicle | The Living Chronicle