Matt Gibson

if you already know what dependencies and vulnerabilities are.

INTRODUCTION

What are dependencies?

A dependency is a piece of code (also known as a component), that you have imported into your project. Typically, these components are developed by companies, or communities of people collaborating together.

This means that you are bringing in code that you do not maintain yourself.

In

Your Project

you've imported an

Open Source Component.

You use their code in your project and are now dependent upon it.

This is called a direct dependency.

The

Open Source Component

you imported,

will also import:

Component ABC.

You are now dependent upon something that you did not import yourself.

This is called a transitive dependency.

It gets a bit more complicated...

We have now imported:

Component ABC.

But,

Component XYZ

also imported

Component ABC.

This is called a circular dependency.

We now have multiple components that are dependent on each other. This will be more relevant when we look at vulnerabilities in the next section.

PART TWO

What are vulnerabilities?

A vulnerability is a piece of code that has the potential to effect our project in ways we didn’t intend it to. We want to avoid vulnerabilities!

A component that you import, could have a vulnerability risk associated with it.

There’s a vulnerability in

Component XYZ

Since there’s a vulnerability in

Component XYZ,

and we've imported:

Open Source Component,

which then imported:

Component XYZ,

Your Project

now also has been exposed to a vulnerability

Avoiding vulnerability risks is important, but understanding where vulnerabilities come from, can be very difficult.

If you do not know all of the dependencies in your project, then resolving these vulnerability risks is even more difficult. That's why we are trying to help developers see their projects as a wholistic picture.

PROJECT OVERVIEW

What were we trying to make?

An experimental application to help developers quickly assess all of their dependencies and improve their project.

Enable developers to see how all of their dependencies are connected.

View key metrics regarding how your whole project and each component is performing.

Receive feedback on how to improve your project and each component.

Summarize and export your actions to improve your project.

PROBLEM ONE

Visualizing dependencies

Comparing methods of visualising dependencies and analysing how they can help developers understand the relationship between their dependencies.

We have 5 components in this example:

We also have 7 connections between these components:

LINEAR DEPENDENCIES

CIRCULAR DEPENDENCIES

List

Shows each component in a list.

PROS

Easy to quickly read component names

CONS

Doesn’t show any hierarchy

All dependency relations are not viewable

Tree List

Shows hierarchy between components, but circular dependencies are shown multiple times.

PROS

Great for visualizing linear dependencies

CONS

Components A, B and C exist multiple times

Hard to see duplicate items when the list is very large.

Tree Graph

Graph showing all connections and showing only one of each component.

PROS

Circular dependencies are viewable

Can see a lot of connections in a small area

CONS

Graph can be very busy

Difficult to see individual connections when there are a lot of connections

Tree Graph with Focus

Same as above, but the user can also select an individual component and only see connections related to that component.

PROS

All depenendency types are easy to view

Focus on one component to see all of its connections

Easy to see connections

CONS

None

PROBLEM TWO

Defining the Data: What do users want to see?

The user needs to be able to quickly determine which dependency needs attention. We did some exploration to determine how much data needed to be shown for them to take action.

Here are some of the designs we explored for nodes on the tree graph.

REFINEMENT

Determining what users want most.

After some testing, we created a refined list of the most important data to display on each component in the tree graph.

The Full Tree View.

After the research was complete, here are some final examples of the tree graph.

Nodes

Finalyzing the styling of each of the nodes in the graph.

Iconography is used to convey when:

An upgrade is avilable for a component

An upgrade is applied automatically without the need for human input

An upgrade is applied but may have issues that need human input

Components are scored on a scale out of 500.

The colour for a lower score has a higher contrast to gain the users attention.

Default Tree View

Here is an example of what the nodes look like in the context of a larger tree view.

Filtered View

The graph can be filtered based on different criteria (here we’ve highlighted scores 150 and below). This helps the user quickly determine which components to focus on.

Selected Node View

Once a component has been selected, all other components that it is not directly connected with become less visible. This helps the user focus on the context of the component that is selected and visually block out the rest of the graph.