Security & vulnerability disclosure

01Our security posture

Core protections built into the Service:

• One public surface. Only the control plane is exposed; the protocol engine, database, and your targets are never directly reachable.
• Credentials never reach the browser. Target secrets are stored gateway-side and injected into connections server-side.
• Outbound-only connectors over mutually-authenticated TLS — the gateway never dials into your network.
• Mandatory MFA and short-lived, per-session tokens.
• Tenant isolation by organization with Postgres row-level security, and per-organization credential encryption at rest.
• Append-only audit logging of who connected to what, when, and for how long.

02Safe harbor

We will not pursue civil or criminal action, or notify law enforcement, for security research conducted in good faith and in accordance with this policy. If legal action is initiated by a third party against you for activity that complied with this policy, we will make our authorization known. To remain protected, stay within scope, avoid privacy violations and service disruption, and give us reasonable time to remediate before public disclosure.

03Scope

In scope

• lazyconman.com and its marketing site;
• the application control plane at app.lazyconman.com;
• the connector agent and its enrollment/tunnel protocol;
• authentication, authorization, tenant-isolation, and session-brokering logic.

Out of scope

• Third-party services we use (Stripe, SendGrid, Twilio, hosting) — report those to the provider;
• Customer-operated targets and networks you do not own or have explicit permission to test;
• Findings requiring physical access, stolen credentials, or a rooted/jailbroken device;
• Social engineering of our staff, customers, or vendors.

04Rules of engagement

Good-faith research means:

• Only test accounts and data that belong to you — create your own trial organization;
• Access only the minimum data necessary to demonstrate a vulnerability, and stop once impact is proven;
• If you encounter personal data, customer credentials, or other sensitive information, stop immediately and report it — do not save, copy, transfer, or disclose it;
• Use your own test targets/connectors; never pivot into systems you do not own;
• Keep details confidential until we confirm remediation or agree on a disclosure timeline.

05What not to do

• No denial-of-service, load testing, or resource-exhaustion attacks;
• No spam, social engineering, or phishing of users, staff, or vendors;
• No accessing, modifying, or destroying data that is not yours;
• No physical attacks against offices or data centres;
• No automated scanning at a rate that degrades the Service for others;
• No use of a finding to access other tenants' data beyond a minimal, non-destructive proof of concept.

06How to report

Email [email protected]. Our machine-readable policy is published at /.well-known/security.txt per RFC 9116. If you wish to encrypt your report, request our PGP key in your first message. Please send one issue per report.

07What to include

• A clear description of the vulnerability and its security impact;
• Step-by-step reproduction, including any required accounts, requests, or payloads;
• Proof-of-concept code or screenshots, kept minimal and non-destructive;
• The affected URL, endpoint, or component and the time of testing;
• How you would like to be credited (or whether you prefer to remain anonymous).

08Our response

Our target timelines (best effort; we will keep you updated):

09Recognition

We do not currently run a paid bug-bounty program, but we are grateful for responsible reports. With your permission we will credit you in our security acknowledgements once an issue is resolved. If we launch a bounty in the future, the details will appear here.

10Commonly out-of-scope findings

• Missing security headers without a demonstrated exploit;
• Reports from automated scanners without a working proof of concept;
• Clickjacking on pages with no sensitive actions;
• Self-XSS, or issues requiring an already-compromised browser/device;
• Email spoofing of domains without a demonstrated impact;
• Best-practice suggestions without security impact.

11Legal

This policy does not grant permission to act in ways that are inconsistent with the law or that would cause us to be in breach of our obligations. Activity outside this policy, or against systems not in scope, is not authorized. We may update this policy at any time; the version that applies is the one published when you conducted your research.