This is how we think about and incorporate security into what we do at Assistiv Labs. Have questions or feedback? Reach out to us at email@example.com.
- Why security really is vital to Assistiv Labs
- How we take care of your data
- How we keep our code secure
- How we secure our business
- Shared Responsibility Model
- Disclosure policy
Why security really is vital to Assistiv Labs
We believe in shift left accessibility, or including accessibility as early in your process as possible. We’re building tools to help you do that with real assistive technologies.
Often that means testing websites before they’re released to the public, or haven’t left
localhost. Maybe they’re experiments that will never ship.
We want you to feel confident testing with Assistiv Labs at any point, and we hope to build your trust with clear values and continued transparency.
How we take care of your data
Encryption in transit
All communication between you and Assistiv Labs traverses the Internet via encrypted HTTPS/WSS traffic using TLS. This includes everything you might do on assistivlabs.com and with AssistivTunnel.
Encryption during communication ensures information cannot be read or manipulated by unauthorized third parties. We do not expose unencrypted API endpoints.
SOC 2 data centers
Assistiv Labs’ infrastructure primarily runs on Google Cloud Platform (GCP), an Infrastructure as a Service (IaaS) provider with exceptional security. We also use Vercel, a Platform as a Service (PaaS) provider which is built upon Amazon Web Services (AWS), GCP, and Microsoft Azure. Any payment information is securely handled by Stripe. Our infrastructure providers all hold security certifications like SOC 2, ISO 27001, and PCI DSS.
For more information about each provider’s security measures, please see:
Data storage and encryption at rest
All data is encrypted at rest and it’s not possible to disable encryption. This includes:
- Your account details (stored in GCP Firestore)
- Your user account password (stored in GCP Firebase Auth)
- Test device hard disks (GCP Persistent Disks)
- Payment details (stored by Stripe)
We do not have data centers as we are a cloud SaaS provider. Physical security to our servers and to your data is managed by GCP, Vercel, and Stripe.
Backups and data retention
Every time you end a test session, the test device's virtual disk is securely deleted or, in the case of real devices, reset to factory settings, erasing all trace of the websites you visited, files you downloaded, and actions you took; except in cases where software licenses require a long-lived disk (learn more about JAWS licenses).
Your account details and payment details are regularly backed up.
When you delete your account, all your data is deleted.
Access to data
We follow the principle of least privilege when granting staff and services access to systems and data. We will only access your data to assist with support, and we will always ask for your consent.
To administer our cloud infrastructure (GCP, Vercel, Stripe), staff must authenticate with our Single Sign-On (SSO) provider, which is additionally protected by multi-factor authentication (MFA, also known as 2FA).
Production services that need access authenticate using their service account keys, which are encrypted and stored with the appropriate secret providers.
Network and application level security monitoring and protection
Only APIs that require public Internet access are exposed, and are protected from DDoS attacks by Vercel Enterprise WAF and GCP Cloud Armor. Everything else is inside a Virtual Private Cloud (VPC) secured by firewall. Firewall rules are default deny, only opening communication between APIs where necessary.
Test devices do not have public IPs, they are behind NAT. Firewall rules block ingress to all ports and prevent test devices from discovering or communicating with one another.
We monitor and protect our infrastructure and application from various threats using:
- Network and resource misconfiguration scanning and alerting via GCP Security Command Center (SCC) Health Analytics
- Intrusion detection and alerting via GCP SCC Anomaly Detection and custom log alarms
- Regular internal and external network vulnerability scans via Nmap
- Dependency and container vulnerability scanning and alerting via Synk
- Maintaining a network log and cloud provider audit trails
- Infrastructure as Code (IaC); all changes go through security review
- API throttling controls and alerts
How we keep our code secure
All vulnerabilities are managed and tracked through a defined set of stages. Once a vulnerability is detected, it is assigned a score, using the CVSS scoring system.
We have an internal SLA that stipulates deadlines for fixing vulnerabilities.
If necessary, a post-mortem is arranged as a learning exercise for our whole company to improve security.
Continuous integration (CI) checks
When code is committed, our CI process automatically initiates a series of checks, including:
- Automatic static code analysis for common security flaws
- Unit and integration tests validating component-specific access controls and protections
Secure software development life cycle (SDLC)
Security is part of our SDLC and influences the product roadmap and specific features. We implement the philosophy of “security by design” where security features are embedded in the product design to ensure, to the best of our abilities, that existing and new functionalities are free of vulnerabilities.
How we secure our business
All our staff sign confidentiality agreements before gaining access to code and data. Everyone is trained and made aware of security concerns and best practices.
We require our staff’s endpoints (laptops, phones) to have full disk encryption, approved software, and automatic updates enabled.
We have a password policy in place to ensure complex, unique passwords. Whenever possible, we use our SSO provider to authenticate with cloud providers. Staff are encouraged to use password managers, such as 1Password, to track credentials.
The use of MFA is required to access email, chat, and all other cloud providers whenever possible.
Shared Responsibility Model
Security is also a shared responsibility between the platform provider (us) and the consumer (you). There are certain aspects only you can help keep secure.
For example, you are allowed to (likely accidentally) download malicious software onto the test devices your sessions run on, and we cannot do anything to prevent that. We are instead trusting you to be diligent in keeping your sessions free from malware.
Another example is that we cannot help if a malicious piece of software installs a forward proxy on your machine and performs a man-in-the-middle attack on your use of AssistivTunnel. We are instead trusting that you are only running AssistivTunnel from a secure machine.
These are 2 examples that are intended to illustrate the broader shared responsibility between us and you.
We believe working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you've found a security issue, we encourage you to notify us. We welcome working with you to resolve any issue, promptly.
In the event of a security incident, we will always notify affected customers within 24 hours of resolution.