Security & Data Privacy

Security Operations & Vulnerability Reporting

How we secure servers, run penetration tests, isolate tenant datastores, and handle vulnerability disclosures.

We secure every layer of our platform, from host firewalls to token validation protocols. This document details our active security operations controls and explains how to report security vulnerabilities to our engineering team.

1. Core Security Operations Controls

Our engineering team operates under strict security guidelines to protect production databases:

  • Tenant Data Isolation: EasyDev uses a logical multi-tenant architecture. Every database query enforces a tenant ID filter (x-tenant-id). Downstream workers cannot access database rows belonging to another tenant.
  • Vulnerability Scanning: We run automated dependency scanning (Github Dependabot) on all repositories to detect and patch CVEs in dependencies immediately.
  • Encrypted Secrets Management: All database passwords, OAuth client secrets, and third-party API keys are stored in encrypted vaults (AWS Secrets Manager) and injected at runtime.
  • Admin Access (Least Privilege): Production server access is restricted using Multi-Factor Authentication (MFA) and is limited to senior devops administrators.

2. Penetration Testing & Auditing

  • We conduct internal vulnerability assessments monthly.
  • We contract external, CREST-accredited security firms to run third-party black-box penetration tests on our platform web APIs, IAM services, and dashboard portals annually.
  • Pentest summaries are available for corporate Pro and Enterprise clients upon signing a mutual NDA.

3. Vulnerability Disclosure Policy (VDP)

If you discover a security vulnerability in our portals or apps:

  1. Responsible Disclosure: Report the issue directly to our security engineering team by emailing security@easydev.in with the subject line VULNERABILITY DISCLOSURE.
  2. Required Information: Provide a detailed description of the vulnerability, including step-by-step instructions to reproduce it, potential impact, and a proof of concept (PoC) if applicable.
  3. Do Not Disclose Publicly: Do not publish, share, or disclose the vulnerability details to any third party until we have investigated and deployed a fix.
  4. No Safe Harbor for Malicious Activities: We welcome reports from white-hat security researchers. We agree not to take legal action against researchers who comply with this disclosure policy.

4. Response SLA for Security Reports

  • Triage: We acknowledge receipt of security reports within 48 hours and provide regular updates as we investigate.
  • Remediation: High-severity vulnerabilities are prioritized and treated as critical events once verified.
Was this article helpful?Suggest edits on GitHub

Can't find an answer?

Our engineers are ready to help. Submit a message or chat with us on WhatsApp for real-time support.