Vulnerability Disclosure Policy

1. Purpose

This Vulnerability Disclosure Policy (VDP) explains how to report a security vulnerability in CyberDudeBivash's products and infrastructure, what happens after you report one, and how we recognize the researchers who do. It exists so that good-faith security research helps make the platform safer without legal risk to the researcher, and so every report is handled consistently, fairly, and quickly.

2. Scope

The following assets are in scope for security testing under this policy:

• https://cyberdudebivash.in and all subdomains
• https://intel.cyberdudebivash.com and all subdomains
• https://tools.cyberdudebivash.com
• Public REST APIs served under /api/* on the domains above

If you're not sure whether an asset is in scope, ask first at [email protected] before testing it.

3. Authorization

Testing that stays within the Scope (§2) and follows the Rules of Engagement (§6) and Testing Guidelines (§7) of this policy is authorized by CyberDudeBivash. We will treat it as authorized access for the purposes of India's Information Technology Act, 2000 and equivalent computer-misuse laws elsewhere.

Testing outside this scope, or that breaks these rules, is not authorized by this policy and may expose you to legal risk we cannot shield you from — see the Legal Disclaimer (§13).

4. Safe Harbor

5. Good Faith

We ask researchers to act in good faith: test only what you need to prove an issue exists, avoid privacy violations, avoid degrading the service for other users, and give us a reasonable opportunity to fix an issue before discussing it publicly. Good faith is what makes Safe Harbor (§4) apply — bad-faith or malicious activity (data theft, extortion, deliberate service disruption) is never covered by this policy, regardless of scope.

6. Rules of Engagement

• Only test against your own account/test data — never access, modify, or delete another user's data.
• Stop and report immediately if you unintentionally access data that isn't yours; do not view or exfiltrate more than the minimum needed to prove the issue.
• Make a good-faith effort to avoid degrading service availability or data integrity for other users.
• Do not use an exploit to pivot further than necessary to demonstrate impact (one proof-of-concept run, not repeated exploitation).
• Do not publicly disclose a vulnerability before we've shipped a fix and we've agreed together on disclosure.
• Report through [email protected] only — not social media, public issue trackers, or third parties.

7. Testing Guidelines

• Manual testing against your own account/test data is welcome at any time.
• Automated scanning is permitted at a reasonable, non-disruptive rate against in-scope hosts only — stop if you notice service impact.
• No destructive testing: no data-deletion payloads, no denial-of-service payloads, no testing that could degrade production for other customers.
• CVSS 3.1 is our reference standard for describing impact in your report — it helps us triage faster, though it isn't required.

8. Out-of-Scope Targets & Findings

• Denial-of-service, load, or stress testing of any kind
• Social engineering or phishing of CyberDudeBivash staff, customers, or contractors
• Physical security attacks against offices, data centers, or hardware
• Vulnerabilities in third-party services we depend on (Cloudflare, Razorpay, email/DNS providers, etc.) — please report those directly to the vendor
• Findings that rely solely on automated scanner output with no working proof-of-concept
• Self-XSS that requires the victim to paste attacker-supplied script into their own browser console
• Missing security best-practice headers or flags with no demonstrated, exploitable security impact
• Reports affecting only out-of-date browsers or plugins the visitor has chosen not to update

9. Responsible Disclosure Process

1. Report. Email [email protected] with the details described on the Security Overview page.
2. Acknowledge. We confirm receipt within 24 hours and open an internal tracking reference.
3. Triage. We reproduce the issue and assign a severity (§11).
4. Remediate. We fix the issue against the severity-based timeline in §10, and re-test.
5. Recognize. We add you to the Hall of Fame and issue a Certificate of Appreciation, per §12.
6. Coordinate disclosure. Any public write-up — by you or by us — waits until the fix is deployed and we've agreed together on timing and content.

10. Timeline

These are targets, not contractual guarantees — complex findings can take longer, and we'll tell you if one does. Our first publicly reported vulnerability (Medium, HTML Injection) was acknowledged, fixed, tested, and deployed inside 24 hours — see the Hall of Fame.

11. Severity Handling

We classify reported vulnerabilities using CVSS 3.1. Severity drives the fix-target timeline in §10 and how we prioritize remediation across the team. If you include a CVSS vector string in your report, we'll confirm or adjust it during triage and tell you why if it changes.

12. Recognition Policy

Every valid, in-scope report resolved under this policy earns:

• A listing on the Security Researcher Hall of Fame (unless you ask to stay anonymous)
• A numbered, verifiable Certificate of Appreciation
• A genuine LinkedIn recommendation from our security team, on request
• Public acknowledgment in our release notes or security advisories, where relevant

13. Future Bug Bounty Roadmap

As the platform grows revenue, we intend to explore introducing a paid bug bounty program. This is a direction of intent, not a commitment: we are not announcing a launch date, a budget, or reward tiers here, because we don't have real numbers to stand behind yet — and we'd rather say nothing than publish figures we can't honor.

The architecture behind this program (Hall of Fame, recognition tiers, certificates, and this policy) is deliberately built so a future paid tier can be added later without a redesign — recognition, certificates, and rewards are already kept as separate concerns internally. When there's real news here, it will be published on this page and announced via the Hall of Fame contact channel for researchers who've asked to be kept informed.

14. Legal Disclaimer

15. Privacy

When you submit a report, we collect what you choose to send us — typically your name or handle, an email address, and the technical details of your finding. We use it only to triage and fix the issue, communicate with you about it, and — if you agree — credit you publicly. We do not sell or share it with third parties, and we do not use it for marketing. You can ask to be credited anonymously, or not credited at all, at any time. Full detail on data handling, retention, and your rights is in our Privacy Policy.