How to Manage “Package Pending Catalog” Events in JFrog Curation

Use Case:

When a package is newly published or pulled but is not yet cataloged, it enters a transient pending state. Because Curation has no data to evaluate the package against, you decide how your build pipelines, governance, and security workflows treat the package while the data is pending: wait for the analysis, fail fast, or let selected policies skip the package.

Curation has the following pending states, and you control each one separately in every policy:

• Pending Catalog update: The JFrog Public Catalog hasn't ingested the package yet.
• Pending on-demand data: The package is waiting for an On-Demand Curation scan to finish.

What Changed

Pending package handling used to be the Resolution of Pending Package Updates setting under Curation Settings > General, which applied to your entire JFrog Platform.

You now set it per policy, so you can block on some policies and skip on others, and route waiver requests to the right policy owners. Curation migrates existing policies automatically and applies the previous global value to both pending controls in every policy. For more information about the migration mapping, see General.

Configure Behavior Per Policy

Edit the policy and, in Step 5 of the wizard under Pending Catalog update, set the following checkboxes:

• Block for pending packages: Covers packages pending a Catalog update.
• Block for on demand pending packages: Covers packages pending on-demand data.

Each checkbox behaves as follows:

• Selected: The policy treats the pending state as a violation and blocks the package until its data arrives.
• Cleared: Curation skips the policy while the data is pending and still evaluates the package against your other policies.

Curation evaluates each policy on its own. If one policy blocks a pending package and another skips it, only the blocking policy blocks the package. A Dry Run policy always skips both pending states. For more information, see Pending Catalog Update Behavior.

On-Demand Curation

A package pending on-demand data is already being scanned, so the block resolves itself when the scan completes. You can't waive blocks of this kind. Instruct developers to retry the download after the scan finishes. Use Block for on demand pending packages only when you want downloads to fail fast rather than proceed without security data.

Waiver Scope and Duration

You can waive only a block on a package pending a Catalog update. The request applies to the specific blocking policy and follows that policy's waiver request settings.

Because the JFrog Public Catalog hasn't ingested the blocked package version, the waiver covers the entire package. It applies only while the package is pending Catalog analysis. The waiver expires in two days by default. When you approve the request, you must set an expiry: you can change the duration to any value from one to 365 days. Permanent waivers aren't allowed. After the JFrog Public Catalog ingests the package, the policy evaluates it in the regular way, based on its actual Catalog data. For more information, see Manage Waivers.

Recommended Approaches

Choose the approach that matches your organization's priorities:

• Security-oriented: Keep the policies blocking and instruct developers to wait for the package to be analyzed. The service level agreement (SLA) for packages pending cataloging is up to four hours, and updates typically arrive within two to three hours. As an alternative, developers can pin a locked version of the package that is already cataloged, so teams can keep working without compromising security.
• High-velocity: Let selected policies skip pending packages by clearing the relevant checkbox in Step 5. Curation still evaluates the package against your other policies.
• Waiver-based: Keep the policies blocking, and let developers request a waiver for the specific package that is holding up their build. Curation routes the request to the decision owners of the policy that blocked the package.