Security & Vulnerability Disclosure

Our security principles

Security at VeraMap isn't a checklist — it's the architecture. The product is built so that a successful attack against our infrastructure does not yield decryptable user location data. Beyond that architectural guarantee, we maintain standard production-grade controls and we welcome the help of researchers in finding what we've missed.

If you find something, we want to know. The faster we know, the faster the fix ships.

How to report a vulnerability

Email security@veramap.app with as much of the following as you can provide:

• A clear description of the issue and its potential impact.
• Steps to reproduce, ideally with a proof of concept.
• The affected component (mobile app + version, API endpoint, web URL, etc.).
• Whether you've shared the issue with anyone else.
• How you'd like to be credited (or not), if and when we publish the fix.

For sensitive disclosures, request our PGP key in your initial message and we'll provide it for follow-up correspondence.

What to expect from us

• Acknowledgement within 2 business days of receiving your report.
• Triage within 5 business days, with an initial assessment of severity.
• Status updates at least every 7 days while the issue is open.
• Resolution on a timeline matching severity — critical issues are handled in days, not weeks. We'll let you know when the fix is in production.
• Credit in our security advisories and in this page's hall of fame, if you'd like to be named.

Scope

The following are in scope for our disclosure program:

• The VeraMap iOS application.
• The VeraMap Android application.
• The VeraMap API and WebSocket gateway hosted at api.veramap.app.
• The marketing website at veramap.app.
• The cryptographic protocol used to encrypt and route location data.

Out of scope

We don't accept reports for the following — usually because they're informational or known:

• Findings from automated scanners that don't include a working proof of concept (banner-grabbing, outdated-library version reports without exploitability, missing security headers on static pages, etc.).
• Social engineering, phishing, or physical attacks against VeraMap staff, contractors, or infrastructure.
• Denial-of-service attacks, including distributed (DDoS) and resource-exhaustion attacks.
• Issues requiring physical access to a victim's unlocked device.
• Issues affecting only obsolete or unsupported browsers, mobile OSs, or app versions.
• Reports of vulnerabilities in third-party services we use; please report those directly to the vendor.
• Self-XSS, clickjacking on pages with no sensitive actions, missing rate limiting on non-auth endpoints.

Safe harbor

VeraMap will not pursue legal action against, or report to law enforcement, security researchers acting in good faith and in accordance with this policy. Specifically, we consider research conducted in line with this policy to be:

• Authorized in view of any applicable anti-hacking laws (e.g., the U.S. Computer Fraud and Abuse Act).
• Authorized in view of relevant anti-circumvention laws (e.g., the DMCA), with no claim brought against you for circumventing technology controls in the course of your research.
• Exempt from our acceptable use restrictions in the Terms of Service for the specific activity required to identify and report the issue.

You're expected to comply with all applicable laws, avoid harm to other users' data and our service, and give us a reasonable window to fix the issue before public disclosure (typically 90 days from initial report, or sooner if we ship the fix earlier).

If at any time you have concerns about whether your research is consistent with this policy, please reach out before continuing.

Rewards

VeraMap doesn't run a paid bug bounty at this time. We do offer:

• Public credit in our security advisories (with your permission).
• A listing on this page's hall of fame.
• Swag for high-impact findings, where applicable.
• Direct access to the engineering team during disclosure — your reports go to engineers, not a triage service.

If we add a paid program in the future, we'll announce it here first.

Cryptographic stack

For researchers reviewing the encryption layer specifically, the relevant primitives are:

• Public-key wrapping: Curve25519 + XSalsa20-Poly1305 via nacl.box() (TweetNaCl).
• Symmetric encryption of payloads: XSalsa20-Poly1305 via nacl.secretbox().
• Geofence-event signatures: Ed25519. Geofence labels are encrypted; only the signature is plaintext on the wire.
• Device key storage: private keys live in the platform secure enclave (iOS Keychain with Secure Enclave-backed keys where supported; Android Keystore).
• Transport: TLS 1.3 across all network paths; certificate pinning on mobile.

Reports about the choice of primitives, key-rotation behavior on member removal, or assumptions in the wrapping scheme are particularly welcome.

Contact