Security Policy

We build a security product. Not having a public security policy would be a bit of an embarrassment. This page exists so that anyone who finds a vulnerability in safetodeploy.dev knows exactly how to tell us about it, what we’ll do when you do, and — most importantly — that you won’t catch a lawsuit for doing the right thing.

If you’re in a hurry: email security@safetodeploy.dev with what you found and how to reproduce it. A human will read it within three business days. The rest of this page is the long form.

1. Scope

The following are in scope for this policy:

• safetodeploy.dev and all of its subdomains
• Our public GitHub repositories, where such repositories exist
• DNS, email, and edge-infrastructure configuration of the domain

The SafeToDeploy application itself is not yet live. When the product launches, this document will be updated to extend scope to app.safetodeploy.dev and the scanning pipeline. Until then, this policy covers the marketing surface only.

2. Out of Scope

The following reports are typically not accepted. We’re not trying to dismiss your work — we just want to spend our triage time where it has the most impact.

• Automated scanner output without a demonstrated exploit path or real-world impact.
• Denial-of-service attacks, volumetric floods, or anything that degrades service for other visitors.
• Social engineering of our team, customers, vendors, or family members.
• Physical attacks against our offices, homes, or hardware.
• Missing or misconfigured security headers (CSP, HSTS, etc.) without a demonstrated exploitation path.
• Self-XSS, clickjacking on static pages without sensitive actions, and tab-nabbing.
• Rate-limiting reports on the waitlist form without a proof-of-concept showing real abuse.
• SPF, DKIM, DMARC, or BIMI records that are imperfect but not actively exploitable for spoofing.
• Content injection in forms without a working XSS or stored-impact payload.
• Vulnerabilities in third-party services we depend on (Cloudflare, Google Analytics, Loops, etc.) — please report those directly to the vendor.

3. Safe Harbor

DineshKP Ventures (OPC) Private Limited will not pursue civil or criminal action, and will not report you to law enforcement, for security research activities that are conducted in good faith and in accordance with this policy. We consider such research to be authorized under the Computer Fraud and Abuse Act, the Information Technology Act, 2000, and equivalent computer-access laws in other jurisdictions, and we waive any related restrictions in our Terms of Service that would otherwise prohibit the research.

For your research to be covered by this safe harbor, you agree to:

• Make a good-faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services.
• Only interact with accounts you own or have explicit permission to access.
• Stop testing immediately and notify us if you encounter any data belonging to a third party, including personally identifiable information, authentication credentials, or proprietary data.
• Not exfiltrate data beyond the minimum required to demonstrate the vulnerability.
• Give us a reasonable opportunity to resolve the issue before disclosing it publicly (see Coordinated Disclosure below).
• Not engage in extortion, or condition the disclosure of a vulnerability on payment.

If at any point you’re unsure whether a specific piece of research is covered by this policy, email us first at security@safetodeploy.dev and we’ll work it out together.

4. How to Report

Send an email to security@safetodeploy.dev containing as much of the following as you can reasonably provide:

• A clear description of the issue and its potential impact.
• Step-by-step reproduction instructions, including any required payloads.
• The affected URL, endpoint, or component.
• Your name or handle and, optionally, how you’d like to be credited in our hall of fame.
• Any supporting material: screenshots, HTTP request/response captures, short video clips.

If your report contains sensitive material — for example, a working credential, a token that should not be in plaintext, or customer data you came across by accident — email us first and we’ll arrange an encrypted channel before you send the details.

5. What to Expect From Us

We’re a small team, so we’d rather promise realistic timelines and meet them than publish aggressive SLAs and quietly miss them.

• Acknowledgement of your report within 3 business days.
• Initial triage and a first assessment of severity within 7 business days.
• Status updates at least every 14 days until the issue is resolved or formally closed.
• A named human on our side handling the thread — no ticket-number black holes.
• Credit in our hall of fame, if you’d like it, once the fix is live.

6. Coordinated Disclosure

We follow a coordinated disclosure model. Our default window is 90 days from the date we acknowledge your report, consistent with the norms set by Google Project Zero and most of the industry. We may ask for an extension if a fix is genuinely complex, and we’ll ask plainly with an explanation — not as a stalling tactic.

Once a fix is shipped, you’re welcome to write about your findings. We’ll happily coordinate on publication timing, link to your writeup from our release notes, and — with your permission — credit you by name.

7. Bug Bounty

We don’t currently run a paid bug bounty program. We’re pre-launch and bootstrapped, and we’d rather be honest about that than list a table of rewards we can’t back. What we can offer researchers who find meaningful issues:

• Public credit on this page and in our release notes.
• A written thank-you from a human who actually read your report.
• An open door the next time you want to poke at something we’ve built.

When we can afford to pay for research, we will. This page will be the first place that changes.

8. Encrypted Communication

We don’t currently publish a PGP key. If you need to send sensitive material encrypted end-to-end, email us first and we’ll generate a keypair and share the public key before you send anything confidential.

9. Hall of Fame

Researchers who have responsibly disclosed issues to us, in chronological order:

Nobody yet — be the first

Contact

Vulnerability reports: security@safetodeploy.dev

For anything that isn’t a security issue, please use hello@safetodeploy.dev instead — it keeps our triage queue focused.

See also: our Privacy Policy, Terms of Service, and the machine-readable security.txt.