All About Policies


In This Lesson:

As discussed in IQ for Developers 100 - Foundations course, a policy in IQ is used to:

  • Serve as a set of security guidelines for open source governance with respect to security vulnerabilities and license compliance as determined by your organization

  • Easily identify and reduce risk

  • Define traits and relative risk of “bad” components

  • Help determine what action is required to remediate the risk

In addition, Sonatype Data Services provides an explanation of a vulnerability and its attack vector. If your applications do not utilize the component code exhibiting that vulnerability, you will understand that you are able to manage the risk associated with the component.

Implementing open source software (OSS) policies enables your organization to maximize the benefits of using open source. At the same time, these policies help to ensure that the security and legal risks resulting from using OSS components are properly managed. You’ll recall that policies are designed to make your job easier so that you, the developer, are not “on the hook” to make all the choices regarding which open source components are safest to use as building blocks within your application. Once policies are defined (by your organization), the decision points that are important in the selection process have already been made, and then it’s just a matter of taking action when violations appear.

Policy Hierarchy and Inheritance

While creation and management of policies for your organization are not a developer’s responsibility, it is helpful to understand the concepts of hierarchy and inheritance as they apply to policy management within Nexus IQ.


Policy management in Nexus IQ is built on the following hierarchy:

Root Organization







  • The top-level root organization acts as a container for organizations.

  • Next, those organizations act as containers for applications.


The root organization has no applications attached to it; applications can only be attached to a single organization.

For many teams, the structure of organizations and applications beneath the root organization mimics their own internal business structure. For example, each business unit might have its own organization below the root organization, and those organizations will have unique applications that apply to them.


Most organizations have rules around OSS component usage, or (if they’re new users of Nexus IQ) are seeking to establish them. As we discussed in the IQ for Developers 100 - Foundations course, policies help formalize these rules and actions to help provide guidelines for which components should be used.

The Inheritance policy setting applies only to organizations (including root), and the selection indicates which types of applications the policy should apply to.

Inheritance allows the organization to specify how a policy is implemented when there are multiple applications attached to a specific organization. There are two choices:

  • All Applications and Repositories in [organization] - The policy is applied to every application attached to the organization.

  • Applications of the specified Application Categories in Root Organization - The policy is applied only to applications that have specific application categories* assigned to them. With this setting, you select which application categories within the Root Organization to use.


Application Categories provide the ability to assign specific text and colors to applications to help group particular applications with similar attributes. They also provide a way to quickly identify the characteristics of an application. They are used primarily to enforce policies on certain application types and filter views based on those types.  For more information, view the help article on Application Categories.

Let’s think about how these policies might move through your organization. We refer to this flow as inheritance. For example:

  • A policy specified for the root organization will extend out to all organizations.

  • A policy specified for an organization will extend out to any attached applications (but does not flow upward to the root).

  • The inheritance hierarchy cannot be broken. It is therefore recommended that global policies remain generic and succinct (as set up in the out-of-box policies)

Of course, there’s opportunity for additional customization. However, the real advantage to inheritance is when you want to make changes that affect more than one organization or one application.

For example, if you managed everything at the application level, one change needed for all applications would need to be made to each one. That’s not hard if you have ten applications, but what if you have a hundred, or even thousands? The same applies for organizations.  It is recommended that you use the root organization to set policy that applies globally to all organizations.