The Results area displays risk information based on the state a policy was in at that time of the most recent evaluation, while information regarding the age is taken from the fist occurrence of the violation. If policy changes have been made, and a new evaluation has not been conducted, the changes will not be reflected in the currently displayed information.
The Results area provides several views of risk information, each of which is described below:
At the top of the Results area, the View menu contains a Calculate Trends command. Calculate Trends opens a Policy Violation Trends dialog displaying policy violations trends that match your current filter.
Calculating trends can take some time depending on the number and size of evaluations that match. |
The purpose of Policy Violation Trends is to provide a quick, twelve-week look at how risk is entering your applications, and how you are handling that risk. The information is divided into four categories, with each category having four metrics over a twelve-week period.
A policy violation that has been Discovered, but not yet Fixed or Waived, is Pending.
Reducing the number of pending violations is a critical task. Weekly deltas above the x-axis indicate there were more discovered violations than those fixed; green bars below the x-axis represent more violations were fixed than discovered. |
This represents a count of policy violations that have been waived. This count is not included in Pending or Fixed, but is included in Discovered.
For more information on waivers, see the Waivers section of the Application Composition Report chapter. |
A policy violation is Fixed when it no longer exists in any stage.
When determining the Fixed state of a component, any filtered stages are not considered. That is, if you exclude a stage where a violation has occurred, the count for fixed may increase even though the violation is still present in the other stage. |
It is not uncommon to see discovered violations trend upwards steeply, especially in the early phases of your implementation, and then plateau as you start developing a better component consumption process. Using your mouse to hover over values in the graphs will display the individual values for each week. |
Violations is the default view for the Dashboard. It displays the first one hundred, newest component violations found in your applications. The data in this view can also be adjusted using the filters, and is organized into a number of columns and rows. These have been described below.
A violation is only considered new the first time it is discovered, even if it is found in different stages. For example, if a violation is found at the first of the month during an evaluation at the Build stage, and then again at the end of the month at the Release stage, only the occurrence at the build stage is considered new. |
The Components View displays the first 100 highest risk components based on any filters that have been set and your level of access. Risk is represented in several ranges (Total, Critical, Severe, Moderate and Low).
To calculate the total risk for each component, the threat level of all policies the component has violated are added together. In other words, component risk is the sum of policy violation threat levels for the component. A similar calculation is done for each risk range.
Now, this may leave you wondering, "What about the duplication of violations across stages, or even in the same stage?"
Good question.
For all calculations, a violation is only counted once. When there are multiple instances of the same violation, only the most recent occurrence is counted, regardless of stage. Because of this, in cases where a policy has been changed in between evaluations, the violation from the latest evaluation will be included. This will be true, even if the change to the policy included threat level.
Now, let’s take a look at each individual column, which has been described below.
The Applications view displays the first 100 highest risk applications based on any filters that have been set, and your level of access.
Like a component, risk for an application is associated with the threat level of a policy. In the case of application risk, it is the sum of policy threat levels that correspond to unique policy violations for the components in an application.
This produces a total count by stage. The unique occurrences are then added together to create the total risk of an application. Put another way, application risk is the sum of all unique policy violation threat levels across all stages and policies the application is evaluated against.
Similar to the By Component view, for all calculations, a violation is only counted once. When there are multiple instances of the same violation, only the most recent violation is counted, regardless of stage. Because of this, in cases where a policy has been changed in between evaluations, only the violation from the most latest evaluation will be included. This will be true, even if the change to the policy included threat level.
In the Applications view, risk is broken down into six columns described below.
Click the stage name to see the most recent Application Composition Report for the corresponding application and stage. |
For additional detail, take a look at the descriptions of each column below.
Remember, if your filters exclude data in any of these categories, this information will not be displayed. |
Terms of Service Privacy Policy
Copyright ©
2008-present, Sonatype Inc. All rights reserved. Includes the
third-party code listed here. Sonatype and Sonatype Nexus are trademarks
of Sonatype, Inc. Apache Maven and Maven are trademarks of the Apache
Software Foundation. M2Eclipse is a trademark of the Eclipse Foundation.
All other trademarks are the property of their respective owners.
Sonatype Headquarters - 8161
Maple Lawn Blvd #250, Fulton, MD 20759
Tysons Office - 8251 Greensboro Drive #610, McLean, VA
22102
Australia Office - 5 Martin Place, Level 14, Sydney 2000, NSW, Australia