Responsible Disclosure

Table of Contents

1. Overview & Purpose
2. Scope & Coverage
3. Definitions
4. Participation Eligibility
5. Ethical Conduct Requirements
6. Reporting Instructions (Yes/No/How)
7. Triage & Remediation Workflow
8. Service-Level Aims (SLA)
9. Recognition & Rewards
10. Confidentiality & Non-Disclosure
11. Safe Harbor (Authorized Testing)
12. What Is Out of Scope
13. Evidence Handling & Data Protection
14. No Warranties, Liability & Indemnity
15. Changes, Suspension & Termination
16. Governing Law & Dispute Resolution
17. Contact Points
18. Annexure A – In-Scope Assets & Versions
19. Annexure B – Out-of-Scope Patterns & Examples
20. Annexure C – Escalation Matrix & Timelines
21. Annexure D – Researcher Acknowledgment (Template)
22. Annexure E – Sample Report Template & Checklists
23. Annexure F – Definitions (Extended Glossary)
24. Annexure G – Frequently Asked Questions

1) Overview & Purpose

Nest welcomes good-faith research that helps us protect our customers and systems. This Policy explains what testing is allowed, what is not allowed, how to report, how we respond, and how we acknowledge your contribution. It is designed to be explicit: yes for good-faith, scoped testing and private reporting; no for disruption, data access, or public disclosure before a fix.

• Yes: Research on assets listed in Annexure A, using your own accounts and minimal data, with care.
• No: Accessing other people’s data, breaking availability, spamming, social engineering, or physical attacks.
• How: Reproduce on non-destructive basis, capture evidence safely, report privately to security@nestapp.in.

2) Scope & Coverage

This Policy covers the Nest App, website, backend APIs, and other production systems explicitly listed in Annexure A. Non-production systems are excluded unless explicitly authorized in writing.

3) Definitions

Term	Meaning
Researcher	An individual or organization submitting a vulnerability report in good faith.
Vulnerability	A flaw that can be abused to compromise confidentiality, integrity, or availability.
Submission	The report sent to Nest containing details to reproduce, evidence, and impact.
Safe Harbor	Assurance that good-faith, compliant testing will not be pursued legally by Nest.
Exploit	The act or code that weaponizes a vulnerability to cause harm.
Triage	Validation, severity rating, and prioritization of the submitted vulnerability.
P0–P4	Severity levels from Critical (P0) to Informational (P4); see Annexure E.

For an expanded glossary, see Annexure F.

4) Participation Eligibility

• Age: 18+ (Yes). Under 18 (No) unless represented by a guardian per law.
• Capacity: Act individually or with employer consent (Yes). Impersonation (No).
• Jurisdictions: Participation must not violate applicable sanctions/export controls.
• Conflicts: Employees of direct competitors (No). Vendors of Nest (Only with prior written approval).
• Lawfulness: All research must comply with applicable laws (Yes).

5) Ethical Conduct Requirements

Your research must follow these clear rules:

• No unauthorized data access: Do not view, copy, modify, or delete someone else’s data. If accidental exposure occurs, stop immediately, collect minimal proof (e.g., redacted screenshot), and report.
• No service disruption: No DDoS, resource exhaustion, spam, brute force, or traffic flooding.
• No social engineering: Do not phish, vish, smish, or manipulate Nest staff, vendors, or users.
• Use your own assets: Test with your own accounts/devices; do not use stolen credentials or shared secrets.
• Keep it reversible: Demonstrate impact without causing persistent damage or state changes.
• Stay in scope: Only test assets listed as in-scope (Annexure A).
• Private reporting: Do not disclose publicly until Nest permits in writing.

6) Reporting Instructions (Yes/No/How)

6.1 Yes – Include

• Clear title and description of the issue.
• Exact steps to reproduce (numbered).
• Proof-of-Concept (non-destructive), screenshots, short videos.
• Impact statement (what an attacker could do).
• Scope (affected URL, endpoint, version, platform).

6.2 No – Exclude

• Personal data dumps or secrets. Redact or mask evidence.
• Attack scripts that cause damage or sustain access.
• Public posts before fix/permission.

6.3 How – Sample Subject & Body

Subject: [Nest Disclosure] IDOR on /api/v2/user/profile leads to data exposure (Android 3.12.0)

Hello Nest Security Team,
I found an authorization flaw. Steps:
1) Login with test account (user A).
2) Call GET /api/v2/user/profile?id=123 (user B’s ID) via proxy.
3) Response returns user B’s PII.

Impact: Unauthorized data access for arbitrary users.
Evidence: (Redacted) screenshot + HAR.
Tested on: Android 3.12.0, build 31200.
Requesting confirmation of receipt. I followed Nest policy and did not retain data.

Thanks,
<Researcher Name/Alias>
      

7) Triage & Remediation Workflow

1. Acknowledgment: We confirm receipt and assign a tracking ID.
2. Validation: Security engineers reproduce and confirm severity.
3. Prioritization: Issues are classified P0–P4 with target timelines (Annexure E).
4. Fix Plan: Eng teams implement mitigations and permanent fixes.
5. Verification: Security retests; regression checks occur.
6. Closure: Reporter is informed; disclosure window discussed.
7. Credit: If eligible, recognition is arranged.

8) Service-Level Aims (SLA)

Stage	Aim
Acknowledgment	Within 24 hours (business days).
Initial validation	Within 3–5 business days.
Fix window (P0/P1)	As soon as practicable; target communicated individually.
Fix window (P2–P3)	Scheduled release; timeline communicated.
Fix window (P4)	At Nest’s discretion.

SLAs are targets, not guarantees. Complex issues or third-party dependencies can extend timelines.

9) Recognition & Rewards

• Hall of Fame: Public acknowledgement (name/alias) with your consent.
• Appreciation Letter: On request, after verified fix.
• Discretionary Rewards: Possible for impactful issues. No entitlement is created by this Policy.

10) Confidentiality & Non-Disclosure

Yes: Keep the report private until we approve disclosure in writing.
No: Posting PoCs, screenshots, or data publicly before resolution. If you publish without authorization, you may be excluded from future participation and applicable laws may apply.

11) Safe Harbor (Authorized Testing)

When you comply with this Policy and act in good faith on in-scope assets, Nest will consider your testing as authorized and will not pursue legal action. If a third party questions your activity, we can confirm to them that the activity was covered by this Policy. This Safe Harbor does not extend to actions outside the Policy (e.g., data theft, disruption, fraud).

12) What Is Out of Scope

• Denial-of-Service and brute forcing.
• Social engineering of staff or users.
• Physical attacks against offices, data centers, or devices.
• Best-practice gaps without exploitability (e.g., missing headers) unless combined with impact.
• Vulnerabilities in third-party products not owned by Nest.

See Annexure B for a detailed, non-exhaustive list.

13) Evidence Handling & Data Protection

• Collect minimal evidence; do not retain or share personal data.
• Redact names, emails, phone numbers, and tokens in screenshots.
• Do not create datasets from live systems. No scraping.
• Securely delete data after submission or upon written instruction.

14) No Warranties, Liability & Indemnity

This Policy does not create a contract, partnership, or employment. It does not guarantee rewards, timelines, or any specific outcome. To the maximum extent permitted by law, Nest disclaims liability for any loss arising from your participation. You agree to use caution, comply with law, and indemnify Nest against claims arising from your non-compliance or unlawful acts.

15) Changes, Suspension & Termination

Nest may update, suspend, or terminate this Policy at any time. Continued participation after changes indicates acceptance of the updated Policy. We may exclude a participant for any violation or risk to users/systems.

16) Governing Law & Dispute Resolution

Governing law: India. Parties will first attempt amicable resolution within 60 days. Unresolved disputes will be referred to arbitration under the Arbitration and Conciliation Act, 1996. Seat: Nellore, Andhra Pradesh. Language: English. Subject to arbitration, courts at Nellore have exclusive jurisdiction.

17) Contact Points

• Primary: security@nestapp.in
• Postal: Vrisha Fintech Private Limited, Nellore, Andhra Pradesh, India
• Grievance (Policy queries only): grievance@nestapp.in

Annexure A – In-Scope Assets & Versions

This annexure defines exactly what is covered. If it is not listed here, it is not in scope unless you have written authorization.

Asset	Identifier	Notes
Nest Android App	com.nest.app	Only Google Play production builds. Beta/alpha builds excluded unless explicitly approved.
Nest iOS App	Nest (Bundle ID: tbd)	Only App Store production builds. TestFlight excluded unless explicitly approved.
Public Website	https://www.nestapp.in	Marketing site and authenticated areas under *.nestapp.in.
API Gateway	api.nestapp.in	Public routes used by production apps only.

Accepted Test Accounts

Use self-created accounts. No shared, leaked, or purchased accounts. Do not test with real customer accounts.

Accepted Client Versions

• Latest store versions only (Android/iOS). Older versions may be out of maintenance and out of scope.

Annexure B – Out-of-Scope Patterns & Examples

The following examples are typically out of scope, unless combined with a clear, reproducible, exploitable impact:

B.3 Third-Party Services

Flaws in third-party platforms (cloud providers, CDNs, analytics SDKs, payment gateways) must be reported to those vendors through their programs unless the exploit demonstrably affects Nest systems and is reproducible on our side.

Annexure C – Escalation Matrix & Timelines

Stage	Who	Target Timeline	Notes
Receipt	Security Intake	Within 24h	Ticket created; acknowledgement sent with Tracking ID.
Validation	Security Engineering	3–5 business days	Reproduction, severity, scope confirmation.
Fix Plan	Product & Eng	Asap for P0/P1	Mitigation + fix ETA communicated to reporter.
Verification	Security + QA	On delivery	Patch testing + regression checks.
Closure	Security Intake	Post-verification	Reporter notified; credit process (if applicable).

Escalation Contacts

• L1: Security Intake – security@nestapp.in
• L2: Security Lead (via L1)
• L3: CISO/Head of Security (via L2)
• Policy Grievance: grievance@nestapp.in

Annexure D – Researcher Acknowledgment (Template)

Use this if a signed acknowledgment is required (email acceptance is typically sufficient).

Title: Researcher Acknowledgment – Nest Responsible Disclosure

I, <Full Name / Alias>, confirm that:
1) I have read and understood the Nest Responsible Vulnerability Disclosure Policy.
2) I will test only in-scope assets and follow ethical rules described.
3) I will not access or retain personal data beyond minimal redacted evidence.
4) I will report privately to security@nestapp.in and await written approval before any disclosure.
5) I understand rewards/recognition are discretionary and not guaranteed.
6) I consent to be credited as <Name/Alias> (Yes/No). If Yes, my preferred link is: <URL>.

Signature:
Date:
      

Annexure E – Sample Report Template & Checklists

E.1 Report Template

Title: <Short vulnerability title>
Asset: <URL/app version/API route>
Severity: <P0–P4>
Category: <IDOR/XSS/SQLi/CSRF/Misconfig/Auth/…>

Summary:
<2–3 lines describing the flaw>

Steps to Reproduce:
1) …
2) …
3) …

Impact:
<What an attacker can achieve>

Evidence:
<Redacted screenshot/short video/HAR>

Test Context:
Device/OS/Browser/Build:
Network (Wi-Fi/Cellular/VPN):
Account type (self-created test):
      

E.2 Severity Hints

Level	Typical Examples
P0 (Critical)	RCE, auth bypass to admin, mass PII exposure, unrestricted money movement.
P1 (High)	Privilege escalation, direct object reference exposing sensitive PII/transactions.
P2 (Medium)	Stored XSS, business logic abuse with meaningful impact.
P3 (Low)	Reflected XSS with constraints, minor info leak with limited value.
P4 (Info)	Missing headers, version info, non-exploitable misconfigs.

E.3 Researcher Checklist

• Is the asset in Annexure A?
• Did I avoid personal data and disruption?
• Are steps reproducible and minimal?
• Is evidence redacted and safe to share?
• Did I send to security@nestapp.in only?

Annexure F – Definitions (Extended Glossary)

• Account Takeover (ATO): Unauthorized control of a user account.
• Broken Access Control: Flaws allowing actions beyond intended permissions.
• Business Logic Abuse: Exploiting flows to gain unfair advantage or bypass checks.
• Cryptographic Weakness: Flaws in key storage, randomization, or protocol use.
• Data Exfiltration: Unauthorized removal of information from systems.
• Deserialization Attack: Abusing insecure object deserialization.
• Insecure Direct Object Reference (IDOR): Accessing others’ objects by manipulating identifiers.
• Least Privilege: Minimal required access to perform a function.
• Man-in-the-Middle (MitM): Intercepting communication between parties.
• Open Redirect: Redirecting to external destinations without validation.
• Privilege Escalation: Gaining higher permissions than authorized.
• Remote Code Execution (RCE): Running arbitrary code on a target system.
• Session Fixation: Forcing a user to use a known session ID.
• SSRF: Server-Side Request Forgery to access internal resources.
• Stored vs Reflected XSS: Persistent vs one-time script injection.

Annexure G – Frequently Asked Questions

G.1 Will you pay a bounty?

Answer: Possibly. Rewards are discretionary, severity-based, and budget-dependent. There is no promise of payment in this Policy.

G.2 Can I disclose after you fix?

Answer: Yes, only after we provide written permission. We may request limited redactions to protect users.

G.3 Can I test with automation?

Answer: Light automation is fine if it does not cause disruption. Heavy scanning, brute forcing, or flooding is not allowed.

G.4 What if I unintentionally access sensitive data?

Answer: Stop, collect minimal redacted proof, delete local copies securely, and report immediately. Do not share the data.

G.5 Do you provide test environments?

Answer: Not by default. Only production assets in Annexure A are covered. If we open a sandbox, we will list it explicitly.