Questions

Our application currently undergoes standard manual QA testing by our internal team, which includes a structured security checklist focused on common vulnerabilities such as broken authentication, input validation (XSS, SQL injection), session management, access control, and secure error handling.

In addition to this, we use Cloudflare to enforce HTTPS, protect against DDoS attacks, apply rate limiting, and enable web application firewall (WAF) rules — all of which help mitigate a wide range of external threats.

At this stage, we have not yet implemented formal automated security testing or third-party audits. However, we are in the process of evaluating tools like Snyk (for dependency scanning) and OWASP ZAP (for basic vulnerability scanning) for integration into our CI/CD pipeline. These will allow us to automatically identify vulnerabilities on each deployment.

As we scale, we plan to engage a third-party security firm for deeper assessments, including penetration testing and secure code reviews. Security is a growing priority for us, and we are committed to maturing our processes as our product and customer base grow.

We host our infrastructure on Google Cloud Platform (GCP) and run our application on Kubernetes. Our network is protected by Cloudflare, which provides WAF, HTTPS enforcement, DDoS protection, rate limiting, and other critical security controls at the edge.

For vulnerability management, we currently address the most critical and basic risks as follows:

• Cloudflare handles edge-layer protections including HTTPS enforcement, TLS configuration, bot mitigation, and web application firewall (WAF) rules.

• GCP provides infrastructure security baselines, IAM management, and firewall configuration. We rely on default secure configurations and restrict public access to our cloud services.

• We are evaluating the use of the following tools to improve host- and container-level vulnerability management:

  • Google Cloud Security Command Center (SCC) — for infrastructure and misconfiguration alerts

  • Trivy — for container image and Kubernetes node vulnerability scanning

  • kube-bench — to ensure our Kubernetes cluster complies with CIS security benchmarks

  • Nmap — for periodic public port and network surface scans

• For dependency security and static analysis, we are exploring Snyk and GitHub Dependabot to scan for known vulnerabilities in open-source packages.

• Infrastructure and deployment pipeline security

• Source code integrity and dependency risk

• Access control, authentication, and logging

• Data handling and user privacy safeguards

• SLA and ticketing performance

Framework Alignment:
Our audit framework is directly mapped to ISO 27001 control objectives. Each audit cycle includes a control-by-control review against these standards.

Frequency:
Internal audits are conducted quarterly, with additional targeted reviews after significant product releases, vendor changes, or incidents.

Remediation Process:
All findings are logged in our internal ticketing system. Issues are categorized by severity:

• Critical issues are remediated within 4 hours, in line with our 99.99% uptime SLA.

• Moderate/Low issues are assigned owners and tracked for closure in our monthly operations meetings.

Continuous Improvement:
Audit results are reviewed by leadership, and corrective actions are documented and verified. We also integrate automated scanning tools (e.g., code scanners, dependency checks) to maintain security posture between audits.

1. Which IT operational, security, privacy related standards, certifications and/or regulations you do comply with?
   
   While viaSocket does not yet hold a separate SOC 2 certification.
   If required, we are prepared to complete a dedicated SOC 2 for viaSocket within 60 days.

Please summaries or attach your application vulnerability management processes and procedures?

At viaSocket, our vulnerability management approach prioritizes protection at the network, application, and code levels, leveraging leading cloud and security platforms. Our process includes:

• Perimeter Protection: We use Cloudflare WAF to mitigate critical vulnerabilities such as SQL Injection, Cross-Site Scripting (XSS), and Distributed Denial-of-Service (DDoS) attacks. Rate limiting and IP reputation controls are enabled to defend against abusive traffic.

• Cloud Security: Our backend runs on Google Cloud Platform (GCP) in Google Kubernetes Engine (GKE), with no public internal IPs, VPC isolation, and IAM role management. GCP Security Command Center flags misconfigurations or security risks.

• Authentication: We use OAuth for secure authentication, and all API communication is encrypted over HTTPS.

• Monitoring: Atatus, Cloudflare, and GCP tools provide real-time performance, error, and security monitoring, helping us detect anomalies and investigate security issues quickly.

• Incident Response: We monitor runtime systems continuously and act based on predefined alerting rules. Our team uses GCP and Atatus logs to respond to suspicious behavior or security events.

Ongoing Improvements:
We are currently integrating automated tools to improve our handling of:

• Vulnerable dependencies (SCA) – tools like Snyk or Trivy

• Static code vulnerabilities (SAST) – tools like Semgrep

These upgrades will ensure we catch vulnerabilities early in development and enhance compliance with common industry expectations.

What tools do you use for application vulnerability management?

✅ Currently in Use:

🔧 In Progress / Planned:

How do you regularly evaluate patches and updates for your infrastructure?

viaSocket follows a structured and proactive patching process to ensure security and reliability in our production environment:

• Library & Dependency Updates: We regularly review and update the libraries and frameworks used in our codebase. Critical security patches are prioritized and deployed promptly.

• Environment Separation: We maintain separate testing and production environments. All patches and updates are first applied to the testing environment, where we perform regression and stability testing before production deployment.

• Containerized Deployments: Our backend services run on Google Kubernetes Engine (GKE). Application containers are rebuilt regularly using updated base images and redeployed via CI/CD pipelines.

• CI/CD Rollouts: Deployments use a controlled CI/CD pipeline with support for rolling updates and rollback mechanisms, minimizing risk during patching.

• Cloud Infrastructure: Underlying infrastructure patches are automatically managed by Google Cloud Platform (for compute resources) and Cloudflare (for edge and WAF services), ensuring timely security updates at the OS and network layers.

This combination of automated patching, version control, and safe deployment practices ensures that we consistently address critical vulnerabilities with minimal impact to production operations.

At viaSocket, all employees operate from a secure in-office environment. Each team member is responsible for managing their own workstation. While we do not currently use a centralized endpoint management solution, access to production systems is strictly limited and controlled through secure methods. Workstations do not connect directly to production infrastructure. All access is mediated through secure cloud environments (GCP/GKE) and is gated via SSH keys, VPNs, and role-based permissions.

Although device configurations are not centrally enforced, we maintain internal standards and encourage all employees to follow security best practices, including:

• Use of strong login passwords and automatic system lock after inactivity

• Limiting administrative privileges to reduce the risk of privilege escalation

• Use of secure office networks with firewall-level protections

Employees are also trained on general security hygiene and safe software development practices. All development and operations workflows occur within secured environments, such as GCP-hosted containers, ensuring minimal reliance on local execution or sensitive local storage.

We maintain a strict policy that no sensitive or private customer data is stored on endpoint devices. All sensitive operations are conducted through secure cloud infrastructure, and customer data remains encrypted and contained within GCP-managed services.

• Access to sensitive data is restricted via SSH key-based authentication, segregated user credentials, and limited access roles

• Employees do not have local access to databases, secrets, or production logs

• Shared credentials and sensitive tokens are stored securely in cloud-managed environments and not distributed to individual machines

This policy is enforced through technical design — we architect systems to never expose sensitive data at the endpoint level. Combined with secure defaults in our cloud infrastructure and clear internal guidelines, this ensures that the risk of endpoint-based data exposure is effectively mitigated.

Yes, all hosts and containers running Viasocket services are configured uniformly. Our infrastructure is built on Google Kubernetes Engine (GKE), which allows us to manage workloads using standardized container images and version-controlled configuration files. Each deployment adheres to a defined baseline configuration, ensuring consistency across environments (testing and production). Infrastructure definitions, environment variables, and runtime parameters are maintained in source control and follow Infrastructure-as-Code (IaC) principles to minimize drift and misconfiguration.

At viaSocket, we follow a secure and centralized approach to managing secrets such as authentication tokens, API keys, passwords, and certificates. Our key practices include:

• Cloud-Native Secrets Management: All secrets are stored and managed using Google Cloud Secret Manager. This ensures secrets are encrypted at rest and access is tightly controlled via IAM policies.

• Environment Separation: Secrets are scoped by environment (testing vs. production), and access is restricted based on least privilege. Production secrets are never accessible from development environments.

• No Local Storage: Secrets are never stored in source code or on local machines. Developers access services using temporary or environment-scoped credentials when necessary.

• Access Control: Access to secrets is role-based and limited to authorized team members and services. This is enforced through GCP’s Identity and Access Management (IAM) system.

• Secret Injection at Runtime: Secrets are injected into containers securely at runtime via environment variables or mounted volumes. They are never written to disk in plaintext.

• Audit & Rotation: Access to secrets is logged and monitored. We regularly rotate sensitive credentials, especially API keys and tokens, following best practices and compliance requirements.

This approach minimizes exposure, enforces control, and ensures secure handling of all sensitive credentials across our infrastructure.

Yes, our production environment is hosted within a Google Cloud VPC, which provides a secure, isolated network environment. While we use a single VPC for both testing and production, service.s are logically separated and access is tightly controlled through firewall rules, IAM policies, and namespace-level isolation within Google Kubernetes Engine (GKE).

No internal APIs, databases, or backend services are publicly exposed. All such components are assigned private IP addresses only, and communication is restricted within the cluster or VPC using Kubernetes network policies and GCP firewall rules, ensuring secure, segmented access even within a shared network.

All network configuration changes (such as updates to VPC rules, firewall settings, or IP access control lists) are performed manually but undergo multiple layers of review before implementation. Changes are reviewed by relevant engineers and release managers, ensuring that no modifications are applied without proper oversight and risk assessment. This review process ensures network changes align with our security and operational standards.

Yes, all network traffic to and from the production infrastructure over public networks is secured using cryptographically sound encryption protocols, primarily HTTPS with TLS 1.2/1.3. We enforce HTTPS at the edge using Cloudflare, which proxies and secures all external-facing services. There are no plaintext connections to production systems over public networks, and no ports or services are exposed without encryption. For internal communication, GCP’s infrastructure provides encryption in transit by default, and traffic within Kubernetes (GKE) clusters is restricted to private, secured channels.

All data in transit over public networks is secured using TLS 1.2 or higher, enforced via Cloudflare and Google Cloud. All public-facing APIs and services are only accessible over HTTPS, ensuring strong encryption.

We use Google Cloud's default encryption at rest, which leverages AES-256 encryption for all data stored on disks, databases, and cloud-managed services (such as GKE, Cloud Storage, Cloud SQL, etc.). For additional protection, sensitive user information stored within our databases is explicitly encrypted at the application level using AES-256, ensuring double-layer protection beyond the infrastructure defaults.

We support multiple authentication methods, including Google OAuth and traditional email/password login. For users authenticating via email and password, we ensure password security by applying industry-standard cryptographic hashing and salting techniques using trusted libraries within the Node.js crypto module. Passwords are never stored in plaintext, and the hashing approach is designed to resist brute-force and rainbow table attacks.

Beyond password protection, all sensitive user data stored in our databases is encrypted at rest using AES-256 encryption, providing a robust layer of security for confidential information.

This combined approach ensures strong security controls around user credentials and sensitive data, leveraging both secure external authentication providers and best-practice cryptographic safeguards internally.

No, we do not use any custom cryptographic implementations. We rely entirely on well-established cryptographic standards and libraries provided by Google Cloud, Node.js, and trusted open-source libraries. This avoids the risks associated with designing or implementing cryptographic logic internally.

We manage cryptographic keys and secrets using Google Cloud Secret Manager, which provides secure storage and access control for all sensitive keys, tokens, and credentials. Access to secrets is tightly controlled using Google Cloud IAM policies, ensuring that only a very limited number of authorized personnel can retrieve or manage these keys.

All access to secrets is logged and audited, enabling traceability and accountability for key usage. While we currently do not have an automated key rotation policy, we rely on Google Cloud Secret Manager’s secure infrastructure to protect keys at rest and in transit.

We do not use hardware security modules (HSMs) at this time but benefit from Google Cloud’s managed security features and best practices for key protection, including encrypted storage and secure access controls.

We rely on the security features and threat intelligence provided by our cloud provider (GCP) and security partners such as Cloudflare, which proactively identify emerging threats and vulnerabilities. We maintain ongoing awareness of potential security vulnerabilities and threats through continuous monitoring and alerting.

Our logging and alerting framework spans both application and network layers. We use Atatus for detailed application-layer monitoring, performance tracking, and security event logging. At the network layer, we rely on Cloudflare to monitor traffic, block threats, and log events through its Web Application Firewall (WAF) and rate limiting features.

Logs from both systems are centrally aggregated and monitored. Alerts generated from security events, such as suspicious traffic patterns or application errors, are configured to notify our security and operations teams via Slack and email, enabling timely investigation and response. This dual-layer monitoring ensures comprehensive coverage of security events across our infrastructure.

Our Security Incident Response Program is designed to ensure timely detection, containment, and remediation of security incidents to minimize impact on our services and customers. The program includes:

• Defined roles and responsibilities: We have a dedicated security and operations team responsible for incident investigation and management. Alerts from monitoring tools like Cloudflare and Atatus trigger immediate review.

• Incident classification and prioritization: Incidents are categorized based on severity and potential impact, allowing us to allocate resources efficiently.

• Incident handling procedures: We follow a structured process including identification, containment, eradication, recovery, and post-incident analysis.

• Communication protocols: Internal notifications are sent promptly via Slack and email to relevant stakeholders. If necessary, we escalate incidents to senior leadership.

• Documentation and reporting: All incidents are logged with details on cause, resolution steps, and lessons learned to improve future response.

We test our Incident Response Plan through periodic tabletop exercises and simulated scenarios involving key team members from security, operations, and development. These exercises occur at least bi-annually and are designed to validate the effectiveness of our procedures, communication, and coordination under realistic conditions.

Additionally, we review and update the plan after any significant incident or change to our infrastructure to ensure it remains current and effective.

We test our Incident Response Plan through periodic tabletop exercises and simulated scenarios involving key team members from security, operations, and development. These exercises occur at least bi-annually and are designed to validate the effectiveness of our procedures, communication, and coordination under realistic conditions.

Additionally, we review and update the plan after any significant incident or change to our infrastructure to ensure it remains current and effective.

Yes, we have a defined approach for notifying clients in the event of a security incident that could potentially impact their data or systems.

• Notification Criteria: We commit to notifying affected clients within 24 hours of confirming a security incident that involves unauthorized access, data exposure, or any compromise of customer-facing systems. This is done to ensure transparency, enable customer-side risk mitigation, and uphold our security responsibilities.

• Communication Method: Clients are notified via email, and our support team remains available to address any questions, concerns, or clarification requests. Clients are encouraged to reach out at any time during or after the incident response process.

• Responsibility & Review: Security incidents are reviewed by our internal engineering and security leads, and decisions to notify customers are based on the severity and potential impact of the incident.

This process complements our broader SLA commitments around uptime, maintenance, and operational transparency, and reflects our priority to protect user data and maintain trust.

Data exfiltration from production environments is tightly controlled. SSH access to production servers is restricted through IAM-based access control, and only a very limited set of authorized engineers are granted permission. All access is logged and monitored. Additionally, production environments are configured to disallow file extraction or external data transfers, and outbound internet access is disabled by default where not explicitly required. These measures collectively ensure that data movement from production systems is tightly regulated.

Although device configurations are not centrally enforced, we maintain internal standards and encourage all employees to follow security best practices, including:

• Use of strong login passwords and automatic system lock after inactivity

• Limiting administrative privileges to reduce the risk of privilege escalation

• Use of secure office networks with firewall-level protections

Employees are also trained on general security hygiene and safe software development practices. All development and operations workflows occur within secured environments, such as GCP-hosted containers, ensuring minimal reliance on local execution or sensitive local storage.

We maintain a strict policy that no sensitive or private customer data is stored on endpoint devices. All sensitive operations are conducted through secure cloud infrastructure, and customer data remains encrypted and contained within GCP-managed services.

• Access to sensitive data is restricted via SSH key-based authentication, segregated user credentials, and limited access roles

• Employees do not have local access to databases, secrets, or production logs

• Shared credentials and sensitive tokens are stored securely in cloud-managed environments and not distributed to individual machines

This policy is enforced through technical design — we architect systems to never expose sensitive data at the endpoint level. Combined with secure defaults in our cloud infrastructure and clear internal guidelines, this ensures that the risk of endpoint-based data exposure is effectively mitigated.

Please summarise or attach your network vulnerability management processes and procedures?

We have a structured process in place for identifying, assessing, and addressing network and host-level vulnerabilities within our infrastructure.

• Vulnerability Scanning:
  We use Google Cloud Security Command Center (SCC) to perform regular network and host vulnerability scans. These scans are conducted monthly to identify misconfigurations, exposed services, and known vulnerabilities across our infrastructure, including GCP-managed services and Kubernetes (GKE) nodes.

• Threat Intelligence & Monitoring:
  We rely on integrated security feeds and alerts from GCP SCC, Cloudflare, and Atatus to stay aware of vulnerabilities relevant to our environment. These tools provide continuous monitoring for new threat vectors and suspicious activity, especially at the network and application layers.

• Review & Mitigation:
  Identified vulnerabilities are triaged and reviewed by multiple team members, including engineers and release managers, to determine appropriate remediation. Patching decisions are prioritized based on severity, exploitability, and impact on production workloads.

• Tracking & Accountability:
  We maintain an internal tool, Db Dash, to track, manage, and resolve vulnerabilities. This ensures visibility into the status of each issue and accountability for timely remediation.

• Patch Management:
  While we do not currently use an automated patching system, all patches related to vulnerabilities identified through scans or alerts are manually assessed and applied as needed, with peer review and regression testing in our dedicated testing environment before production deployment.

This process ensures we proactively identify and manage risks in our cloud-hosted and containerized infrastructure, while also maintaining operational stability and compliance with basic security hygiene

1. Introduction

This Information Security Policy establishes the principles and responsibilities for safeguarding

viaSocket's data and systems.

2. Purpose

The purpose of this policy is to protect the confidentiality, integrity, and availability of data handled

by viaSocket.

3. Scope

This policy applies to all employees, contractors, and third-party vendors who handle viaSocket

data.

4. Security Controls

- Access Control: User accounts and roles are managed carefully to limit access to data based on

job responsibilities.

- Data Protection: Data is protected by encryption and secure storage.

- Incident Response: viaSocket has an incident response procedure in place to quickly handle

security incidents.

- Physical Security: Physical access to office spaces and servers is restricted.

- Employee Awareness: Employees receive security awareness training.

5. Roles and Responsibilities

- Security Officer: Responsible for overseeing security program implementation and compliance.

- Employees: Expected to follow security policies and report incidents.

6. Policy Review

This policy is reviewed annually and updated as needed.

What technology languages/platforms/stacks/components are utilized in the scope of the application?

The viaSocket application stack includes:

• Frontend: ReactJS, Next.js, HTML5, CSS3, JavaScript, TailwindCSS

• Backend: Node.js, Express, and TypeScript

• Database: PostgreSQL and MongoDB

• Caching & Search: Redis and Elasticsearch

• Cloud/Infrastructure: Google Cloud Platform (GCP), Google Kubernetes Engine (GKE), Docker, GitHub Actions, and GCP Triggers

  • Security: TLS/SSL for secure data transmission and role-based access control

At

viaSocket.com

1. Data Encryption In Transit:

• We use TLS 1.2/1.3 to encrypt all data transmitted between clients and our servers.

• All APIs and application endpoints are served over HTTPS with strong cipher suites.

2. Data Encryption At Rest:

• Customer data stored in our databases is encrypted using AES-256 encryption.

• Sensitive credentials and secrets are further secured using encryption key management systems provided by our cloud providers (e.g., AWS KMS or equivalent).

3. Secrets and API Keys:

• We never store plaintext secrets. All API tokens and sensitive information are encrypted before storage.

• Vaulting and access control policies are in place to restrict sensitive data access.

4. Access Control:

• We use role-based access control (RBAC) to limit internal access to encrypted data.

• Data is only accessible by services or personnel with a strict need-to-know basis.

1. Input Validation (Basic XSS/SQL Injection)

• In any input field (e.g., form, search), enter:

  • "><script>alert(1)</script> → Should not execute any script.

  • ' OR 1=1-- → Should not affect login or queries.

• Observe page behavior and console for script execution or server errors.

2. Session Management

• Login → Close tab → Reopen and access the app → Should still be logged in if session valid.

• Login → Wait 30+ minutes idle → Try again → App should timeout session.

• After logout, try using browser back → Should not allow access to pages.

3. Access Control / IDOR (Insecure Direct Object Reference)

• Login as User A → Copy a URL containing an object ID (/flow/123)

• Login as User B → Try accessing that same URL → Should receive Access Denied or 404

4. Error Handling / Information Leakage

• Force an error (e.g., disconnect network or corrupt URL) → App should show a friendly error page, not a stack trace, database name, or internal path.

• Look at responses in dev tools → Ensure no sensitive info (tokens, env values, etc.) is leaked.

5. Role-based Access Control (RBAC)

• Log in with different roles (Admin/User/Viewer, etc.)

• Try accessing features or APIs not allowed for that role via direct link → App should block or hide.

6. File Upload Validation (if applicable)

• Try uploading:

  • .exe or .php files → Should be blocked

  • Large files (e.g., >20MB) → Should show limit exceeded

  • Rename a .js file to .jpg → Should still be blocked

• Ensure uploaded files can’t be directly accessed unless needed

7. Security Headers (Non-CF Controlled)

Use browser dev tools → Network → Any request → Response headers
Check for:

• X-Frame-Options: DENY

• X-Content-Type-Options: nosniff

• Referrer-Policy: no-referrer or strict-origin-when-cross-origin

(CF may not always cover these fully; backend should ensure)

8. Token & API Security

• Open browser dev tools → Look for JWT or auth tokens → Ensure they are:

  • Stored in secure, HTTP-only cookies (preferred)

  • Not exposed in localStorage/sessionStorage (avoid this if possible)

• Try calling a few API endpoints manually with an expired/invalid token → Should return 401/403, not data.

📋 Internal Audit Plan (You Can Start With This)

Roles Involved:

• CTO or Engineering Lead (Audit Owner)

• DevOps or Security Engineer (Reviewer)

• Product/Support Lead (User-facing audit areas)

Audit Checklist (Quarterly):

• ✅ CI/CD pipeline access and permission checks

• ✅ GitHub repo scanning for secrets or misconfigurations

• ✅ Access logs review for production systems

• ✅ Third-party service usage and dependency review

• ✅ Ticketing system SLA compliance check (e.g. response and resolution times)

Tools You Can Use:

• GitHub Code Scanning

• Dependabot or Snyk (for dependency audits)

• Postman/New Relic/DataDog (for monitoring & API checks)

• Google Sheets or Notion (for logging audit reports)