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 firstname.lastname@example.org.
SOC 2 Type 2
Assistiv Labs has a SOC 2 Type 2 attestation for Security criteria. Contact us for a copy of the report.
- 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
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.
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.
Customers on Company Plans can enable secure authentication with platforms like Okta, Auth0, and more.
SAML and OIDC are supported with JIT user creation. SSO can be enforced as a requirement for your organization and associated with one or more email domains.
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.
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.
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.
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
- Dependency and container vulnerability scanning and alerting via Snyk
- Maintaining a network log and cloud provider audit trails
- Infrastructure as Code (IaC); all changes go through security review
- API throttling controls and alerts
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.
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
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.
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.
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.