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.
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.
Open Source Component
will also import:
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:
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.
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
Since there’s a vulnerability in
and we've imported:
Open Source Component,
which then imported:
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.
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.
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:
Shows each component in a list.
Easy to quickly read component names
Doesn’t show any hierarchy
All dependency relations are not viewable
Shows hierarchy between components, but circular dependencies are shown multiple times.
Great for visualizing linear dependencies
Components A, B and C exist multiple times
Hard to see duplicate items when the list is very large.
Graph showing all connections and showing only one of each component.
Circular dependencies are viewable
Can see a lot of connections in a small area
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.
All depenendency types are easy to view
Focus on one component to see all of its connections
Easy to see connections
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.
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.
Full Data List
Name of component
Name of component
Overall score (out of 500)
Overall score (out of 500)
PUTTING IT ALL TOGETHER
The Full Tree View.
After the research was complete, here are some final examples of the tree graph.
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.
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.
A Full Look at our User Journey
List of the core steps to the experience of the application.
Upload a file or link that represents your project, including all of its dependencies.
You can now view all of your dependencies and see how they are connected, and filter if necessary.
Select different components to see their details.
User can see when an upgrade is available, and quickly improve their score.
Take it home.
Export a upgraded SBOM and import it into your project.