Reference Policies

The reference policy set may be downloaded and imported manually. This replaces the current policies without starting over with server configuration.

The following datatypes are included in the reference policy:

policies, actions, notifications, labels (Application Categories), policyViolationGrandfatheringAllowed (Legacy Violations), licenseThreatGroups, tags (Component Labels),  policyTags

See this knowledge base article on how to export policy.

Warning
Importing the reference policy is destructive to existing data in Lifecycle.
Importing policies deletes the references for policy violations, waivers, application categories, component labels, legacy violations, notifications, actions, and license threat groups.

Included Policies in the Reference Policy Set

The reference policy set includes a baseline set of Sonatype-provided policies across multiple policy types. These policies are intended to address common risk scenarios and provide a starting point for policy configuration.

Policies included in a reference policy set may span:

• Component policies
• Security policies
• License policies
• Architecture policies (where applicable)

Note
Not all policies visible in the Lifecycle UI are introduced through reference policy import. Some policies may be introduced in later Lifecycle releases and may not exist in earlier reference policy versions.

Methods of Policy Introduction

Policies may exist in a Lifecycle instance through different introduction methods. Understanding how a policy was introduced can help determine how it should be managed or updated.

Policies Introduced During Product Upgrades

Some policies are added automatically during Lifecycle upgrades when new baseline risk detections are introduced. These policies are created directly in the system and do not require importing a reference policy JSON file.

Examples include:

• New risk-based detections introduced to address emerging security, license, or maintenance concerns.
• Policies such as Component End of Life (EOL) that were introduced as part of a product release.

Policies introduced during upgrades appear in the Lifecycle UI alongside other policies. Depending on the Lifecycle version and reference policy file in use, these policies may not be present in earlier reference policy versions.

Policies Introduced via Reference Policy Import

When a reference policy JSON file is imported:

• Existing policies are replaced.
• The imported file defines exactly which policies, actions, and notifications are created.
• Policies included in the file are recreated as defined in that version.

The set of policies included depends on the Lifecycle release version associated with the reference policy file.

Manually Created or Modified Policies

Policies can also exist that were created manually or modified after import or upgrade.

Manually created or modified policies are not added to reference policy files and will be removed if a reference policy set is imported.

Reference Policy Versions by Lifecycle Release

Each Lifecycle release aligns to a specific reference policy file. Use the version that matches your Lifecycle release to understand which policies are included.

New Policies Introduced in reference-policies-v8.json

Reference-policies-v8.json includes all policies from reference-policies-v7.json, in addition to the following new policies:

• AI-ML-Derivative-Model: This policy identifies AI/ML models that are derivatives of a foundation model, using the DerivativeAiModel constraint.
• Component End of Life: This policy identifies components whose latest version has reached end of life and is no longer supported.
• Security-Malicious: This policy identifies components where the security vulnerability category is Malicious Code and any system may be compromised when such a vulnerability is present.

Policies Included in reference-policies-v7.json

The following policies are included in reference-policies-v7.json:

• Architecture-Cleanup: This policy identifies common testing and build libraries that should not be distributed with an application.
• Architecture-Quality: This policy identifies components that are older or not popular, which may indicate quality or maintenance risk.
• Component-Similar: This policy identifies components that have been modified from the original source.
• Component-Unknown: This policy identifies components that were not found in Sonatype data and are not marked as proprietary.
• Integrity-Rating: This policy identifies components whose Integrity Rating is Pending or Suspicious in order to surface potential release‑integrity issues.
• License-Banned: This policy identifies components whose effective license is in the Banned license threat group.
• License-Commercial: This policy identifies components whose effective license is in the Commercial license threat group.
• License-Copyleft: This policy identifies components whose effective license is in the Copyleft license threat group.
• License-Modified Weak Copyleft: This policy identifies components whose effective license is in the Modified Weak Copyleft license threat group.
• License-Non-Standard: This policy identifies components whose effective license is in the Non‑Standard license threat group and may require legal review.
• License-Threat Not Assigned: This policy identifies components whose effective license has not been assigned to any license threat group.
• Security-Namespace Conflict: This Repository Firewall policy identifies component requests where a proprietary name conflict is present, helping detect namespace‑confusion scenarios.
• Security-Critical: This policy identifies vulnerabilities with very high CVSS severity that are generally exploitable when the component is on the classpath of the running executable.
• Security-High: This policy identifies vulnerabilities with high CVSS severity that are generally exploitable when the component is on the classpath of the running executable.
• Security-Low: This policy identifies vulnerabilities with low risk of exploitation, while noting that multiple low issues may be chained into more severe exploits.
• Security-Medium: This policy identifies vulnerabilities that are generally exploitable through specific component functionality or misconfiguration.

Policy Visibility by Policy Type

A policy’s location in the Lifecycle UI depends on the type of risk it detects. Policies introduced automatically or through reference policy import may appear in different sections of the UI based on their classification.

For example, policies related to component maintenance or lifecycle status, such as Component End of Life (EOL), appear under Component Policies rather than Security Policies.

Importing Reference Policies

Importing policies requires the Owner role at the root organization.

1. From the Actions menu, select Import Policies.
2. Select the Choose File button and select the policy.json file in the file browser.
3. Select Import.