Security and Compliance

Cloudflare (WAF)

Blocks SQLi, XSS, DDoS, bot attacks

GCP Security Center

Monitors for misconfigurations, IAM violations

GKE (Kubernetes)

Isolated container environments, no public internal IPs

Atatus

Application monitoring, alerting, runtime issue tracking

Snyk / Trivy

Scan open-source dependencies for known CVEs (SCA)

Semgrep

Scan source code for injection flaws, insecure patterns (SAST)

Gitleaks / TruffleHog

Detect hardcoded secrets/tokens in Git history

Are all endpoint laptops that connect directly to production networks centrally managed?

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.

Describe standard employee issued device security configuration/features. (Login Password, antimalware, Full Disk Encryption, Administrative Privileges, Firewall, Auto-lock, etc.)

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.

Does sensitive or private data ever reside on endpoint devices? How is this policy enforced?

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.

Config Management

Are the hosts where the service is running uniformly configured?

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.

Are changes to the production environment reviewed by at least two engineers/operations staff?

Yes, all changes to the production environment are reviewed by at least two team members. We have dedicated release managers who review and approve every deployment after peer code review, ensuring proper oversight before any changes are applied to production.

Secrets Management

Describe your secrets management strategy:(auth tokens, passwords, API credentials, certificates)

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.

Logs

Are all security events (authentication events, SSH session commands, privilege elevations) in production logged?

Yes, all critical security events in our production environment are comprehensively logged and monitored. This includes:

• Authentication Events: All user authentication attempts, both successful and failed, are logged via Google Cloud Audit Logs and our integrated identity access management tools.

• SSH Sessions: SSH access to production systems is tightly restricted and rarely used. When required, all SSH access is logged, and session activity (including commands executed) is recorded using GCP’s logging infrastructure.

• Privilege Elevations: Any privilege elevation, such as use of sudo or changes to IAM roles and permissions, is automatically tracked through Cloud Audit Logs, ensuring full traceability of administrative actions.

• Log Access Control: Access to production logs is strictly limited to a small number of authorized personnel. Role-based access controls (RBAC) in GCP ensure that only relevant team members with a legitimate operational need can view or query sensitive logs. All access to logs is itself auditable and monitored.

Logs are securely stored, timestamped, and retained according to our internal policy. They are regularly reviewed and used for security monitoring, incident response, and compliance verification. Anomalies and suspicious events are flagged through our observability stack, which includes Atatus, Cloudflare, and GCP-native monitoring tools.

Network Security

Is the production network segmented in to different zones based on security levels?

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

What is the process for making changes to network configuration?

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.

Is all network traffic over public networks to the production infrastructure sent over cryptographically sound encrypted connections? (TLS, VPN, IPSEC, etc). If there are plaintext connections, what is sent unencrypted?

1. 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.

Cryptographic Design

What cryptographic frameworks are used to secure data in transit over public networks?

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.

What cryptographic frameworks are used to secure data at rest?

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.

What cryptographic frameworks are used to store passwords?

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.

Are any custom crypographic frameworks/implementations used? If so, have any custom cryptographic frameworks been reviewed by an independent 3rd party?

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.

Key Management

How are crytographic keys(key management system, etc) managed within your system?

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.

How do you keep aware of potential security vulnerabilities and threats that may affect your service?

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.

How do you log and alert on relevant security events? (this includes the network and application layer)?

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.

Describe or attach your Security Incident Response Program?

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.

How is your Incident Response Plan tested? Include cadence.

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.

Do you have a formal service level agreement (SLA) for incident response?

https://viasocket.com/faq/others/service-level-agreement-sla

Do you have formally defined criteria for notifying a client during an incident that might impact the security of their data or systems? What are your SLAs for notification?

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.

How do you limit data exfiltration from production endpoint devices?

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.

What systems do you have in place that mitigate classes of web application vulnerabilities? (e.g.: WAF, proxies, etc)

We use Cloudflare Web Application Firewall (WAF), which is fully configured to block a wide range of web application vulnerabilities, including OWASP Top 10 threats such as SQL injection, XSS, and RCE. In addition, we utilize Cloudflare rate limiting, bot protection, and custom firewall rules to prevent abuse and reduce the attack surface. All public traffic to the application flows through Cloudflare, ensuring comprehensive edge-level protection.

Do you have breach detection sytems and/or anomaly detection with alerting?

Yes, we use Cloudflare and Atatus for breach and anomaly detection. These tools monitor both network-level traffic and application-level behavior. We have alerting configured via email, which notifies the team of any abnormal activities such as suspicious login attempts, traffic spikes, or access pattern anomalies. These alerts allow for a timely investigation and response to potential incidents.