CertSafari
    Snowflake SnowPro Specialty: Native Apps· Lessons

    Domain 3 · Lesson 7/12

    Native App Listings: DISTRIBUTION, Private vs Marketplace, and Listing Approval

    Publish to Snowflake Marketplace.

    10 min read
    3.67% of exam
    5 sources
    Published 5 Oct 2026
    Docs as of 4 Oct 2026

    What you will be able to do

    • Set an application package's DISTRIBUTION property to match the listing type you plan to create
    • Explain which actions start the automated security scan and which do not
    • Create a private listing or a Snowflake Marketplace listing in Provider Studio
    • Submit a Marketplace listing for approval, and fix the common reasons the Submit for Approval option is disabled
    • Describe how the security scan and review work, and meet the code readability, source map and dependency vulnerability requirements so an app is approved

    Key concept

    DISTRIBUTION property — A setting on an application package. It controls who you can list the app to. INTERNAL limits you to private listings inside your own organization and skips the security scan. EXTERNAL allows listings outside your organization, including Marketplace listings, and requires the app to pass the automated security scan.

    1.INTERNAL vs EXTERNAL: deciding who can get the app

    You don't share a Snowflake Native App directly. You share it through a listing, and the application package is the listing's data product. Before you open Provider Studio, the application package already limits which kinds of listing you can make. That limit is the DISTRIBUTION property, and it has two values.

    What each DISTRIBUTION value allows
    DISTRIBUTIONListings you can createAutomated security scan
    INTERNALOnly private listings within the same organization where the application package was createdNot performed
    EXTERNALPrivate listings outside the provider's organization, public listings, and Marketplace listingsPerformed on versions and patches

    You can set the property when you create the package or change it later. If you set it at creation time, every version or patch you add afterwards is scanned straight away.

    Creating an application package that can be listed outside the organizationsql
    CREATE APPLICATION PACKAGE hello_snowflake_package
      DISTRIBUTION = EXTERNAL;

    Release channels change what triggers the scan. When release channels are enabled, adding a version to the ALPHA or DEFAULT channel starts the scan, which covers that version's 10 most recent patches. Adding a version only to the QA channel does not start it. For this reason Snowflake recommends two packages. A development package set to INTERNAL lets you iterate without starting a security review on every change. A production package set to EXTERNAL holds only the versions that have passed your own security review.

    Checkpoint 1 of 5· Fill the gap

    Your app is ready to go beyond your organization. Which value completes this statement so the existing package can be listed externally and its patches are scanned?

    ALTER APPLICATION PACKAGE hello_snowflake_package
      SET DISTRIBUTION =  ? ;

    Sources12

    2.From approved version to published listing

    Publishing passes two separate gates. The first applies to the code. A version or patch in an EXTERNAL package must pass the automated security scan before anyone outside your organization can use it. The second applies to the listing. A Snowflake Marketplace listing must be approved by Snowflake before you can publish it. Between the two gates you set a release directive, which tells Snowflake which version or patch consumers get. You need a default release directive before you create the listing. If you use release channels, set it on the default release channel.

    Checkpoint 2 of 5· Put it in order

    Put these steps for getting a Native App onto the Snowflake Marketplace in order

    1. 1.Add a version or patch to an application package whose DISTRIBUTION is EXTERNAL
    2. 2.Publish the approved listing
    3. 3.Submit the listing to Snowflake for approval
    4. 4.Wait for the automated security scan to report APPROVED
    5. 5.Create a Marketplace listing in Provider Studio

    Sources31

    3.Private listing or Marketplace listing in Provider Studio

    You create both kinds of listing in Snowsight under Marketplace » Provider Studio » Create Listing. The setting that separates them is Who can discover the listing.

    - Only specified consumers creates a private listing. You choose the application package, write a description, and add the account identifiers of the consumers who should get it. If those accounts are in another region, you set up auto-fulfillment. You can then publish right away or save a draft. You don't need a provider profile for a private listing. - Anyone on the Marketplace creates a public Marketplace listing. You also choose Free or Paid under *How will consumers access the data product?* and then select Next. That creates a draft, not a live listing. Before you can submit it, you fill in each required section of the draft. Adding a pricing plan is optional and is covered in the monetization lesson.

    The security review and listing approval cover different listings. Every app published to consumers outside your organization must pass the security review, whether it goes out through a private listing or the Marketplace. Snowflake's separate listing approval applies only to Marketplace listings. A private listing inside your own organization, built on an INTERNAL package, needs neither gate.

    How the security scan and approval work. Snowflake scans new versions and patches automatically. The review copies the app to a dedicated scanning account, scans its files, and then either auto-approves the app or starts a manual review. The scanners look for code bugs and vulnerabilities, malware, and vulnerable dependencies. If the automated scan fails, Snowflake reviews the app manually, and the status ends as APPROVED or REJECTED. You can follow the status in the review_status column of SHOW VERSIONS IN APPLICATION PACKAGE, or in Snowsight under Projects » App packages. For a rejected version, open the app package to see the reason. Snowflake does not send a notification when an app is rejected, so check the status yourself. If you disagree with a rejection, you can appeal it with a severity 4 support ticket.

    Three code requirements decide most outcomes:

    - Readability. All app code must be human readable. Obfuscated code is rejected. - Source maps. Minified JavaScript is the one exception, and only if the app includes a source map file that recovers the un-minified code. - Dependencies. Libraries with critical or high CVEs must be updated to a secure version when one is available. Snowflake also rejects an app with a CVE that has a confirmed fix and a high integrity impact, or an EPSS score of 10 percent or higher.

    Approved Marketplace apps keep being monitored. If new issues turn up, you are notified and have 30 business days to patch the app.

    Checkpoint 3 of 5· Check yourself

    A provider shares an app with three named customer accounts in other organizations through a private listing. The app has passed the security scan. Which statement is true?

    Checkpoint 4 of 5· Exam question

    A provider wants to make a Snowflake Native App available only to two specific consumer accounts, without the app appearing in the Snowflake Marketplace catalog. Which listing configuration should the provider use?

    Sources34125

    4.Submitting a Marketplace listing for approval

    To submit, open the draft in the Listings tab and select Submit for Approval. If that option is disabled, check three things:

    1. You have configured every required section of the listing. 2. You are ACCOUNTADMIN or have the OWNERSHIP privilege on the data product attached to the listing. 3. All sample SQL queries attached to the listing pass validation.

    After Snowflake reviews the listing, its state becomes Approved or Denied. If it is denied, update the listing based on the feedback in the comments and submit it again. Either way, Snowflake emails the Business Contact and Technical Contact listed in the provider profile attached to the listing. Once the listing is approved, select Publish. You can then define a referral link that points consumers straight to the listing.

    Checkpoint 5 of 5· Match them up

    Match each term from the publishing process to its description

    Tap a term, then the definition that fits it.

    Sources3

    Exam traps

    Each one states something that sounds right. Open it to see what is actually true.

    1. 1.Every listing, private ones included, has to be submitted to Snowflake for approval before it can be published.Why is that wrong?

      Listing approval applies only to Marketplace listings. Private listings to accounts outside the organization still depend on the code passing the security scan, but they are not submitted for listing approval.

      Covered in Private listing or Marketplace listing in Provider Studio

    2. 2.When release channels are enabled, adding a version to any channel, including QA, starts the security scan.Why is that wrong?

      Only adding a version to the ALPHA or DEFAULT channel starts the scan. Adding a version only to QA does not.

      Covered in INTERNAL vs EXTERNAL: deciding who can get the app

    3. 3.Minified JavaScript is always rejected as obfuscated code.Why is that wrong?

      Minified JavaScript is allowed if the app includes a corresponding source map file that recovers the un-minified code.

      Covered in Private listing or Marketplace listing in Provider Studio

    Sources

    Every claim above is drawn from one of these pages, quoted as it was written on the date shown.

    1. 1.
      “INTERNAL indicates that a provider can only create a private listing within the same organization where the application package was created.”
      ↩︎ INTERNAL vs EXTERNAL: deciding who can get the app
      “The automated security scan is not performed when the DISTRIBUTION property is set to INTERNAL.”
      ↩︎ INTERNAL vs EXTERNAL: deciding who can get the app
      “EXTERNAL indicates that a provider can create listings outside the same organization where the application package was created.”
      ↩︎ INTERNAL vs EXTERNAL: deciding who can get the app
      “The provider can set the release directive for the application package.”
      ↩︎ From approved version to published listing
      “If the status is Rejected, select the app package to see the reason for the rejection.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “A provider can appeal the rejection by opening a severity 4 support ticket.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “The DISTRIBUTION property of an application package indicates the type of listing a provider can create”
      ↩︎ Key concept
      “Adding a version only to the QA release channel does not initiate the security scan.”
      ↩︎ Exam trap 2
      “the automated security scan is automatically run on the 10 most recent patches of every version in the application package.”
      ↩︎ Prediction
      “Await the results of the scan. If the scan is approved, the provider can continue with the process of publishing the app.”
      ↩︎ Checkpoint
    2. 2.
      “The production application package should have its DISTRIBUTION property set to EXTERNAL.”
      ↩︎ INTERNAL vs EXTERNAL: deciding who can get the app
      “All app code must be un-obfuscated, meaning that the code must be human readable.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “it must include a corresponding source map file that can be used to recover the un-minified code.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “All dependencies or libraries with critical or high common vulnerabilities and exposures (CVE) must be updated to a secure version, if available.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “it must include a corresponding source map file that can be used to recover the un-minified code.”
      ↩︎ Exam trap 3
    3. 3.
      “you must specify the default release directive that points to the version or patch of the app you are publishing.”
      ↩︎ From approved version to published listing
      “In the Who can discover the listing section, select Only specified consumers to privately share the listing with specific accounts.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “select Anyone on the Marketplace to publish the listing on the Snowflake Marketplace.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “Creating a provider profile is not required for private listings.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “You are the ACCOUNTADMIN or have the OWNERSHIP privilege for the data product attached to the listing.”
      ↩︎ Submitting a Marketplace listing for approval
      “an email notification is sent to both the Business Contact and Technical Contact email addresses”
      ↩︎ Submitting a Marketplace listing for approval
      “You only need to approve listings published to the Snowflake Marketplace.”
      ↩︎ Exam trap 1
      “You only need to approve listings published to the Snowflake Marketplace.”
      ↩︎ Checkpoint
      “After the listing is reviewed by Snowflake, the state changes to Approved or Denied.”
      ↩︎ Checkpoint
    4. 4.
      “All apps that are published to consumers must pass this security review.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “Auto-approves the app or initiates a manual review of the app.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
      “Snowflake does not send a notification if an app is rejected.”
      ↩︎ Private listing or Marketplace listing in Provider Studio
    5. 5.
      “Snowflake rejects an app if it has an EPSS score of ten percent or higher.”
      ↩︎ Private listing or Marketplace listing in Provider Studio

    Continue to page 2 of 2

    Native App Security Review: Readable Code, Source Maps, and CVE Scanning

    Spotted a mistake, or was something unclear? Tell us.