IQ Server Grandfathering

IQ Server | Reading time: 7 minutes

In this guide:

Overview

You have to start remediating risk to get the most out of IQ Server, and the best approach is to let grandfathering help with prioritization. With grandfathering, you can see the existing risk, prioritize what you want to fix, and then focus on any new risks while working your way through the grandfathered violations.

If you’re new to IQ Server, it can be hard to prioritize the violations reported by Lifecycle when you first onboard applications. With a new Lifecycle installation, you’ll have violations that existed before adoption. Enabling the grandfathering feature lets you focus on actions and remediation for newly discovered risk, while managing your backlog of existing violations — those that existed before Lifecycle was adopted. This means that existing violations won’t cause a policy action (for example fail the build) but if a new violation comes in after grandfathering, then the policy action takes effect.

Videos

IQ Server Grandfathering Overview Video

 

Policy Grandfathering Configuration Demo with Jamie Whitehouse (IQ Server Product Owner)

Audience

Nexus IQ Server Policy Administrators

Prerequisites

IQ Server release 50 (or later).

Desired Outcomes

This guide should take you about 10 minutes to read, and by the end you’ll be able to:

  • Explain what grandfathering is, how it works, and why you want to use it.
  • Understand the difference between grandfathering and waiving.
  • Effectively manage new application onboarding with grandfathering enabled.

What is Grandfathering?

This IQ Server feature lets you grandfather (acknowledge) existing issues found in newly onboarded applications. The main objective of grandfathering is to provide an easier route to automated enforcement, which is difficult to achieve if there’s a large backlog of existing issues. When grandfathering is enabled, existing violations won’t cause a policy action, but if a new violation is introduced the policy action is applied.

The goal of grandfathering is not to hide risk, but rather to provide an easier path to onboarding. When you use the grandfathering feature, your violations are still there, but you can more easily focus on the most important (critical) violations.

Here’s an example of how new application onboarding might work with grandfathering enabled:

  1. A policy administrator configures policies with a build action of fail and enables grandfathering at the root organization level.
  2. You run an evaluation to assess components A and B revealing violations A and B; however, since grandfathering is enabled, they are automatically deferred. No policy action is taken during the first evaluation, allowing the build to pass.
  3. Component C is added later and that shows new violations and fails the build.

In the above example, the first evaluation is used to assess an application. Although there are violations, they represent existing risk and are marked as grandfathered. The build continues to pass with these violations until the new component is added revealing new violations that fail the build.

You can also apply grandfathering at the application level to existing policy violations. This works basically in the same way as new app onboarding, but can be applied at any time to any application. For example, violations could show up on an existing app due to things like policy changes. You could then apply grandfathering to the existing application so you can easily see the critical violations, and then let your team focus on remediating those risks. Any further evaluations will treat these policy violations as grandfathered, but the action won’t perform a new evaluation. This is only available if grandfathering is enabled or inherited for the current application.

Difference Between Waiving and Grandfathering

A good way to think about grandfathering is that it lets you exempt existing risk you had before adopting IQ Server. On the other hand, waivers are a way to individually exempt new risk after IQ Server is deployed.

With grandfathering enabled, you won’t get overwhelmed with violations, but you will be aware that the violations exist. It’s different from waiving in this way. Waivers acknowledge a variance in policy for a specific component, whereas grandfathering is a way to acknowledge the existing state of the application prior to onboarding with IQ Server. With grandfathering, you can easily get to a logical, approachable scope when you get started and have time to remediate risk.

Why is it Needed?

Grandfathering violations lets system owners enact enforcement at their own pace and allows developers to select the best components at a logical starting point. A basic function of grandfathering violations is to not unexpectedly break builds that were previously working fine.

For example, you turn on grandfathering, onboard a new application, and then run an evaluation that returns 100 violations, with only a small portion being critical. Because you had grandfathering enabled, you can see all 100 violations, but only the 10 critical ones are going to follow policy enforcement. This lets you focus on what’s most important, but it doesn’t mean that you’re done. It means you see the grandfathered violations and then triage remediation of everything else while still enforcing policy. With grandfathering, you can mute the minimum risk and give your team more time to work on what’s important.

What’s the Best Approach to Manage Grandfathering?

Grandfathering is disabled by default so that upgraded servers behave the same. You can enable it at the root organization, organization, or application level (to see how to enable this in the UI, go to Policy Violation Grandfathering in our IQ Server Help docs). This feature is built to inherit from the parent and that determines what you can do in the children (if you need a refresher on hierarchy and inheritance, check out our Hierarchy and Inheritance topic in the IQ Server Help docs). We recommend that you go ahead and enable grandfathering at the root organization level and allow override by child organizations and applications. This gives you the freedom to disable grandfathering at these levels, but it will apply to everything by default through inheritance.

Grandfathering applies only to applications and works with your policies. In IQ Server, a policy is the set of rules or criteria used to evaluate components in your applications. Administrators set policy actions when creating the policy, including how action is handled at enforcement points. When a policy is violated, the defined action is executed at the enforcement point. For example, a violation found during continuous integration stops the build while violations found at proxy time with Firewall block downloading of the component.

You can choose what policies can be grandfathered in the policy configuration of IQ Server. Our ideal state is that you should not grandfather critical violations, and that’s why the most critical (9 and 10) violations aren’t grandfathered by default. This lets you focus on the most severe violations while keeping a backlog of everything else. This can be changed in the policy, as needed, to suit your organizational needs. When you fix any grandfathered violations, you can re-evaluate and they won’t be there anymore.

Anything that’s been grandfathered can also be revoked, which will reinstate the grandfathered violations at the application level. When you revoke grandfathering on an application, running any further evaluations will contain the policy violations where applicable, but the existing reports won’t change.

With this feature, we have the means for you to see the grandfathered violations, but we don’t have a way to say “Hey, team, this is what you should work on.” We expect teams to look at their grandfathered violations and then add these to your backlog to fix. Grandfathered violations are not things that you should permanently ignore. Instead, you can fix the critical violations up front and then schedule fixes for the remaining risk into your development cycle.

Notifications

Remember that with grandfathering, we don’t want to hide your risk. Because of this, a lot of the work done for this feature is around adding visibility in the user interface and creating notifications.

When grandfathering is applied, it is always reminding you of your risk. You can filter by grandfathered violations in the Dashboard, and you’ll also see summaries throughout the Application Composition Report. Notification emails have also been updated to show the number of grandfathered violations, and you’ll also see alerts in your CI plugins. Anywhere that we can show you what’s grandfathered, we’ll show it. The goal is that they’re always visible and that you’re working on them.

Figure 1: Grandfathering Notification in Jenkins, Grandfathered Filter in Lifecycle Dashboard