Create Policies
Curation is based on a set of defined policies. To create a new curation policy, the Curation Admin must choose the remote repositories to which the policy applies, the policy condition (only 1 condition can be defined for each policy), and the action to be performed when the policy is violated. In addition, any exceptions to the policy can be defined in a waiver.
This is a basic procedure outlining the steps to create a policy. In the How-Tos section we provide more scenario specific procedures for creating policies.
Do the following:
- Go to Administration > Curation > Policies Management.
- Click Create Policy and follow the wizard:
- Step 1: Enter a name for the policy (max 50 characters, no special symbols).
- Step 2: Define the scope:
- Organization-wide: Applies to all curated repositories. You can exclude specific repositories, groups, or projects.
- Specific projects: Select one or more projects. For more information, see Apply Policy to Projects.
- Specific remote repositories: Select one or more curated remote repositories or package types to enforce the policy on.
- Selected groups: Enforce the policy only on selected JFrog Platform Access groups. Requires Enforce policy on cached packages to be enabled.
- Step 3: Choose a condition from the predefined or custom options.
For a full detailed list of the conditions, see here.
Examples:- Block based on CVSS score thresholds.
- Block non-official Docker images.
- Block packages not labeled as "allowed."
- Block package versions that have reached End of Life (EOL).
- Block a cached package whose checksum doesn't match JFrog Catalog. For more information, see Package integrity violation.
- Block or allow packages based on custom licenses from JFrog Catalog. For a step-by-step guide, see How to Create Curation Policies for Custom Licenses.
- Step 4 (optional): Add waivers to exclude specific packages or versions.
- Step 5: Define the action as Block or Dry Run, set the behaviors for packages whose data is pending, and configure email notifications. The pending behaviors are Block for pending packages and Block for on demand pending packages.
- Step 6 (optional): Enable Share with Federation to propagate this policy to all connected follower Instances via Curation Federation. This option is available only for policies with scope All Curated or Package Types. Share with Federation requires Curation Federation to be enabled on your platform.
Learn more here.
Pending Catalog Update Behavior
A package that the JFrog Public Catalog hasn't ingested yet is in a Pending Catalog Update state. A package that is waiting for an On-Demand Curation scan is in a pending on-demand state. Each policy decides on its own whether to block or skip a package in these states.
In Step 5 of the wizard, under Pending Catalog update, select or clear the following independent checkboxes. Each one covers a different pending state, so selecting one doesn't affect the other.
| Checkbox | Applies to | When a package is blocked |
|---|---|---|
| Block for pending packages | Packages that the JFrog Public Catalog hasn't ingested yet. | Developers can request a waiver against the policy, or wait for the Catalog to analyze the package. |
| Block for on demand pending packages | Packages that are waiting for an On-Demand Curation scan. | Developers must wait for the Xray scan to finish and retry the download. A large artifact can time out on that request. Retry within a few minutes. Waivers are not available. See On-Demand Curation. |
- Selected: The policy blocks the package while its data is pending.
- Cleared: The policy is skipped while the data is pending, and the package is still evaluated against your other policies.
Only a block on a package pending a Catalog update can be waived. For more information, see Manage Waivers.
Note
Both checkboxes are available only for policies whose action is Block. A Dry Run policy always skips both pending states and never blocks a package in a pending state.
How Pending Packages Are Evaluated
Each policy is evaluated independently. If one policy blocks a pending package and another skips it, the package is blocked only by the blocking policy. When the package is pending Catalog analysis, a waiver request is routed to the decision owners of that blocking policy.
Migration from Global Setting
This per-policy behavior replaces the platform-wide Resolution of Pending Package Updates setting. Existing policies are migrated automatically.
| Previous global setting | Migrated policy behavior |
|---|---|
| Always allow (Not recommended) | Both options cleared to skip pending packages |
| Always block | Both options selected to block pending packages |
| Allow if no blocking policy on remote | Both options selected to block pending packages |
Dry Run policies are migrated with both options cleared.
Policy Scope Options
When creating a policy, you choose how broadly or narrowly it should be applied. The available scope options are:
| Scope | Description |
|---|---|
| Organization-wide | Enforces the policy across all current and future curated repositories. You can exclude specific repositories, groups, or projects. |
| Specific projects | Enforces the policy on curated repositories that belong to the projects you select. Shared repositories aren't covered. To learn how to split a shared repository by project, see Project-Aware Download Requests. |
| Specific remote repositories | Enforces the policy only on the remote repositories you select. |
| Repositories package type | Enforces the policy on all repositories matching the selected package types (e.g., npm, Maven, PyPI). |
| Selected groups | Enforces the policy based on the requesting user's JFrog Platform Access group membership. Only users belonging to the selected groups are subject to the policy. |
Apply Policy to Projects
You can limit a policy to one or more projects. Curation resolves each project's repositories from JFrog Artifactory.
A project-scoped policy covers a curated repository when the following are true.
- The repository belongs to a project you selected.
- The repository isn't shared into that project.
A shared repository stays outside a project-scoped policy.
Curation saves the policy when at least one selected project has a curated repository that isn't shared. If the selected projects have no curated repositories, or every curated repository is shared, Curation doesn't save the policy.
On an organization-wide policy, you can exclude projects as well as repositories and groups. A repository that an excluded project lists isn't covered. That includes a repository shared into the excluded project.
Note
If project lookup fails during a download, a project-scoped policy doesn't apply to that repository. An organization-wide policy still applies, and Curation doesn't exclude the repository for that download.
For more information about what you can change while a project is selected, see Set User Roles and Permissions.
Apply Policy to a Group of Users
Curation supports scoping policies by JFrog Platform Access Groups, enabling organizations to apply different policy behaviors to different teams or user segments even when they share the same repositories.
Group-based policy scope requires Enforce policy on cached packages to be enabled.
Navigate to Administration > Curation > Settings and enable Curation for Cached Packages before using this scope.
How It Works
When a user requests to download a package, Curation resolves the user's Access group memberships and evaluates whether the policy applies:
- Selected groups (include): The policy is enforced only for users who belong to at least one of the selected groups. Users outside those groups are not affected.
- Excluded groups: When using the Organization-wide scope, you can exclude specific groups. Users belonging to an excluded group are exempt from the policy, even if it would otherwise apply.
If a user belongs to both an included and an excluded group, the exclusion takes precedence and the policy is not enforced for that user.
When to Use Group-Based Scope
Group-based scoping is useful when a single repository serves multiple teams with different security requirements. For example:
| Group | Policy behavior |
|---|---|
| Dev Team A | Excluded from the policy — allowed to download packages meeting internal maturity criteria |
| Dev Team B | Blocked if the package contains a critical CVE |
| Compliance Team | Restricted to approved package versions only |
Configuration
- Go to Administration > Curation > Policies Management.
- Click Create Policy.
- In the Scope step, select Selected groups.
- Choose one or more Access groups from the group selection modal.
- Continue with the remaining policy wizard steps (condition, waivers, actions).
To exclude groups from an Organization-wide policy:
- In the Scope step, select Organization-wide.
- Click Exclude Groups and select the groups to exempt.
Limitation for NPM Packages When using Compliant Version together with group-based policy enforcement and cached package blocking, cache behavior may cause multiple groups to receive the same compliant version that was retrieved by the first user. Curation will still evaluate the download request and block it if it conflicts with the policies of the requesting group.
Updated 12 days ago
