Some examples of how we operate our security program include:

• Continuous vulnerability scanning and patching of our infrastructure
• Hardening of our virtualized cloud infrastructure and microservices
• Annual penetration tests conducted by companies with a strong reputation in offensive security and red teaming
• Regular internally conducted penetration testing and application security assessments
• Segmentation and isolation of customer data within our infrastructure
• Distributed Denial of Service protections for hosted customer websites
• Quarterly Disaster Recovery simulations and Incident Response tabletop exercises
• Threat-informed risk analysis
• Adhering to recognized industry standards such as CIS and SOC 2

Shared Responsibility

Like many cloud SaaS providers, Gatsby approaches security through a shared responsibility model. A shared model is essential since we at Gatsby don’t review or test the security of customer-supplied code built within the Gatsby Cloud.

Our responsibility at Gatsby is to secure our infrastructure and our underlying service offerings. We work hard to ensure that the digital assets, source code, configurations, and deployed websites you entrust to our services are protected.

Customers are responsible for the security of the projects, websites, and applications that are built and deployed within the Gatsby Cloud. This includes using best practices with regard to secure coding, application security testing, secure application architecture, and understanding where and how your application exposes data.

Compliance at Gatsby

SOC 2 Type 2

Gatsby has aligned our security program with the AICPA SOC 2 standard and is SOC 2 Type 2 certified for the Trust Services Criteria: Security, Availability, and Confidentiality. We chose SOC 2 as a compliance framework, as it’s one of the best industry recognized standards for service organizations to demonstrate maturity around IT security and data protection controls. Our customers can be confident that our security program and data handling practices adhere to industry best practices, and is audited annually.

We are able to make our SOC 2 report available to current customers who have professional tier plans or higher. Contact our compliance team or your sales representative for more details.

GDPR

Gatsby adheres to the European Union’s General Data Protection Regulation - commonly referred to as GDPR - and has chosen to be audited against the standard annually to ensure compliance. We are also able to provide a Data Processing Agreement (DPA) for customers who require such an agreement for compliance purposes.

An up-to-date list of Gatsby’s sub-processors can always be found at the following URL: https://www.gatsbyjs.com/subprocessors/

Making a GDPR data request

If you are a citizen of the European Union and would like to make a GDPR data request, sign in to your Gatsby account and use the contact form to make a request. GDPR requests made in this manner will be forwarded to the appropriate internal channel, so one of our compliance officers can assist in completing your request.

Help → Get Help → Contact Us → GDPR Request (EU customers only)

Contact Gatsby Security

If you have any questions for our security and compliance team at Gatsby you can reach us by email at the following addresses.

• Technical or general security questions: security@gatsbyjs.com
• Compliance related questions: compliance@gatsbyjs.com

Reporting a Vulnerability

If you believe you have found a security issue with any of Gatsby’s open source or commercial offerings, we would love to receive your report! Security findings can be emailed to security@gatsbyjs.com.

Gatsby does not operate a formal bug bounty program at this time - and does not offer monetary rewards for vulnerability reports, but researchers reporting vulnerabilities may be acknowledged in a security advisory. Security advisories can be viewed at: https://github.com/gatsbyjs/gatsby/security/advisories

When reporting a security issue, describe the issue in detail and include steps to reproduce, including any relevant tools and tool output. Please do not send attachments with your report, although if required, TXT files and screenshots in PNG or JPG format are permitted. The more detail provided, the more likely we will be able to reproduce the issue and determine a course of action.

Please do not report findings from the following categories:

• Reports from npm audit (We are aware of package dependency issues that are reported by this tool and do review these reports. In many cases the issues reported by npm audit are misleading and do not present a tangible/exploitable security risk for Gatsby users.)
• HTTPS configuration (supported TLS versions, cipher suites, etc.)
• HTTP header configuration
• Clickjacking / UI redress
• DNS configuration (SPF, DKIM, DMARC, CAA)
• Denial of Service or other attacks that repeatedly spam requests toward our services or would affect the availability of our service

Conducting Penetration Testing and Vulnerability Assessments of your Application

We encourage our customers to test the security of deployed web applications. Please contact our security team ahead of any planned testing, with at least a five business day lead time to ensure the testing is not blocked by our security controls.

Tools that may send an abnormal number of requests to our services should be rate limited to a maximum of 10 requests per second. Furthermore, guardrails should be employed to ensure that testing is limited to properties where testing has been authorized by the owner. Testing the security of any property where authorization has not been explicitly given by the owner is strictly prohibited, and may result in account suspension.

In your request, please provide the following information:

• The workspace and site id(s) that will undergo testing
• The expected domain(s) / subdomain(s) that will undergo testing
• The expected start/end date/time when testing will occur
• The IP addresses that will be used to originate traffic
• The contact information (phone number and email address) of the individual or third-party who will be conducting the testing
• Any other specific needs

If any testing uncovers a vulnerability in Gatsby’s service, please contact our security team immediately.

Vulnerability Disclosure Policy

Where applicable, Gatsby will coordinate the public disclosure of validated vulnerabilities within our software. We request that potential vulnerabilities not be disclosed in a public setting until our team has had time to review and respond to the submission, provide a suitable fix to mitigate risk, and reach out to potentially impacted customers. We prefer that any public disclosure be made simultaneously. The timeline to address a vulnerability depends on the severity of the risk and the potential impact.

To determine the severity of a vulnerability, we use the Common Vulnerability Scoring System version 3 (CVSS v3) and the Penetration Testing Execution Standard (PTES) as a guide, and take into account the exploitability of the flaw when evaluating risk. Where applicable, a Common Vulnerability and Exposures (CVE) identifier will be assigned to a validated vulnerability.

We maintain public security advisories for our open source offerings at the following URL: https://github.com/gatsbyjs/gatsby/security/advisories