Linxus Infotech
Sign in Start free scan
Legal

Security & Data Protection Statement

Last updated: June 11, 2026 · Version 3.0 · Applies to linxusinfotech.com and infrasync.app

This Security & Data Protection Statement describes the technical and organizational measures we implement to protect your data.

1. Executive summary

This Security & Data Protection Statement describes the technical and organizational measures Linxus Infotech implements to protect:

  • Cloud-provider credentials you connect (currently AWS Access Keys).
  • Generated Terraform code and scan output.
  • Personal data and account information.

This document describes current practices, not aspirational ones. Items on our roadmap are explicitly labelled as such.

Company information:
Linxus Infotech Private Limited
G.NO.215, Dongargaon (Shev), Phulambri, Aurangabad, Maharashtra 431111, India

Security contact: security@linxusinfotech.com · +91 8828 757 008

2. Data we protect

2.1 Cloud-provider credentials

The most sensitive data you entrust to us is your AWS credentials, specifically the AWS Access Key ID and AWS Secret Access Key for accounts you choose to connect. The Secret Access Key is encrypted at rest in our database as described in section 4. We recommend you provide credentials scoped to read-only permissions (e.g. AWS managed policy ReadOnlyAccess or a narrower equivalent).

2.2 Generated Terraform artifacts & scan output

Generated .tf files and resource metadata returned by scans. Files are uploaded to Amazon S3 in the ap-south-1 (Mumbai) region with AWS-managed server-side encryption; metadata is stored in our application database.

2.3 Personal & account data

Name, email, phone (optional), company name (optional), billing address, optional GSTIN and place of supply for invoicing, invoice history, support correspondence, and audit-log entries describing actions taken in your organization.

3. Security architecture

3.1 Hosting and region

The InfraSync platform runs on Amazon Web Services in the ap-south-1 (Mumbai) region. The platform consists of three independently deployed services:

  • a Next.js web application,
  • a Node.js / Express REST API backend,
  • a Go-based scanner worker that performs cloud enumeration and generates Terraform code.

Backend and frontend services run on EC2 instances managed by PM2. The scanner runs as a containerised worker. Scan jobs are dispatched asynchronously through AWS SQS; real-time scan progress is fanned out to the web UI through Amazon ElastiCache (Redis) and Server-Sent Events.

3.2 Network security

  • The application is reachable only over HTTPS on the public web tier.
  • The backend application database is reachable only from application servers; it is not exposed to the public internet.
  • Production EC2 instances are administered through controlled SSH access; access is restricted to authorised operators.

4. Encryption

4.1 Encryption at rest

AWS Secret Access Keys (sensitive credential field):

  • Algorithm: AES-256-GCM (authenticated encryption).
  • Initialization vector: 96-bit, randomly generated per record.
  • Authentication tag stored alongside the ciphertext.
  • The encryption key is a single application-wide secret held in the backend service's environment configuration. We do not currently maintain per-customer keys or scheduled key rotation. Both are on our hardening roadmap.

Other fields:

  • The AWS Access Key ID and the GitHub App access token are stored unencrypted at the application layer and rely on database-level access controls.
  • Passwords are stored as bcrypt hashes (current cost factor: 10 salt rounds). Plaintext passwords are never stored or logged.

S3 (generated Terraform code):

  • Uploads use AWS-managed server-side encryption (SSE-S3 by default; SSE-KMS supported for customer-supplied Terraform state backends).

4.2 Encryption in transit

  • All client → server traffic uses TLS (minimum TLS 1.2).
  • Connections from our backend to AWS APIs, GitHub, and Razorpay use those services' standard HTTPS endpoints.
  • HSTS is enabled on the public web tier.

5. Access controls

5.1 User authentication

  • Password authentication using bcrypt for password hashing.
  • Session management via the NextAuth.js library using a JSON Web Token (JWT) session strategy. Each token carries a token version so we can invalidate all of a user's sessions if a compromise is suspected.
  • Two-factor authentication for end users is currently not implemented. It is on our roadmap.

5.2 Role-based access control (RBAC)

Within an organization, users hold one of four roles, each with a different scope of permissions:

  • admin — full control of the organization, including team and billing.
  • maintainer — manage credentials, integrations, schedules, and scans; no billing changes.
  • writer — initiate scans, view and download generated code.
  • viewer — read-only access to scans, drift reports, and audit logs.

5.3 Operational access

  • Operational engineers may have administrative access to production hosts and the application database in order to operate the Service.
  • Such access is restricted to authorised personnel, requires SSH key authentication (no password SSH), and is logged.
  • We do not claim that operational personnel cannot decrypt customer credentials — the application key needed to do so is present in the backend service environment.
  • Sensitive end-user actions are recorded in our application audit log and retained for 90 days by default.

5.4 Least privilege for cloud calls

  • Scans use only read-only AWS APIs needed for resource discovery.
  • We do not perform write operations against your AWS account.
  • You are responsible for the IAM policy attached to the credentials you provide; we recommend the narrowest read-only set sufficient for your scan scope.

6. Vulnerability management

  • We patch operating-system, runtime, and dependency vulnerabilities on a routine cadence and out-of-band for critical issues.
  • We use automated dependency scanning on our source repositories for the frontend, backend, and scanner.
  • We invite responsible disclosure of vulnerabilities by independent researchers (see section 13).
  • Formal third-party penetration testing is on our roadmap.

7. Incident response

7.1 Process

  1. Detect: through monitoring, alerting, and user reports.
  2. Contain: isolate affected systems, rotate compromised secrets, and revoke affected sessions and tokens.
  3. Eradicate: remove the root cause and patch affected systems.
  4. Recover: restore service to normal operation and verify integrity.
  5. Notify: notify affected users and authorities as required by law (see section 7.2).
  6. Learn: conduct a written post-incident review and update controls.

7.2 Breach notification

Where a personal-data breach is reasonably likely to result in a risk to affected users, we will notify them and the appropriate authorities within timelines required by applicable Indian law, including the Digital Personal Data Protection Act, 2023 and CERT-In directions under the Information Technology Act, 2000. Notifications will describe the nature of the incident, data affected, measures taken, and recommended steps for affected users.

8. Business continuity & backups

  • Application databases are backed up on a regular schedule using AWS-native snapshot mechanisms.
  • Generated Terraform artifacts stored in S3 benefit from S3's native durability (designed for 99.999999999% durability).
  • We do not currently operate a hot disaster-recovery region outside India.
  • Recovery point and recovery time objectives are being formalised; targets will be documented as we mature the practice.

9. Compliance & data residency

  • Customer data is stored in AWS's ap-south-1 (Mumbai) region.
  • Our processing complies with the Information Technology Act, 2000 and is being aligned to the Digital Personal Data Protection Act, 2023 as it comes into force.
  • We are not currently SOC 2 or ISO 27001 certified. These certifications are on our roadmap; references to them in any prior marketing should be disregarded.
  • Sub-processors are listed in section 5 of the Privacy Policy and in section 12 below.

10. Personnel

  • Access to production systems is limited to personnel with a need to know and is provisioned through individual accounts.
  • Personnel are bound by confidentiality obligations.
  • Onboarding includes briefings on handling customer data, credential hygiene, and reporting suspected incidents.

11. Customer security responsibilities

You play a critical role in keeping your account safe. We recommend:

  • Provide IAM credentials with the narrowest read-only scope sufficient for your scans (e.g. AWS managed policy ReadOnlyAccess or narrower).
  • Rotate the AWS keys you provide to InfraSync periodically and disconnect any cloud account you no longer wish us to scan.
  • Use a strong, unique password for your InfraSync account.
  • Assign the lowest role sufficient for each organization member.
  • Review your audit log periodically for unexpected activity.
  • Report suspected account compromise immediately to security@linxusinfotech.com.

12. Sub-processors

The Service is operated using the following sub-processors:

  • Amazon Web Services, Inc. — compute (EC2), object storage (S3), message queue (SQS), in-memory cache (ElastiCache for Redis), and email (SES), all in the ap-south-1 region.
  • Razorpay Software Private Limited — payments and recurring-billing mandates.
  • GitHub, Inc. — only if you choose to install the InfraSync GitHub App and push code to a GitHub repository.
  • SMTP email provider (fallback) — used only if AWS SES is unavailable.

13. Responsible disclosure

If you believe you have found a security vulnerability, please report it to security@linxusinfotech.com with the subject line "Security Vulnerability Report". Please:

  • Give us reasonable time to investigate and remediate before any public disclosure.
  • Avoid privacy violations, destruction of data, or interruption of service in the course of your research.
  • Only test against your own account or accounts you have explicit permission to test.

We do not currently operate a paid bug-bounty program but are happy to acknowledge researchers who responsibly disclose valid issues.

14. Changes to this statement

We may update this statement to reflect changes in our practices or for legal, operational, or regulatory reasons. The updated version will be posted with a revised "Last Updated" date. For material changes, we will notify customers by email and an in-product notice.