The CVE database on Ubuntu.com provides information about security vulnerabilities to users of the Ubuntu operating system and the Security community. CVE stands for Common Vulnerabilities and Exposures, and it is a system used to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. Given that Ubuntu is used in millions of machines and servers around the globe, it is essential that this information is accurate and easy to understand.

The CVE database in our website reflected our internal processes and language instead of addressing user needs. We conducted surveys and user interviews, and collected feedback on pain points when using the website. We also looked into other vulnerability databases, such as Debian’s and Red Hat’s, to learn from the way they were naming status and severity levels. We did all this while engaging with half a dozen Canonical teams.

The search results are more compact and show more relevant information. They also provide filters that are easier to use.

The search results are more compact and show more relevant information. They also provide filters that are easier to use.

Based on the research, we now provide clearer labels, self-explanatory as much as it is possible. Documentation is now also easier to access, providing guidance on how to get the latest patches to secure Ubuntu machines against the latest vulnerabilities.

From hundreds to a single status

Perhaps the biggest piece of work was the summarised statuses we now show for each CVE. In the previous design, we were showing every status per affected package and Ubuntu release. For many CVEs, particularly those related with the Linux kernel, that meant showing a long table with hundreds of statuses. Search results became overwhelming and hard to navigate as a result.

We worked together with the Ubuntu Security team for months on the logic for a single status per CVE that could abstract all that complexity without misleading users. This summarised status automatically updates as the user narrows down their search by using the filters, giving them an ever more accurate yet compact overview of the issues they might need to address.

Example of kernel update, which used to show in the search results as a table with 6 columns, one per release, and 126 rows, one per kernel version. Now a summarised status is shown, reading 'Some fixes available, 19 of 30', and then up to five of the affected packages

Users show the way

For this project we were able to conduct all kinds of research. We reviewed the web analytics for the CVE pages (thousands of visits per month) and ran heatmaps to see how users were interacting with them. We benchmarked how other websites were dealing with similar information. And we conducted heuristic analysis, checking for best practices both in terms of user experience and accessibility.

But most importantly, we asked our users about their experience. We gathered feedback through a survey with dozens of responses, and then interviewed a handful of users, both external and internal. These users validated some of our assumptions on the shortcomings of the existing design, and pointed out some new problems.

As a couple of users pointed out, improving status labels was much needed:

“I’m still unsure as to what the Status column values actually mean. e.g. “Does not exist”: does it mean the vulnerability does not exist in that particular package? Or that there’s no patch? What does “needed” mean? Is it the same as “does not exist”?”

We now use more explicit and standard wording, instead of reflecting the status of the CVE on our internal pipeline:

Released became Fixed; Needed became Vulnerable; Pending became Vulnerable, work in progress; Deferred became Vulnerable, fix deferred; Needs triage became Needs evaluation; and Does not exist became Not in release

Some other users flagged how we weren’t providing any sort of information on how to actually fix the vulnerabilities:

“How a fix should be done should be the most prominent information for someone like me. I am trying to fix these vulnerabilities in my systems after a scan picks them up.”

Together with the Documentation team, we came up with a new page that explains our recommended practices for keeping Ubuntu instances secure and up-to-date, and we link to it from each individual CVE page. If no patch is available yet for a specific CVE, our Security team might provide some mitigations that are featured prominently on that page.

Beyond the specific tweaks here and there, research also showed us the variety of users and contexts for which this database was relevant. From IT consultants to university librarians, from data centres to a personal laptop: security is always essential. Each user has different jobs to complete, and so we verified that all the available information was accessible in one way or another for key jobs.

Miro board with sticky notes, outlining every user story and the related acceptance criteria

This work was conducted together with Katarzyna Cichomska (user researcher) and MariaPaula Trujillo (web engineer).

Back to portfolio