Dependency View
This view gives an overall understanding of the security risk of the dependencies in your repository or branch, by displaying them along with what vulnerabilities those dependencies introduce. It is a graphical Software Bill of Materials (SBOM) with the ability to export (in the CycloneDX format).
With the analysis of a repository and branch or pull request, Lift will perform a scan of all dependencies it can find and display the results in the Lift Console in the Dependencies tab. The outputs of this scan are a Vulnerability Summary, a Component Summary and a breakdown of Components found. The page also has the ability to export the results into a JSON file using the Export CycloneDX button. The export JSON file is CycloneDX format with custom property registered under CycloneDX property taxonomy.
Vulnerability Summary
The Vulnerability Summary shows the total number of vulnerabilities found in your repository branch scan along with a summary of the severities. This displays a count in 4 categories (Critical, Severe, Moderate and Unknown) as well as in a pie chart segmented by color for a full picture display. For example:
A severity of "Unknown" occurs when the system does not have a CVSS score for the vulnerability. This can occur for a variety of reasons, many being data dependent and outside the scope of this application.
Component Summary
The Component Summary relays the number of components with vulnerabilities and tells the percentage of components in your repository branch that were scanned as vulnerable. A pie chart shows a visual of that percentage. For example:
Components
The Components section shows a list of all dependencies found and scanned by Lift. Also shown are letter designations of what type of dependency it is, the number and category of vulnerabilities, if any, against that dependency, and the number of occurrences of the dependency. Further, you can filter by title, and there is a dropdown in the Vulnerabilities column that allows you to limit the results by severity.
| Dependency designation | What it stands for |
|---|---|
| D | Direct Dependency |
| P | Project Dependency |
| T | Transitive Dependency |
| U | Unknown Dependency, i.e. one that Lift does not recognize, such as internal to your project |
If no dependencies can be found, this section will show "No Data".
Each dependency row may be clicked for more specific information about the dependency.
Dependency Specifics
The resultant page begins by restating the component path, name, ecosystem and version you clicked to get here.
The Vulnerabilities table shows the criticality in a matching color circle as well as textually. You can also click each row in that table for the full vulnerability data, including exact vulnerability score, explanation and recommendation. Note, not all vulnerabilities will have the same level of detail as they depend on what is known and input about them.
Lift is one of the only products which takes into account risk from transitive as well as direct dependencies! You see that in this table and the preceding Threats count.
The Dependency Graph shows visually where the dependency falls, vulnerable or not, within the project. If it is found multiple places, it will show multiple times in the graph. This has the combined effect of showing how often the item is used as well as if it's vulnerable how many places you'd need to fix. Above the tree structure, the number of occurrences and dependency types are summarized.
Be aware, clicking the links in the Dependency Graph takes you to more details about the component you clicked. It is not a tree-like navigation. So, in the example screen below, clicking Maven : com.scalesec/vulnado : 0.0.1-SNAPSHOT will open up that dependency and tell you the information about it.
Sometimes, above the Vulnerabilities table a Version Comparison section will be displayed. This section is shown for Java components where there is a newer version to upgrade to. Next to your current version, Lift will show the newest major version that matches the one you are on as well as the latest version overall (just once if these are the same) and a breakdown of them to compare against each other. This section will not appear if the component is the latest version nor will it appear for non-Java components. Here's an example of the comparison:
This example shows the current version of h2 in the project (1.4.199). This compares to the latest major version (1.4.200) and the latest version overall (2.1.214). You can see the latest major is much more popular though has a few (possible) breaking changes as well the same number of vulnerabilities. The latest overall has no critical vulnerabilities though is less popular so may have unknown things lurking. It also has a huge number more (possible) breaking changes.
The Lift Score row shows the severity score of each version as determined by Sonatype; the range is between 0-10 where 10 is the least secure/most risky.
The Vulnerabilities row shows the number of vulnerabilities in each version. While often this makes an obvious choice (less vulnerable equals better), sometimes greater versions have more total or severe vulnerabilities thus are worth comparing.
While many Lift reports take into account transitive risk, at this time, the version comparison does not. Thus, you may see differences between the Vulnerabilities row count and the Vulnerabilities section just below it.
The Relative Popularity row shows the popularity scores against other versions of this component. The higher the score the more popular the component is. While popularity should not be the sole determinate of use, unpopular components do not get the same visibility and scrutiny as more popular components, thus may have more unknowns and possibly issues. 
If the version is less than 3 months old, there will be a warning icon next to the percentage, relaying that the data may not be as reliable as older versions. But in more detail this is what each row represents:
The Published row tells you when each version shown was released. If that data is not available, Lift will say N/A in the place.
Finally, the Breaking Changes row details the number of possible breaking API changes when you switch from your current version to the one discussed. Note, this is a total number of possible breakages and not the ones that you will need to fix for your specific project necessarily. The number is intended to represent how big a change this may be and a gauge of maximum risk and effort to upgrade. That number will always be 0 for your Implemented Version. In the event the latest version is very new, this value may temporarily say Unavailable but will update once the information is calculated.
The Version Comparison section does not champion always upgrading to the latest major or latest version, the information is just provided so you can be aware and help make an easier decision. It is altogether possible a newer version may have more vulnerabilities or breaking changes and is not always the best choice.