What you will be able to do
- Explain the risks a Native App poses to a consumer account and how NAAAPS scanning and manual review address them
- Apply the code, dependency and secrets requirements an app must meet before a version can be published
- Choose INTERNAL or EXTERNAL distribution for development and production application packages
- Describe the extra review, isolation and approval that apply when a Native App runs Snowpark Container Services
Key concept
Reviewed-before-shared — A Native App runs provider code inside the consumer's account. Snowflake therefore requires every app published to consumers to pass a security review of its code, dependencies and (for container apps) images before consumers can install it.
1.Why apps are scanned: the threat model and NAAAPS
A Snowflake Native App is code written by a provider that runs inside a consumer's account, next to the consumer's data. Snowflake names four risks that this creates. Data exfiltration: an app copies consumer data out through external functions or logs. Compute abuse: an app runs unauthorized work, such as cryptomining, that the consumer pays for. Ransomware: an app encrypts or corrupts data and demands payment. Privilege escalation: an app tries to gain permissions it was not given.
The control for these risks is the Native App Anti-Abuse Pipeline Service (NAAAPS). It runs every time a new version or patch is created. NAAAPS copies the app to a dedicated scanning account and scans the app's files. It looks for bugs, anti-patterns and vulnerabilities in the code, scans for malware, and checks the app's dependencies for known vulnerabilities. It then either approves the app automatically or sends it to manual review. A manual review can approve or reject the app. Snowflake sends no notification when an app is rejected, so providers check the review status in Snowsight.
Checkpoint 1 of 6· Put it in order
Put the automated security review steps in the order NAAAPS performs them after a provider creates a new version or patch.
- 1.Scan the files associated with the app and update the security review status
- 2.Copy the app to a dedicated Snowflake account used to scan apps
- 3.Auto-approve the app or initiate a manual review
The app is first copied to an isolated scanning account, then its files are scanned, and only after that is it approved automatically or sent to manual review.
“Copies the app to a dedicated Snowflake account used to scan apps.”Source: docs.snowflake.com
Sources1
2.Securing app code, third-party libraries and secrets
NAAAPS can only scan what is in the package. That is the reason behind the first code rule: an app must not load or run code from outside the application package, except Snowflake-provided libraries. All library dependencies and setup code have to be part of the version itself. A dependency fetched at runtime would bypass the review. All code must also be un-obfuscated, meaning human-readable. As the prediction showed, minified JavaScript is allowed only when it comes with a source map.
Third-party packages. Any dependency with a critical or high CVE must be updated to a secure version when one exists. Snowflake prioritizes CVEs according to its CVE Evaluation Criteria policy, which applies to every app under security review. As SDLC practice, Snowflake recommends reviewing app code for vulnerabilities before you create a version, and reviewing and updating all third-party libraries at least once a quarter.
Secrets and data. Apps must not store or require plain-text customer secrets. Secrets and sensitive data should be protected with encryption and access controls. Providers are also responsible for making sure that no personal, sensitive, export-controlled or regulated data ends up in any file in the application package. All Internet traffic from the app must use HTTPS with a valid TLS certificate.
Checkpoint 2 of 6· Exam question
A consumer admin has installed a Native App that exposes the application roles `viewer` and `admin`. Analysts must use the app's dashboards, while only the security team may change its configuration. What should the admin do?
Correct answer: C — Grant the `viewer` application role to the analyst account role, and grant the `admin` application role only to the security team's account role
- A. This is incorrect. Usage on the application object does not expose its internal objects; access to those is controlled by privileges granted to application roles inside the app. It would also not separate viewer from admin duties.
- B. This is incorrect. The app's internal roles are separate from account roles and cannot be granted by consumers. Only application roles the app exposes can be granted to account roles.
- C. This is correct. Application roles are the app's interface to consumers and are granted to account roles to give differentiated access. Granting only `viewer` to analysts keeps configuration functions limited to the security team.
- D. This is incorrect. IMPORTED PRIVILEGES applies to databases created from shares, not to installed applications. It would not map to the viewer and admin application roles.
Checkpoint 3 of 6· Check yourself
A provider wants the app to download its latest Python helper module from the provider's GitHub at startup so that fixes ship without new versions. Why does this violate the code requirements?
All app code, including dependencies, must be inside the app version so that it can be scanned. Code loaded at runtime from elsewhere escapes the review.
“Your app must not load or execute any code from outside the application package except Snowflake-provided libraries.”Source: docs.snowflake.com
Sources2
3.Packaging and sharing: INTERNAL vs EXTERNAL distribution
Because every new version or patch triggers a scan, Snowflake recommends two application packages. The development package has DISTRIBUTION set to INTERNAL. It is not distributed to external consumers or sent to Snowflake for scanning, so developers can iterate without triggering a review each time. The production package has DISTRIBUTION set to EXTERNAL. It is the package that goes to Snowflake for scanning and approval and then to consumers. Only versions that have passed the provider's own security review should be added to it.
| Package | DISTRIBUTION | Scanned by Snowflake? | Purpose |
|---|---|---|---|
| Development | INTERNAL | No | Rapid iteration and testing |
| Production | EXTERNAL | Yes, then released to consumers | Publishing approved versions |
Setting a package up for external sharing automatically shares the app's code with Snowflake for scanning. That scan runs in a mapped region. Most AWS regions are scanned in the same region. Azure regions are grouped into three scanning regions. Listed GCP regions are scanned in AWS US West (Oregon). Apps can be published as private listings or on Snowflake Marketplace, and Marketplace adds its own listing guidelines. Every listing must also tell consumers about all app functionality, every Internet endpoint the app connects to, every external function, and any consumer data the app logs, collects or stores.
Checkpoint 4 of 6· Check yourself
A team wants to test dozens of builds a day without each one going through Snowflake's security scan. What should they do?
Patches are scanned just like versions. An INTERNAL development package is not sent to Snowflake for scanning, which keeps iteration fast.
“It should have its DISTRIBUTION property set to INTERNAL.”Source: docs.snowflake.com
4.Implications of running a Native App in Snowpark Container Services
An app that ships container images has a larger attack surface, and Snowflake responds in four ways. Image scanning: tools scan the container images for known vulnerabilities and violations of security best practices. Network isolation: each app with containers runs in its own isolated network environment. Snowflake monitors and filters egress to detect suspicious traffic, and the provider must declare every external endpoint in the manifest, which is itself reviewed. Scoped data access: the app can reach only the data and resources it has been granted. Consumer data is protected by encryption in transit and at rest and by fine-grained access controls.
Provider approval: before a provider can create a public or private listing for an app with containers, the Snowflake Product Security team must approve that provider. If the provider has not been approved and sets DISTRIBUTION=EXTERNAL on a package with containers, Snowflake returns error 093197. The provider then submits a security questionnaire about its security practices and compliance readiness. Only after approval does the app go through the automated scan, which combines the normal app scan with a scan of the container images. Scan time grows with the number and size of images:
| App size | Approximate time to complete scan |
|---|---|
| Five images or fewer / smaller than 40 GB | Less than 8 hours |
| Ten images or fewer / smaller than 70 GB | Less than 24 hours |
| Ten images or more / larger than 70 GB | 2 business days or more |
Snowflake also lists extra best practices for container apps. Limit external dependencies to reduce supply-chain risk. Harden images with minimal base images and remove unnecessary packages. Encrypt communication between containers and to external systems. Log container activity and data access. Patch images regularly. Request only the privileges the app needs.
Checkpoint 5 of 6· Exam question
A provider wants to publish a Native App on the Snowflake Marketplace for consumers outside its organization. Which sequence correctly gets a new version through the mandatory security review?
Correct answer: B — Set DISTRIBUTION = EXTERNAL on the application package, add the version, and wait for the scan to approve it before setting a release directive on it
- A. This is incorrect. Internal distribution is meant for same-organization use and does not publish to outside consumers, and consumers have no command for scanning provider code. The review is run by Snowflake against the provider's version before release.
- B. This is correct. External distribution makes each new version subject to the Native App Anti-Abuse Pipeline Service scan, and the release directive can only point at a version that has passed (automatically or after manual review). Skipping this order leaves the version unpublishable.
- C. This is incorrect. Trust Center scanners evaluate account configuration and do not gate application package versions. The Native App review happens before a version can reach consumers, not after installation.
- D. This is incorrect. MANAGE RELEASES is a provider-side privilege for managing release directives on an application package. Consumers do not approve scan results; Snowflake's pipeline and reviewers do.
Checkpoint 6 of 6· Check yourself
Which statement about a Native App with containers is supported by Snowflake's documentation?
Container apps run in isolated networks with controlled egress, and every external endpoint must be declared in the reviewed manifest. Images are scanned, and the provider needs prior approval from Product Security.
“App providers are required to explicitly declare all external endpoints in the application manifest, which undergoes a security review.”Source: docs.snowflake.com
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If my app is rejected in manual review, Snowflake will email me.Why is that wrong?
Snowflake does not notify the provider of a rejection. Providers must check the review status in Snowsight.
Covered in Why apps are scanned: the threat model and NAAAPS
2.Any minified JavaScript in an app counts as obfuscation and causes rejection.Why is that wrong?
Minified JavaScript is acceptable when a source map that recovers the un-minified code is included.
Covered in Securing app code, third-party libraries and secrets
3.An app with containers can be published as soon as its automated scan passes.Why is that wrong?
The provider must first be approved by Snowflake Product Security through a security questionnaire before it can list an app with containers.
Covered in Implications of running a Native App in Snowpark Container Services
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Data exfiltration: Malicious apps could copy consumer data to external functions or logs.”
↩︎ Why apps are scanned: the threat model and NAAAPS“This automated security review occurs when a new version or patch of an app is created.”
↩︎ Why apps are scanned: the threat model and NAAAPS“When configuring a Snowflake Native App to be shared externally, providers automatically share the code in app with Snowflake for scanning.”
↩︎ Packaging and sharing: INTERNAL vs EXTERNAL distribution“All apps that are published to consumers must pass this security review.”
↩︎ Key concept“Snowflake does not send a notification if an app is rejected.”
↩︎ Exam trap 1“Copies the app to a dedicated Snowflake account used to scan apps.”
↩︎ Checkpoint - 2.
“All dependencies or libraries with critical or high common vulnerabilities and exposures (CVE) must be updated to a secure version, if available.”
↩︎ Securing app code, third-party libraries and secrets“Apps must not store or require any plain text customer secrets.”
↩︎ Securing app code, third-party libraries and secrets“Review and update all third-party libraries in the app at least once a quarter.”
↩︎ Securing app code, third-party libraries and secrets“The production application package should have its DISTRIBUTION property set to EXTERNAL.”
↩︎ Packaging and sharing: INTERNAL vs EXTERNAL distribution“it must include a corresponding source map file that can be used to recover the un-minified code”
↩︎ Exam trap 2“it must include a corresponding source map file that can be used to recover the un-minified code”
↩︎ Prediction“Your app must not load or execute any code from outside the application package except Snowflake-provided libraries.”
↩︎ Checkpoint“It should have its DISTRIBUTION property set to INTERNAL.”
↩︎ Checkpoint - 3.
“Each app with containers runs in its own isolated network environment, with controlled access to external systems and services.”
↩︎ Implications of running a Native App in Snowpark Container Services“This scan includes a normal app security scan and a scan of the container images included in the app.”
↩︎ Implications of running a Native App in Snowpark Container Services“they must be approved by the Snowflake Product Security team”
↩︎ Exam trap 3“App providers are required to explicitly declare all external endpoints in the application manifest, which undergoes a security review.”
↩︎ Checkpoint