Tightknit Infrastructure & Application Security

​

Application Infrastructure

Tightknit utilizes best-in-class cloud infrastructure vendors to provide the Tightknit service. Tightknit’s infrastructure is primarily managed through Cloudflare, Supabase, and Vercel, and is complemented by additional specialized services to support advanced functionalities.

​

Primary Infrastructure

Tightknit’s platform operates primarily on Cloudflare Workers, Supabase Postgres, and Vercel, ensuring high availability, security, and compliance.

Cloudflare’s network security capabilities provide robust DDoS protection, while Supabase offers managed, scalable database services with strong encryption practices. Vercel powers our frontend deployment, offering performance optimizations and automatic scaling. Cloudflare Workers support our application and allow us to protect ourselves with isolated serverless executions.

Cloudflare, Supabase, and Vercel maintain certifications including ISO 27001, SOC 2, and PCI DSS, ensuring adherence to industry security standards.

​

Access Controls

All Tightknit employees have limited access to Tightknit infrastructure and systems, and access is always provisioned on a minimum-necessary, least-privilege basis.

Access is only granted on a need-to-use basis, based on the responsibilities and duties of the employee. Role-Based Access Controls (RBAC) restrict data access to authorized personnel.

​

Data Obfuscation

To enhance security, Tightknit employs database role-based access control to obscure customer data. In rare cases where support teams require visibility, written customer approval is mandatory, and access is granted temporarily.

​

Authentication

Every Tightknit employee has unique authentication details that identify them when accessing infrastructure systems, assets, and applications. Multi-factor authentication is enforced and Google Workspace SAML is used whenever available.

​

Physical controls

Tightknit utilizes Supabase which utilizes Amazon Web Services as the principal database infrastructure. Amazon Web Services data centers feature a layered security model, including extension safeguards such as:

• custom-designed electronic access cards

• motion alarms and sensors

• video surveillance

• perimeter fencing

• metal detectors

• biometrics

Tightknit employees do not have physical access to Amazon Web Services data centers, servers, network equipment, or storage.

​

Vulnerability Management

Tightknit has vulnerability management policies and procedures in place to describe how we monitor for new vulnerabilities, enforce timelines and processes for remediation.

​

Scanning and detection

Tightknit utilizes services like Snyk to perform internal vulnerability scanning and package monitoring on a continuous basis.

​

Security advisories

Tightknit subscribes to GitHub’s security alerts program. If GitHub detects a vulnerability from the GitHub Advisory Database or WhiteSource in one of the web application’s dependencies, the engineering team is notified.

​

Severity and timing

Tightknit defines the severity of an issue via industry-recognized Common Vulnerability Scoring System (CVSS) scores, which all modern scanning and continuous monitoring systems utilize. The CVSS provides a way to capture the characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

​

Low Severity - 0.1 - 3.9

Low severity vulnerabilities are likely to have very little impact on the business, perhaps because they require local system access.

​

Medium Severity - 4.0 - 6.9

Medium severity vulnerabilities usually require the same local network or user privileges to be exploited.

​

High Severity - 7.0 - 8.9

High severity vulnerabilities are typically difficult to exploit but could result in escalated privileges, significant data loss, and/or downtime.

​

Critical Severity - 9.0 - 10.0

Critical severity vulnerabilities likely lead to root level compromise of servers, applications, and other infrastructure components. If a critical vulnerability cannot be addressed within timelines as defined, an incident response ticket will be opened, documenting what interim remediation has been made.

​

Remediation process

When a vulnerability is detected and verified, the engineering team will remediate vulnerabilities within the SLA depending on the severity. Compliance of vulnerability SLAs is enforced and tracked using Linear.

​

Vulnerability disclosure

This policy governs how security researchers should raise security concerns with us, and how we will respond.

Data security is a top priority for Tightknit, and we believe that working with skilled security researchers can identify weaknesses in any technology.

If you believe you’ve found a security vulnerability in our service, please notify us; we will work with you to resolve the issue promptly.

​

Disclosing a weakness

• If you believe you’ve discovered a potential vulnerability, please let us know by emailing us at [email protected]. We will acknowledge your email within ten business days.

• Provide us with a reasonable amount of time to resolve the issue before disclosing it to the public or a third party. We aim to resolve critical issues within one week of disclosure.

• Make a good faith effort to avoid violating privacy, destroying data, or interrupting or degrading the Tightknit service. Please only interact with accounts you own or for which you have explicit permission from the account holder.

​

Exclusions

While researching, we’d like you to refrain from:

• Distributed Denial of Service (DDoS).

• Spamming.

• Automated penetration tests or vulnerability scans.

• Social engineering or phishing of Tightknit employees or contractors.

• Any attacks against Tightknit’s physical property or data centers

​

Logging and monitoring

Tightknit application and infrastructure uses industry-standard tooling and multiple logging layers to monitor the application health and alert the engineering team when something is not working as expected.

​

Application logging

Tightknit utilizes Sentry, Cloudflare Logs, and Axiom for application logging and monitoring to help diagnose and fix issues within Tightknit. Application error logs are stored in Sentry for 30 days and are used to help investigate issues raised from automatic alarms raised via Sentry.

​

Infrastructure logging

Tightknit utilizes Grafana to log, monitor, and alert on resource allocation and operational performance of the infrastructure of the Tightknit database.

​

Audit logging

Tightknit utilizes Cloudflare Audit Logs to enable governance, compliance, and operational risk auditing of operations and actions taken on Cloudflare infrastructure and services. Audit logs are stored indefinitely.

​

Firewall

Tightknit employs industry-standard techniques for detecting and preventing possible intrusions. Detected intrusions can result in escalation through incident response procedures.

​

Web Application Firewall

Tightknit is protected by Cloudflare’s web application firewall (WAF) and assists in blocking common web exploits and attack patterns. Tightknit manages a number of firewall rules, including rules that address issues like the OWASP Top 10 security risks.