How Snowflake Native Apps Deliver Security for App Builders and Consumers

The Snowflake Native App Framework, which leverages Snowflake’s advanced architecture, allows for a new level of security for applications. This security spans not just the application consumer, but also the application provider. Controlling all software and infrastructure in the Snowflake Data Cloud, Snowflake can protect the application code, reducing risk for app providers. For consumers, protection comes via extensive capabilities in role-based access control (RBAC), which is used to control application access.

The application market has been growing at a fast pace. This creates several challenges that prevent greater application adoption:

• Data protection and governance
• Data sovereignty
• Third-party agreements
• Security audits
• Security patch and maintenance

Application builders spend a considerable amount of time developing custom processes and algorithms. Before Snowflake Native Apps, application builders had to choose between a managed offering where the provider hosts the infrastructure, the code and the user experience, or a licensing model where the code/packages are given to the application consumer to host on their own hardware.

Traditional software started with licensing agreements where application customers were expected to install and operate the software bought from an application builder. Unfortunately, the team that was expected to operate the application generally knew very little about the solution because it was built by a third party. Operations teams were concerned about introducing issues while patching and upgrading these systems, resulting in systems that were not actively patched. Application consumers, on the other hand, really liked this model for their data protection and governance because the solutions operated on the data in its existing location and, in most cases, a third party didn’t need access. 

For the application providers, not having control over the code/executables not only puts the license at risk, but also puts their business at risk should their software be reverse engineered. Any time an application is packaged and given to a customer to run on their own hardware, reverse engineering those packages becomes much simpler. The code can be debugged and memory can be easily inspected. App builders can build in protection to try to prevent reverse engineering, such as by obfuscating executables, but this is complicated, error prone, and still doesn’t provide complete protection. 

The emergence of SaaS applications and managed services alleviated some of these challenges, but also introduced new ones. With the SaaS model, when application builders control all hardware and software, they maintain control over their code at all times. The builder can also push any urgent updates and security patches as needed. 

The challenge in this shift in the industry is that these applications often require the application consumer to provide access to or a copy of their data to the third-party provider. The builder has, or can have, direct access to this information, which puts more risk on the application consumer. The data that is being stored is outside the consumer’s systems, so the third party has to be evaluated for trust and security risk, and processes have to be carefully checked for compliance.

Snowflake Native Apps (currently in public preview on AWS and private preview on GCP and Azure) are deployed into the application consumer’s Snowflake account. This offers an advantage in that the application is hosted in isolation from other consumers and their data. Multi-tenant applications are often difficult to secure and require a significant amount of engineering and testing to verify data cannot be accessed by unauthorized or malicious users.

For example, if a managed application is vulnerable to a SQL Injection attack, it’s very possible the attacker could gain access to other users’ data. In the case of a Snowflake Native App, the application has only been granted access to the application consumer’s data in the consumer’s own account. If an exploit is found, thanks to the way Snowflake Native Apps isolates each tenant’s data, an application user would only gain access to their own data that they provided to the application.

Snowflake Native Apps are deployed into the consumer’s account. In most application models, this would also allow the consumer access to the builder’s binaries and the servers hosting them. Snowflake’s architecture, in which the servers are administered by Snowflake and not by the customer, helps providers protect the application code from prying eyes.

Here you can see the objects and code when the application is installed in the provider’s account in debug mode:

When installed in the consumer account, the views and functions were configured to not be accessible. The SHOWME_VIEW and SUPERSECRETSAUCE can still be used by the SHOWME_PROC during execution, but the existence of and the code backing all these objects is protected.

Snowflake can allow the consumer to access parts of the application and data, which are granted to the application without giving application consumers, even ACCOUNTADMIN, access to the code/data/logs. 

With Snowflake Native Apps, providers that had concerns about protecting their code are no longer limited to SaaS options. A whole new market is opening up for consumers and providers that want more control over their data.

Snowpark for Python is commonly used in Snowflake Native Apps to provide features which were not possible using Snowflake’s SQL engine. While Python is extremely powerful, it could be a vector for additional exploits—and our customers spoke loudly that package security and governance was of utmost concern. Any developer on the internet can publish a Python package, or in some cases hijack an existing project.

To mitigate these concerns, Snowflake teamed up with Anaconda to deliver a vast number of packages to run directly in Snowflake. Because Anaconda maintains its own security practices around curation, patches, scanning and release security, customers can optionally rely on Anaconda to provide up-to-date packages. When building Snowflake Native Apps, you can use any package in the Snowflake conda channel. The packages in the conda channel are vetted and patched by Anaconda. Snowflake Native App publishing and upgrades are gated on a security scan, which checks for known security vulnerabilities in the application. Approval is only granted after the app passes the scan. 

Snowflake also scans packages and code included in Snowflake Native Apps for security concerns prior to making them available in Snowflake Marketplace.

Application consumers have always expected that the SaaS applications they purchase would be upgraded and kept secure by the application provider. Snowflake offers application providers a way to push updates to customers in an automated rollout, improving both user experience and security. 

Even though Snowflake Native Apps are installed and run in the application consumer’s account, the application provider still has control over the release cycle. To release a new version of the application, the builder can create a new release directive to push that update to a select set of users or to all users. This capability gives the provider confidence in knowing that all applications are patched (or upgraded) even though the application is deployed in many accounts.

Application consumers install a Snowflake Native App from a provider in their own account. Access to any data that application needs must be granted to the application by the consumer administrator, so it is well known what the application can access and use. In Snowflake Native Apps, the data doesn’t need to be moved or sent to a third party, which makes it much easier to be compliant with security requirements and data sovereignty rules.

When a provider publishes an application, it includes a manifest file. This manifest contains the permissions to be granted to the application, which can be reviewed by the application consumer during installation. By default, a Snowflake Native App has no permissions outside of the application itself, including data access or the ability to create database objects (tables, tasks, warehouses, etc).

Additional rights can be granted to the application, but that must be done by the application consumer administrators through explicit grants or references. Application code runs as a new application role, with owner’s rights, such that it can only access what that role has been granted to do. This means that the application can’t access data that the caller has access to—it must be explicitly granted permission. 

Snowflake Native Apps will automatically be kept up to date by the provider. The Snowflake Native App Framework has all the capabilities needed to upgrade in place and push updates to customers. This empowers the builder to keep all their installations patched, and the application consumers can rely on them always being up to date with the latest changes without any effort.

Snowflake Native Apps were developed to fulfill needs that were previously unmet in the industry, and Snowflake is uniquely positioned to provide applications from providers to consumers while protecting each party. Snowflake Native Apps leverage some of the biggest strengths in managed applications, provider-managed code and upgrades, and protecting the provider's code, along with the biggest strengths of traditional applications, which keep control and sovereignty of data in the consumers' hands.

Check out the Snowflake Native App Framework or use our Quickstart tutorial to develop a Snowflake Native app for yourself. We look forward to seeing what you build!