Security

We're often asked about the security and safety of your data. In this page we'll describe some of the steps we take to prevent leakage of your intellectual property. If you have any further concerns, please feel free to reach out!

Certifications

Screenshotbot is SOC2 Type II compliant. This attestation indicates that our handling and processing of customers' data meets key security standards.

We use Vanta to track and maintain our security posture even when we're not under an audit.

You can request the latest SOC2 report from our Trust and Security dashboard.

Penetration Testing

Screenshotbot partners with Pensive Security, an external security research company, to perform annual penetration tests.

You can download the most recent Letter of Attestation, or you can request the detailed Penetration Test and Remediation report on our Trust and Security dashboard.

Keeping your Code safe

Screenshotbot does not need access to your code. It does not need access to any metadata in your Git repository. During the CI step, Screenshotbot creates a "commit graph": This is a commit graph of only the commit hashes, and for each commit hash its parent commit hashes. This is the only information we need about your code.

On GitHub and Azure DevOps, we require permission to update the build statuses on commits and Pull Requests. This permission does not grant us the ability to read or write code.

On BitBucket and Phabricator, we only use the APIs to update build statuses, but the platforms don't provide granular permissions. So a simple configuration using these platforms might provide us access to read and write code, even though we don't use it. Our corresponding documention provides suggestions on how to limit the scope of the access to only certain repositories.

The same is true for GitLab, but we also support integrations using secure webhooks. Without webhooks you would have to provide us an access token and GitLab doesn't provide granular permissions. You can restrict the access token to specific repositories, but not specific APIs. With webhooks, you would have to implement a custom webhook listener, and forward the build statuses to your GitLab server. In this mode, Screenshotbot does not need an access token and will have no access to your GitLab instance. Please reach out to us if you are looking for webhook support on BitBucket or Phabricator.

In every case, we provide audit logs of each time Screenshotbot makes any API call to your services.

Keeping your Images safe

By default, all images uploaded to Screenshotbot are sent over an encrypted channel, and are stored on Screenshotbot's servers. In particular, we do not serve images over an external object storage such as S3.

This means that we can have tight controls over who can access your images.

Image URLs

Image URLs have encrypted information in order to access the image:

Anyone who is given this URL can access the image. (But we can override this if you wish!) This URL cannot be guessed, the only way to get access to this URL is to log in to your dashboard and copy the image URL for whichever image you are looking for.

CDN

By default, we might use CDNs to link to the images. In this situation the image might be cached on the CDN (we use CloudFront which is run by Amazon). But again, nobody can access the image unless they have the encrypted identifier. We can disable the CDN on request.

Stronger restrictions

The use of the CDN and publicly accessible image URLs are meant to protect us from Denial of Service attacks. However, we understand that some enterprise customers might want to restrict access to images further, perhaps for legal reasons, or just to reduce the chance of a leak by someone who has access to your account.

For enterprise customers, if you wish, we can ensure that images are only accessible to users who are logged in. In this setup, if somebody has access to the URL, they would not be able to access the image. We would not use a CDN if you choose to go this route (since using a CDN would prevent us from doing access checks).

Third-party Vendors

The only third-party vendors that hold our customers' data are data-center providers and CDN providers.

We use AWS for compute, storage, CDN and email. See their certifications here.