Vulnerability Disclosure Policy

If you have found a flaw in something we built, we want to hear about it. This page tells you what is in scope, how to report, and what we promise not to do to you.

1. Safe harbour

This authorisation covers activity that stays within section 3 and complies with section 4. If you are unsure whether something is in scope, ask us at security@dectify.in before you do it. We would much rather answer a question than argue about it afterwards.

Safe harbour does not extend to accessing, downloading, modifying or retaining data belonging to another person beyond the minimum needed to demonstrate the flaw, and it does not authorise anything against a customer's deployment without that customer's own permission.

2. How to report

Email security@dectify.in. Encrypt with our PGP key at [key URL, fingerprint] if the report is sensitive. Reports may be submitted anonymously.

Include: what you found, where, the steps to reproduce it, what an attacker could achieve, and any proof-of-concept. Screenshots and a short video help. Write in English. One issue per report.

We accept reports in any format — a well-written email beats an unfilled template. Do not report through social media, a support ticket, or a sales contact; those routes are not monitored for this and will slow you down.

3. Scope

3.1 In scope

• dectify.in and its subdomains.
• The DECTIFY HUB web application and its API.
• DECTIFY mobile applications.
• DECTIFY hardware and firmware, where you own or are authorised to test the device.
• Our published SDKs and sample code.

3.2 Out of scope

• Customer deployments and customer data. A live camera system belongs to a customer. Do not test it without that customer's written permission — our safe harbour cannot give you theirs.
• Third-party services we use but do not control. Report those to their owner; tell us too and we will coordinate.
• Social engineering of our staff, customers or suppliers, including phishing and pretexting.
• Physical attacks on our offices or on installed hardware you do not own.
• Denial of service, load testing, and resource exhaustion. Do not test availability.
• Automated scanning that generates significant traffic.

3.3 Usually not accepted

Missing security headers with no demonstrated impact; SPF, DKIM or DMARC configuration without a working spoof; certificate or TLS configuration warnings without exploitability; version disclosure alone; clickjacking on a page with no sensitive action; self-XSS; rate limiting on non-authentication endpoints; outdated browser issues; theoretical CSRF on a form with no state change; reports produced entirely by a scanner with no validation.

If you can demonstrate real impact from any of these, we will look at it. Impact is what decides, not category.

4. Rules

• Do not access, modify, delete or retain data belonging to anyone else. If you encounter personal data, stop, do not save it, and tell us immediately.
• Use only your own test accounts. Ask us for one if you need it.
• Do not degrade service for anyone.
• Do not pivot deeper once you have proven access. Proof of the vulnerability is enough; proof of the whole network is not.
• Do not install a backdoor, a persistence mechanism, or leave anything behind.
• Give us reasonable time to fix before public disclosure — see section 6.
• Do not extort. A report conditioned on payment is not a report.

5. What we commit to

We will tell you when it is fixed, and we will tell you honestly if we decide not to fix it and why. We will not dispute a valid finding to avoid acknowledging it, and we will not downgrade a severity to shorten our own deadline.

6. Coordinated disclosure

We support public disclosure and we do not ask for indefinite silence.

• Please wait until the fix is deployed, or 90 days from your report, whichever comes first.
• Where a fix requires customers to update hardware in the field, we may ask for longer, and we will explain why and give a date. You are free to decline.
• We will coordinate timing with you and are happy to publish simultaneously.
• Where a flaw is being actively exploited, we may need to move faster than the deadline, and we will tell you.
• Please do not include customer data, customer names or deployment locations in anything you publish.

7. Recognition

With your consent we credit you by name or handle in our security acknowledgements at [acknowledgements URL] and in the release notes for the fix. You may stay anonymous.

DECTIFY does not currently operate a paid bug bounty. We say so plainly rather than implying one. Where a report is exceptional we may offer a discretionary reward, and if a programme launches it will be announced here.

8. If a report reveals a breach

Where your report shows that data was actually accessed by someone, our own obligations engage immediately: six hours to CERT-In under the Directions of 28 April 2022, seventy-two hours to affected customers, and notification to the Data Protection Board of India and to the OAIC under the Notifiable Data Breaches scheme as those regimes require.

We will keep you informed, we will not name you to a regulator without your consent unless compelled, and your having found it does not make you responsible for it.

9. Reporting something that is not a vulnerability

• Misuse of DECTIFY systems by a customer — abuse@dectify.in. See the Acceptable Use Policy.
• A wrong or harmful model output — responsible-ai@dectify.in.
• A privacy concern — privacy@dectify.in.
• An open source licensing concern — opensource@dectify.in.

All of these accept anonymous reports, and none of them will be used to identify you to anyone.