Security

01Our Security Philosophy

We follow a defence-in-depth security model: multiple independent layers of protection so that if any single control fails, others continue to protect the system. Security reviews happen at every stage of development — not just before deployment.

Our engineering team applies the OWASP Top 10, CWE/SANS Top 25, and relevant NIST guidelines as baselines for all software we build. For regulated industries (healthcare, finance, government), we additionally apply sector-specific frameworks including HIPAA Technical Safeguards, PCI DSS, and ISO 27001 controls.

02Infrastructure Security

Our internal systems and client-facing infrastructure are protected by the following controls:

• All data in transit is encrypted using TLS 1.3. TLS 1.0 and 1.1 are explicitly disabled across all endpoints.
• All sensitive data at rest is encrypted using AES-256. Database backups are encrypted before being written to storage.
• Access to production systems follows the principle of least privilege. Every engineer has a unique, named account. Shared credentials are prohibited.
• Multi-factor authentication (TOTP or hardware security keys) is mandatory for all systems that access production environments or client data.
• Production systems are hosted on AWS with VPC isolation, private subnets, security groups, and AWS WAF in front of all public-facing services.
• Secrets (API keys, credentials, certificates) are managed via AWS Secrets Manager or HashiCorp Vault — never stored in code repositories or environment files.
• All infrastructure changes go through a peer-reviewed pull request process. Terraform is used for infrastructure-as-code with state stored securely in S3 with versioning enabled.

03Application Security

Security is built into our software development lifecycle (SDLC) at every stage:

• Threat modelling is performed during the design phase of every new feature or system. We use the STRIDE model to identify and mitigate threats before they are built.
• Static Application Security Testing (SAST) is integrated into our CI/CD pipeline using Semgrep and CodeQL. Builds with critical security findings are blocked from merging.
• Dependency vulnerability scanning runs automatically on every build using Dependabot and Snyk. Critical CVEs in dependencies trigger immediate patch cycles.
• Every code change goes through a mandatory peer review by at least one senior engineer with security awareness training.
• SQL injection, XSS, CSRF, SSRF, and insecure deserialization protections are implemented and tested as part of our standard coding practices.
• All authentication implementations use industry-standard protocols (OAuth 2.0, OpenID Connect, SAML 2.0) — we do not implement custom authentication schemes.
• Session tokens use cryptographically secure random generation with appropriate entropy. Tokens are invalidated server-side on logout.

04Security Testing

We conduct multiple types of security testing to validate our defences:

• Automated DAST (Dynamic Application Security Testing) — run against staging environments before every major release using OWASP ZAP.
• Annual penetration testing — conducted by an independent third-party security firm using black-box and grey-box methodologies against our internal systems.
• Client project security audits — offered as a deliverable for applicable project types (SaaS platforms, APIs, authentication systems), performed before go-live.
• Continuous vulnerability scanning — all production infrastructure is scanned daily using AWS Inspector and custom Nuclei templates.
• Secret scanning — GitHub Advanced Security secret scanning is enabled across all repositories to detect accidentally committed credentials.

05Access Control and Authentication

We apply strict access control policies across all systems:

• Zero standing access to production — engineers must request and receive time-limited, audited access to production environments for approved tasks.
• All access is logged and monitored. Access logs are retained for 12 months and reviewed periodically for anomalies.
• Client project credentials are stored in dedicated, isolated credential vaults per client. No cross-client credential access is possible by design.
• Offboarding procedures include immediate deprovisioning of all access within 1 hour of an employee's last working day.
• Annual access reviews are conducted to ensure role assignments remain appropriate.

06Incident Response

We maintain a documented incident response plan that covers detection, containment, investigation, remediation, and communication:

1. 1Detection — automated alerts from our SIEM (Security Information and Event Management) system, monitoring for anomalous access patterns, error spikes, and known attack signatures.
2. 2Triage and classification — incidents are classified by severity (P0–P3) within 15 minutes of detection. P0 incidents (active breach or data exposure) trigger immediate escalation.
3. 3Containment — affected systems are isolated within minutes of a confirmed incident to limit blast radius.
4. 4Investigation — forensic analysis to determine root cause, scope of impact, and data affected.
5. 5Notification — affected clients are notified within 72 hours of confirmation of a data breach, in accordance with GDPR Article 33 and applicable laws.
6. 6Remediation — root cause is remediated, controls are strengthened, and a post-incident review is conducted within 5 business days.

07Responsible Disclosure Policy

We welcome security researchers who identify vulnerabilities in our systems or products. If you discover a potential security issue, please report it responsibly:

• Email your findings to security@mirayatechlab.com with the subject line 'Security Vulnerability Report'.
• Include a clear description of the vulnerability, steps to reproduce, potential impact, and any proof-of-concept (without exploiting live data).
• We will acknowledge receipt within 24 hours and provide a triage assessment within 72 hours.
• We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and remediate (typically 90 days).
• We do not pursue legal action against researchers who act in good faith and follow this policy.

We currently do not operate a bug bounty programme, but we do acknowledge researchers in our security hall of fame for responsibly disclosed valid vulnerabilities.

08Client Data Security

When clients share confidential data, credentials, or access to their systems with us for project purposes, we apply the following protections:

• All client credentials are stored in an isolated, encrypted vault accessible only to team members assigned to that client's project.
• Client data is never used for any purpose other than the project deliverable. It is never shared with other clients, used for internal testing beyond the project scope, or retained after project completion without written authorisation.
• SSH keys and API tokens provided for project access are revoked within 24 hours of project completion or upon client request.
• We execute a mutual NDA with every client before they share sensitive information or system access.

09Compliance and Certifications

Our security practices are designed to support the following standards and certifications:

• ISO 27001 — our information security management system follows ISO 27001 principles. Formal certification is in progress.
• SOC 2 Type II — our controls for security, availability, and confidentiality align with SOC 2 Trust Services Criteria.
• GDPR — our data processing practices comply with the EU General Data Protection Regulation.
• HIPAA — for healthcare clients, we sign a Business Associate Agreement (BAA) and apply HIPAA Technical, Physical, and Administrative Safeguards.
• PCI DSS — for projects involving cardholder data, we implement PCI DSS-compliant architectures (typically using Stripe's PCI-certified infrastructure to minimise scope).

10Security for Products We Build

Every software product we deliver includes security as a default, not an add-on:

• Secure defaults out of the box — HTTPS only, HTTP Strict Transport Security (HSTS), Content Security Policy, X-Frame-Options, and other security headers are configured from day one.
• OWASP Top 10 coverage — every web application is tested against the OWASP Top 10 before delivery.
• Authentication and authorisation review — all auth flows are reviewed by a senior engineer, tested for privilege escalation, and validated against OWASP Authentication Cheat Sheet.
• Dependency management — we deliver a project with up-to-date dependencies and a clear process for ongoing dependency updates.
• Security documentation — we provide a security overview document with each delivery, covering architecture, trust boundaries, authentication mechanisms, and recommended security practices for ongoing operation.