What you will be able to do
- Describe what the automated security scan (NAAAPS) checks and read its review_status values
- Make app code pass the readability rule, including source maps for minified JavaScript
- Apply Snowflake's three CVE criteria to an app's dependencies
- Appeal a rejected scan correctly and meet the remaining approval requirements on functionality and privileges
1.What the automated security scan does
Before an app reaches consumers outside the provider's organization, the code in the application package has to pass a security review. Snowflake's documentation names four risks the review guards against:
- Data exfiltration: copying consumer data out to external functions or logs. - Compute abuse: running unauthorized work, such as cryptomining, at the consumer's expense. - Ransomware: encrypting or corrupting consumer data and demanding payment to restore it. - Privilege escalation: trying to gain unauthorized permissions in the consumer's account.
The review is run by the Native App Anti-Abuse Pipeline Service (NAAAPS). It runs whenever a new version or patch of an app is created. NAAAPS copies the app to a dedicated scanning account, scans the files, updates the review status, and then either approves the app or starts a manual review. Its scanners look for bugs, anti-patterns and security vulnerabilities in the code, check for malware, and identify vulnerabilities in the app's dependencies. Scanning happens in a region tied to the provider's region. For example, the AWS US West (Oregon) region is scanned in Oregon, and the listed GCP regions are scanned in AWS US West (Oregon).
SHOW VERSIONS IN APPLICATION PACKAGE hello_snowflake_package;You can also see the result in Snowsight under Projects » App packages, in the Security Scan Status column. If a version is Rejected, select the package to read the reason. If the automated scan fails, the result isn't final: Snowflake reviews the package manually, and the status then becomes APPROVED or REJECTED. Snowflake does not send a notification when an app is rejected, so you have to check the status yourself.
Checkpoint 1 of 7· Match them up
Match each review_status value to what it means
Tap a term, then the definition that fits it.
These four values appear in the review_status column of SHOW VERSIONS. APPROVED is the status that lets you set the release directive.
“The review_status column displays the status of the automated review scan.”Source: docs.snowflake.com
Checkpoint 2 of 7· Exam question
A provider has an existing application package with several versions and patches already added under DISTRIBUTION = INTERNAL. The provider now changes the package to DISTRIBUTION = EXTERNAL to prepare for Marketplace publication. What happens as a result?
Correct answer: A — Snowflake immediately scans the 10 most recent patches of every version for security issues
- A. Switching an existing package to EXTERNAL distribution triggers Snowflake to scan the 10 most recent patches of every version already in the package, not just the latest one.
- B. The scan is not limited to a single most-recent patch; Snowflake scans up to 10 recent patches per version once EXTERNAL distribution is set.
- C. The scan runs when the DISTRIBUTION property changes, not when a consumer later installs the app, so this describes the wrong trigger.
- D. No manual support case is needed to start the scan; setting DISTRIBUTION to EXTERNAL triggers it automatically.
2.Code readability and source maps for minified code
The scanner can only review code it can read, so two code rules come first. First, everything the app runs must be inside the package. The app must not load or execute code from outside the application package, except for Snowflake-provided libraries. All library dependencies and setup code belong in the app version. Second, all code must be un-obfuscated, meaning a person can read it. Snowflake counts minified JavaScript as obfuscation, along with encryption and encoding.
The source map rule also affects appeals. If a scan rejects your app for obfuscated code, you can appeal only when the obfuscation is minified JavaScript, and the appeal must give the location of the matching source map. Encrypted or encoded code cannot be appealed. You have to remove it. A rejection for code loaded from outside the package is handled differently: to appeal it, you list all the data the app imports and explain how the app uses it.
Checkpoint 3 of 7· Check yourself
A scan rejects an app for obfuscated code. Which situation can be appealed?
Obfuscation appeals are accepted only for minified JavaScript, and the appeal must say where the source map is. Encoding and encryption have to be removed. Loading code from outside the package breaks a different rule.
“Appeals are only allowed for minified JavaScript. Please provide the location of the corresponding source map file to the minified JavaScript.”Source: docs.snowflake.com
Sources3
3.Dependency vulnerability scanning and the CVE criteria
The scanner reads the app's dependencies as well as its own code. The rule is that any dependency or library with a critical or high CVE must be updated to a secure version, if one exists. Snowflake's CVE Evaluation Criteria decide which CVEs actually lead to a rejection. Snowflake warns that the scan may not detect every CVE.
| Criterion | What it means |
|---|---|
| Confirmed fix | Snowflake reports only CVEs that have a confirmed fix according to the National Vulnerability Database (NVD) |
| High integrity impact | Under CVSS, a total loss of integrity, which allows unrestricted unauthorized changes to data |
| EPSS score of 10 percent or higher | The Exploit Prediction Scoring System estimates the vulnerability is likely enough to be exploited |
The confirmed-fix criterion is why the requirement says "if available": Snowflake reports only CVEs you can actually fix. Snowflake chose the EPSS threshold from data on current apps, so it can focus on the vulnerabilities most likely to be exploited. You can avoid surprises at scan time by reviewing third-party libraries during development and updating them at least once a quarter.
Checkpoint 4 of 7· Check yourself
Which of these is NOT one of Snowflake's three CVE evaluation criteria for a Native App?
The three criteria are a confirmed fix, high integrity impact and an EPSS score of 10 percent or higher. How recently the CVE was disclosed is not one of them.
“The CVE has an EPSS score of 10 percent or higher”Source: docs.snowflake.com
4.Rejections, appeals and monitoring after publication
If your app is rejected, you can either fix the code and add a new patch or appeal. To appeal, open a support case with severity 4, category General Administration and subcategory Other. Use the summary Appeal <App Name>, <Version>, <Patch>. In the description, give the app name, version and patch, paste in the rejection reason and code, and include everything that reason requires. You get one appeal per patch, and the whole appeal must be in a single case. Snowflake rejects a second appeal for the same patch and may reject an incomplete one without reviewing it. Appeals take 3–5 business days, and cases filed at a higher severity may be downgraded to 4. Snowflake does not share details of how the scan was carried out.
A CVE-based appeal must explain why the CVE can't be exploited in your app, include a reachability analysis report if you have one, and give a plan for updating to the fixed version. If you can't update, explain in detail why. The Snowflake Security team decides all appeals. Approval doesn't end the review, either. Published apps get periodic image security analysis. If it finds a problem, Snowflake notifies the provider, who has 30 business days to patch the app or 15 days to request an exception.
Checkpoint 5 of 7· Check yourself
A patch was rejected for a high CVE. The provider filed an appeal that left out the reachability analysis. Can they open a second, more complete appeal for the same patch?
Snowflake allows one appeal per patch, and all the information must go in that single case. CVE rejections can be appealed, and a higher severity is simply downgraded to 4.
“Snowflake allows one appeal per patch of an app.”Source: docs.snowflake.com
5.The other requirements for app approval
Readable code and patched dependencies are only part of what approval requires. The remaining requirements cover what the app does and what it asks for:
Disclose in the listing - All of the app's functionality and features. - Every Internet endpoint and URL the app connects to. - All external functions. - Any consumer data the app logs, collects or stores. - All installation and setup instructions.
Behave safely - Work as the listing describes. - Never store or require plain-text customer secrets. - Use HTTPS with a valid TLS certificate for any Internet traffic. - Never cause harm, such as data leakage, excessive resource consumption or arbitrary code execution. - Make every connection authenticate through a Snowflake-provided method first.
Request privileges carefully - Declare all privileges on all objects, and all API integrations, in the manifest file. - Ask only for the minimum privileges the app needs.
The Marketplace adds its own requirements on top of these. Snowflake publishes separate guidelines for listing apps there.
Checkpoint 6 of 7· Check yourself
Which design is most likely to get an app rejected in security review?
Apps must not store or require plain-text customer secrets. The other three options follow the requirements on manifest disclosure, endpoint disclosure and authentication order.
“Apps must not store or require any plain text customer secrets.”Source: docs.snowflake.com
Checkpoint 7 of 7· Exam question
According to Snowflake's security requirements for Native Apps, what is required of all application code, including JavaScript?
Correct answer: A — The code must be un-obfuscated and human readable in its submitted form
- A. Snowflake requires that all app code, including JavaScript, be un-obfuscated and human readable so it can be reviewed as part of the security scan.
- B. There is no requirement to avoid JavaScript in favor of Python; the readability rule applies regardless of programming language used.
- C. Snowflake's published readability requirement concerns un-obfuscated code, not digital signing with a provider certificate.
- D. Compiling to WebAssembly would make the code less readable, which conflicts with the human-readability requirement rather than satisfying it.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If the security scan rejects an app, Snowflake emails the provider, just as it does when a listing is denied.Why is that wrong?
Snowflake sends no notification when an app is rejected in security review. You have to check review_status or Snowsight. The email to the Business and Technical Contacts is sent only for listing approval decisions.
Covered in What the automated security scan does
2.Minified JavaScript is banned outright, so a Native App can only ship unminified bundles.Why is that wrong?
Minified JavaScript counts as obfuscation, but it is allowed if the app includes a matching source map that can recover the un-minified code.
Covered in Code readability and source maps for minified code
3.Every CVE in a dependency must be fixed, even when no fixed version of the library exists.Why is that wrong?
The requirement is to update critical or high CVEs to a secure version if one is available, and Snowflake reports only CVEs with a confirmed fix in the NVD.
Covered in Dependency vulnerability scanning and the CVE criteria
Practise it for real
Create an externally distributable application package and watch its automated security scan status
1.Run CREATE APPLICATION PACKAGE hello_snowflake_package DISTRIBUTION = EXTERNAL;
Why: With EXTERNAL set at creation, every version or patch you add later is scanned straight away
You should see: The application package is created with external distribution
2.Add a version or patch to the package from your app files, making sure all code is inside the package and any minified JavaScript has its source map
Why: Adding a version or patch to an EXTERNAL package starts the automated scan
You should see: A new version or patch appears in the package
3.Run SHOW VERSIONS IN APPLICATION PACKAGE hello_snowflake_package; and look at the review_status column, or open Projects » App packages in Snowsight
Why: Snowflake sends no notification on rejection, so you have to check the status yourself
You should see: review_status moves from IN_PROGRESS to APPROVED or REJECTED; if REJECTED, select the package in Snowsight to read the reason
Stuck? Get a nudge
If you only see NOT_REVIEWED, check that DISTRIBUTION is EXTERNAL. INTERNAL packages are never scanned.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“This automated security review occurs when a new version or patch of an app is created.”
↩︎ What the automated security scan does“Identify vulnerabilities in app dependencies.”
↩︎ What the automated security scan does“When publishing an app to Snowflake Marketplace, providers must consider additional requirements and best practices.”
↩︎ The other requirements for app approval“Snowflake does not send a notification if an app is rejected.”
↩︎ Exam trap 1 - 2.
“When an automated security scan fails, the Snowflake manually reviews the application package.”
↩︎ What the automated security scan does“A provider can appeal the rejection by opening a severity 4 support ticket.”
↩︎ Rejections, appeals and monitoring after publication“given 30 business days to patch the app or can request an exception within 15 days”
↩︎ Rejections, appeals and monitoring after publication“The review_status column displays the status of the automated review scan.”
↩︎ Checkpoint - 3.
“All app code must be un-obfuscated, meaning that the code must be human readable. This requirement includes minified JavaScript code.”
↩︎ Code readability and source maps for minified code“Your app must not load or execute any code from outside the application package except Snowflake-provided libraries.”
↩︎ Code readability and source maps for minified code“All dependencies or libraries with critical or high common vulnerabilities and exposures (CVE) must be updated to a secure version, if available.”
↩︎ Dependency vulnerability scanning and the CVE criteria“Review and update all third-party libraries in the app at least once a quarter.”
↩︎ Dependency vulnerability scanning and the CVE criteria“All app installation and setup instructions must be included in the app listing.”
↩︎ The other requirements for app approval“Apps should only ask for the minimum set of privileges needed for the app to function.”
↩︎ The other requirements for app approval“If an app needs to use minified JavaScript code, it must include a corresponding source map file”
↩︎ Exam trap 2“it must include a corresponding source map file that can be used to recover the un-minified code.”
↩︎ Prediction“Apps must not store or require any plain text customer secrets.”
↩︎ Checkpoint - 4.
“A high integrity impact indicates a total loss of integrity or complete loss of protection”
↩︎ Dependency vulnerability scanning and the CVE criteria“Snowflake provides actionable information and reports only on CVEs that have a confirmed fix according to the National Vulnerability Database (NVD).”
↩︎ Exam trap 3“The CVE has an EPSS score of 10 percent or higher”
↩︎ Checkpoint - 5.
“All appeals have a turnaround time of 3-5 business days (Monday to Friday).”
↩︎ Rejections, appeals and monitoring after publication“Appeals are only allowed for minified JavaScript. Please provide the location of the corresponding source map file to the minified JavaScript.”
↩︎ Checkpoint“Snowflake allows one appeal per patch of an app.”
↩︎ Checkpoint - 6.
“These guidelines define the enforced standards for publishing applications, both Snowflake Native Apps and Connected Applications, on Snowflake Marketplace.”
↩︎ The other requirements for app approval