Security

Vulnerability Disclosure Policy

We take the security of our systems seriously. This page tells you how to report a vulnerability, what we commit to in return, and what we ask of you while we work together.

1. Scope

The following systems are in scope for our vulnerability disclosure programme:

• sriinfoit.com and its sub-paths (the website you are reading right now).
• Any service exposed under *.sriinfoit.com we directly operate.

The following are out of scope — please do not test these:

• Third-party services we link out to (OEM partner portals, social profiles, etc.).
• Customer infrastructure we manage under engagement contracts — report those through the customer's own disclosure channel, not to us.
• Email-based denial-of-service or any attack that disrupts service for other users.
• Issues that require physical access to our offices or staff devices.

2. How to report

Send an email to security@sriinfoit.com. Please include:

• A clear description of the issue.
• Step-by-step reproduction details (URL, request payload, expected vs. actual behaviour).
• Your assessment of impact and severity.
• Whether you are willing to be credited in our acknowledgements (default: yes, with your handle of choice; we will never publish your contact details).

For sensitive reports, our PGP key is published at /.well-known/security-pgp.asc. Encrypt to that key if you'd prefer.

3. What we commit to

• Acknowledgement within 3 working days of receipt.
• Initial triage response within 5 working days describing whether we have reproduced the issue, our preliminary severity assessment, and an estimated remediation window.
• Status updates at least every two weeks while a report is open.
• No legal action against good-faith researchers who follow this policy. We treat your work as authorised testing under §43 IT Act, 2000.
• Public credit in our acknowledgements once the issue is resolved, if you have asked for it.

4. What we ask of you

• Avoid actions that affect other users — no automated scanning at high rates, no spam, no destructive testing.
• Do not access, modify, or download data that does not belong to you. If a vulnerability lets you reach data, prove the access is possible (e.g. by reading a single record metadata) and stop — do not exfiltrate.
• Do not use social engineering against our staff.
• Give us a reasonable time to remediate before any public disclosure. The default coordinated-disclosure window is 90 days from the date we acknowledge your report. We will work with you to extend this only if remediation requires upstream vendor coordination, and we will tell you if we need that.
• Comply with all applicable Indian law while testing.

5. Severity guidance

We use roughly the following internal severity buckets to set remediation timelines. These are not contractual; they help us prioritise.

6. Out-of-scope issue types

The following issues are typically not eligible. Reporting them is fine; we just may not act on them as security issues:

• Reports based purely on automated scanner output without an exploit narrative.
• Missing security headers that don't lead to a demonstrable exploit (we still want to know — just understand the priority will be low).
• Self-XSS that requires a victim to paste attacker-supplied input into the console.
• Best-practice complaints that are not vulnerabilities (e.g. "you should use a different framework").
• Email-spoofing reports about domains that don't have SPF/DKIM/DMARC published yet (we are working on these — check back).
• Denial-of-service that requires sending unusual traffic volumes.

7. Acknowledgements

Researchers who have reported valid issues to us will be listed here, with their consent, after their issues are resolved. (No issues to acknowledge yet at the time of v7.1 launch — if you're the first, you'll get the top spot.)

8. Contact